人人都是产品经理——iamsujie

我一直觉得敏捷是理想与现实妥协的结果，是一种很好的实践，理论网上随便一搜就有很多，这次就说说我身边的团队，真实的实践，通过“沟通”的角度来讲，不妨起个名字叫做“敏捷沟通”。

我们的每个项目，项目经理都会建立一个临时的IM群（旺旺）、一个临时的邮件列表，把项目干系人全部加入。邮件列表通常是通过第一封项目相关的邮件，把大家的email整理齐，在邮件最后说明“本项目干系人以此封邮件为准，大家的项目邮件可以直接回复全部并修改邮件名称和正文”。IM用于实时沟通，比如发了项目邮件要大家赶紧收、文档有重要更新、测试环境构建了暂时没法访问等等，都可以群里吼。旺旺有群公告，我们会贴上项目各种文档、资料的wiki地址，以及一些测试环境的host绑定等等公共信息。

经典的每日站立晨会我们团队是坚持的，对于典型周期为2～4周到项目，控制粒度到“天”还是很必要的，项目状态看板视情况而定，经常搞，举例如下。

第一张图，是用白板做的项目看板，这类项目典型长度是两个星期，看板可以和项目日报、晨会整合应用，板上横轴为进度百分比，纵轴为项目成员。每个项目成员负责的功能点，用一张张便签表示，在项目开始的时候这些便签都贴在0%的下方，随着项目的进行，这些便签就逐渐被拿到右边的方格里。每天晨会的时候，大家都围在白板前，集中调整便签的位置。便签的红黄绿不同颜色可以加以利用，比如代表不同类型的任务，白板最右边留出一块可以写其他必要的信息，非常随意。用了这种看板，对于如此短周期的项目，邮件日报通常可以省略。这个看板的最大好处是随时可视，项目成员、老板路过都会看两眼，而每个人要自己贴条，也是一种督促和帮助，试想大家都按进度在走，你老是滞后，自己也有压力，另一方面，如果真遇到困难，大家也能及时发现并提供帮助。这里也蕴含着自我管理的思想，让每个项目成员都对项目进度负起责来。

第二张图，是“魔方计划”（项目代号）的项目墙，和白板比起来，这个项目相对长期，2个月左右，毕竟这样一个KT板也要200多块钱，上面主要有整个项目的时间轴、各个团队的重要里程碑、产品设计过程的一些可视化文档等等。究其目的，也是让所有项目干系人随时可以了解到项目的各方面信息，在每个项目里，类似的看板应该包含哪些内容，大家可以边实践边改进。最终能做到根据项目特点的不同，在启动的时候自然使出最合适的项目管理方法，从而画出最适合的看板，就是最高境界了，而这种最高境界的习得，我现在的感觉是没法学，没法文档化，只能靠悟，比较郁闷。

顺便提一点，我们喜欢尽量给一些项目起个有意义的代号，说实话这样还真能增加临时团队的凝聚力，比如“还魂丹”（激活不活跃用户的项目）、“魔方计划”（将多个产品的零散模块整合成一个新产品）、“画皮”（产品界面改版）、“画心”（产品交互改版，PM光光同学在这个项目Kick Off的时候，一直放着张靓颖的《画心》做背景音乐，感觉真的很不错），而一些特别的项目，还会把团队临时集中在一个会议室做，叫封闭开发。

最后小结一下，从沟通扩大至整个敏捷方法，任何团队的探索，都在试图给出一个介于“无过程”和“过度过程”之间的折衷方案，使这个轻重适中的过程给团队带来最大的收益。

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需要收集反馈以确定下一步方向、团队也会做人员调整），所以这个时候做产品文档规范，总结第一代产品、第一代团队的工作，对提高后期的效率是最合适的。当然，这个工作也是应该采用迭代的方式进行的，无需也做不到一蹴而就。