人人都是产品经理——iamsujie

2007年底之前，也就是开始做产品设计师约1年以内，我一直只是很单纯的在做产品设计、以及大产品设计，在为产品所发起的一个个项目中，扮演的是一个设计师的角色，主要负责“做多少、怎么做”的问题，那会项目经理是开发经理兼任，他负责“何时做、谁来做”的问题。

后来公司发现这样的一些弊端：

对设计师的考核是产品的商业价值，比如用户活跃度等等，而这些指标和产品的用户体验关系极大，大家知道，想把产品的用户体验做到极致，让用户轻松，必然的代价就是我们受罪，特别是开发的同学要额外做很多他们看起来价值不大的细节，比如一个最简单的登录页面上的2个输入框，一个填帐号，一个填密码，想体验好一点，就要考虑如何限制输入内容长度，如何控制输入非法字符，如何给用户提示等很多问题。简单说一下输入帐号的长度控制问题，就又要考虑是点击“登录”提交表单时判断？鼠标焦点移动到密码输入框时判断？还是输入帐号时随时计算长度直接判断？……

开发同学的考核一般来说是项目的完成情况，Bug数量，很显然，如果他们做项目经理，矛盾就自然而然就发生了，开发的同学会倾向于简化项目，尽量少做、做自己熟悉的，使得项目顺利完成 & bug很少，但是做出来的东西商业价值不足、用户体验不好。

由于上述原因，公司决定让产品设计师兼任项目经理，这样对我们的要求就更高了，于是我也渐渐的有机会接触了项目管理方面的事情，发现这块“硬功”也是一个产品设计师必备的素质，于是，我们向着全能战士——产品经理，又跨了一大步。

话说一个事物必然有它的两面，如果你只看到了一面，必然说明你只看到了系统的一部分，我还是比较相信在哲学层面上，很多东西都是“守恒”，或者说“对立统一”的。那么这么做的缺点又是什么呢，留个悬念，后续在一些有关组织结构的文章里再做讲述。

回到本系列，先谈论了做产品与做项目的异同。在做项目的过程中，我体会到创业公司，或者大公司里的创业型团队，特别是对于互联网、软件行业，有一颗敏捷之心很重要，所以这部分里有不少关于敏捷的描述。此外举例了适合创业型团队的项目管理方法中的几个关键点，比如Kick Off、评审会，最简单的一句：计划与控制，就是项目管理。

大大小小的项目做了几十个，自然的发现另外2点提高效率的事情：流程与文档。

流程的作用，是把经常做的事情固化，以提高效率，下文有例子描述了简单的需求流程，再举个不好的例子，如果阿里有一位同事不幸去世了，那公司一定会起个紧急项目来处理这件事，而如果是华为，就可以走流程了。项目与流程是对立统一的关系，并且可以互相转化，后面也会仔细描述。

文档管理主要谈到了两块：一是模板管理，文档为什么要有模板？我们有哪些常用的文档模板？各个模板的目的是什么？相应的又应该怎么设计？举例说明了一些文档具体应该如何写，已经贴出来的有最最常见的UC；二是版本管理，提到了版本管理的目的，有哪些常用的版本管理方法及其优劣，顺便讨论一下文档轻重的问题。

这个系列还没有结束，这篇算是一个阶段性小结。

老板项目，就是指老板突然跟你说，我们要做个什么什么，然后你只有执行的份儿……的项目。什么，你们公司所有项目都是老板项目？很正常，那我们更应该聊聊这个话题了。

先来一点科普，做项目的目标无非是多快好省：范围多、时间短、品质高、资源省。但又要马儿跑又想马儿不吃草的事情是没有的，有理智的老板也都明白这一点，所以我们通常是在上述4个要求中做平衡。对比经典的项目TRQ：项目时间（Time）、项目资源（Resource）、项目质量（Quality），几乎一样。一点区别就是Q，我觉得Q = Quality+Quantity更准确，质量这个词其实包含了“品质”和“数量”两个含义，而我所经历的项目，Q更多的是表达Quantity，一般来说，品质高这点是不会舍弃的（不排除有特殊场景），所以可变的是项目范围。

综合一下，我们做项目就是在时间要求、人财物花费、项目范围三点上做平衡，不妨就继续叫做TRQ吧。

来一个真实场景回放：“你突然被老板叫到办公室，他和蔼可亲，又情绪激动的对你说，小某啊，组织上有个重要项目要交给你，blablabla，省去半小时，这都不关键，最后一句：某月某日之前一定要发布！”似曾相识？嗯。首先恭喜你，通常这样的“老板项目”都是重要的项目，说明老板信得过你。然后你要反驳了，恭喜什么啊，我牙还没刷呢，连做什么都不知道，居然TRQ的T已经定了？！

是的，当时就是这样。

传统项目管理中的那一套，先需求，知道要做什么以后，再组织协调资源，最后推算出时间计划，在这里跑不起来啦。我脑中突然浮现一句话，改编如下：做项目，特别是老板项目就像被强奸，与其无畏的反抗，不如好好享受。

于是，阿Q的我们找到了理论支撑：Agile，敏捷！不是么，更多的时候我们都是被动敏捷，或是被老板逼的，或是被用户逼的，或是被对手逼的……人类的本性应该还是恐惧变化和不可知的吧，不知有多少人看到这里内心在呐喊——我爱瀑布模型！

所以有公司在价值观里宣扬“拥抱变化”真是很积极的一种人生态度。那我们来拥抱敏捷吧，看看在TRQ三方面应该如何享受：

T是给死的，可以试着商量一下，但一般很难改变，如果是老板的老板给老板定的，那就更甭想改了。通常，每一级任务的下放，老板都会给自己留一小段时间做缓冲，但是我们可千万不要在定项目计划的时候算上老板留给自己的这段时间，反过来，我们订计划的时候应该再给自己留一段，这些都是最后救命用的。

Q是可变的，先说Q，一般越大的老板给出的指示越战略性，越不具体，所以具化出来的Q就可大可小了，所以开始的时候，尽量发挥自己的聪明才智，先天马行空的爽一把，把Q搞大搞大搞大，并合理的算出一个巨大的R，然后，你就可以欣赏到老板因为无法付给你这么多R而自己砍Q的表演了……当然，我们应该尽职的帮老板排出各种功能的建议优先级和所耗资源，好让老板知道刀该往哪里挥。

R是丰富的，老板项目么，第一优先级，R就是大大的有，其他项目统统让路，让多少路，这个问题应该抛回给老板决定，我们只提供专家意见，狮子大开口：让的越多越好！记住，千万不用在这个时候就帮老板着想，应该怎么节省R，那样反而不讨好，老板会觉得你思路不开阔，没劲，我有过一次做了个项目方案，十几个人就搞定，沾沾自喜，结果老板说：你先给我照着100个人做这么久来规划。

真的这么爽？

当然不是，有时候你发现，老板比较猛，Q都帮你想好了，那只能说没劲，也别废话了，甩开膀子干活呗。更悲剧的是，R也是不足的，就那么几棵人，又要在固定的T下做这么多Q，绝望？不至于，我们还有最后一招IT民工必杀技——加班，天天加班，天天加班还不要加班费……我们期望的是老板看得到，公司有前途，明天会更好……

如果这样还做不完，那只能说——老板丧失理智了！兄弟，撤吧……

最后谈谈，老板项目到底好不好？从个人角度，如果是纯项目经理，这就是本质工作，无所谓好坏，而对于我们这样做产品的同学，老板项目没有成就感（有成就感的项目是自己去做用户/市场研究，然后发现问题，发起项目），而好处就是接近老板，无需多说；从老板/公司角度，效率高，决策风险大，其实，这和民主与专制的区别是很像的。

我基本每隔几个月就会整理一次团队的产品文档规范与模板，然后release一个非常轻量级的文档包，起个酷点的名字：PD_std_template_tool_kit.mmap，这次讲讲理好的mindmanager图：

====== 看不清猛击图片看大图 ======

Ø 需求管理类

n 用户调研模板，调研前、中、后都要做什么，调研问卷怎么设计。

n 功能列表极其管理方法，这里可以体会到团队协同工具的重要，我们用过office live的excel，比较简单。

n 产品的网站页面地图，这块让UE的同学帮忙这里更合适。

Ø 项目管理类

n 项目管理制度，原则性的东西，比如项目经理、开发经理、测试经理的权责利。

n 项目任务书，网上有很多模板，小项目可以灵活变通。

n 项目Kick Off的ppt，之前有说过这个话题。

n 项目组织结构，省时间的，以后每次填名字就可以了，没啥技术含量。

n 项目WBS，我用的是一个小软件“WBS Chart Pro”（奇怪我搜不到下载了，需要的可以问我要），只有几M，它做的图可以生成project文件，就是说项目计划也有了。（我不喜欢动不动就几百兆的软件，而对于几M就能实现大部分功能的小软件特别有好感，呵呵。）

n 项目日报，主要有今日要闻，明日看点，当前问题，所需支持，项目进展等几项。

n 项目发布通知，为了省时间而已。

Ø 流程管理类：小团队常用的有日常发布流程、紧急发布流程等。

Ø 商业需求类：BRD，参见4004。

Ø 产品需求类：PRD，参见3010。

Ø 需求规范类：

n 交互规范：控件规范，如列表的默认排序、列表中文字的对其方式，手头这个产品是“文本左对齐、时间居中、数字右对齐”；判断规则规范，包括字段的校验规范、系统反馈的规范等等。

n 视觉规范：整体的如页面大小、字体字号颜色编码。

n 文案规范：如语言风格、语法模板、常用操作的标准说法等。

Ø 日常工作类，暂时只整理了会议记录模板和日报周报模板。

另外还有很多文档，比如开发规范，会说一些代码的规矩，函数命名规则等等，PD接触的不多，我也太懂，就不扯了。

网上不少同行前辈讨论过产品文档、规范应该什么时候整理，我个人的感觉是产品1.0发布以后，2.0发布之前。一般互联网产品在1.0之前都是急行军，顾不上文档，而在做1.1、1.2的时候往往有一个设计工作的缓冲期（一方面是开发测试忙着应付扑面而来的线上故障、另一方面是PD需要收集反馈以确定下一步方向、团队也会做人员调整），所以这个时候做产品文档规范，总结第一代产品、第一代团队的工作，对提高后期的效率是最合适的。当然，这个工作也是应该采用迭代的方式进行的，无需也做不到一蹴而就。

UC（use case，用例）是需求人员写给开发人员看的一种最基本的文档，在和其他公司合作做项目的过程中，发现双方的文档规范差异很大，造成了沟通成本的提高，所以感觉在一个长期合作的团队中，文档与规范的统一真的是非常必要的（我强调的是“统一”，并没有强调要一定要用“某种格式”）。

查了一下资料，早期的需求人员是通过对应用场景（Scenario）的分析来细化需求，本世纪初，一些牛人们才将这种方法正式归纳为用例法。之后在网站制作中，业界又对其发展，扩展出了“任务分解”等需求细化方法。

从一个项目的PRD开始，首先会有些总体说明，如项目概述、功能范围、用户描述、词汇表等，然后主体就是UC文档，首先需要有个总的用例图来对系统给出高级可视化的表示，说明各个UC之间的关系，UML中有相关的内容。上个图感觉一下。

本篇简单说一下单个用例要描述哪些事情。

====== 看不清猛击图片看大图 ======

首先是UC概述（括号中举例说明每项内容）：

用例的唯一标识（UC_ordermeal）；

用例名称（点菜）；

业务描述（为什么要做这个UC？小明工作一周辛苦了，周末晚上去吃一顿好的补补。）；

需求描述（这个UC要做什么？去餐馆，点一个菜，之后等烧好了吃掉）

行为者（小明）；

前置条件（是周末，……）；

后置条件（服务员接受订单，去厨房，……）；

UC主体：

界面描述（小明的例子中好像没有，对于网页，我们对界面的描述经常占UC的很大篇幅，甚至链接上demo。当然还有一种做法是单独写界面文档，然后与UC文档互相引用）；

业务规则（比如限制条件：小明不吃辣，小明口袋里只有100块）；

流程描述，分主干、分支和异常三种，描述共前置条件到后置条件的过程中，系统与用户之间有何种交互步骤，这里多见的是时序图、活动图、流程图（小明自己选 or 让服务员推荐，if 服务员推荐，小明接受 or 不接受……确定点某个菜……）；

其他内容，额外的一些针对项目特定的需求。

UC一般只能描述绝大部分的功能需求，无法描述诸如性能、培训需要、时间限制等非功能需求，所以再加上非功能的需求描述以及项目其他的概要信息，才构成教科书里的“需求说明书”。