《人人都是产品经理》读后感16：互联网项目管理之流程

今天仍是3.5节“山寨级项目管理”，是其第二部分：流程管理。

---

流程也是手段

长视者把目的当手段，短视者把手段当目的。公司里的KPI就是一个很好的例子，坐着在第五章也有讲关于KPI的问题，后面再细说。但一定要记住我们研究手段，一定不能忘了目的。文档只是手段，流程也是手段，这些手段都是为了把项目做好，把产品做好；把项目和产品做好也是手段，是为了达到公司的商业目标；达到公司的商业目标也是手段，是为了完成公司的使命、实现公司的愿景……

项目VS. 流程

“项目流程”只是一种特殊的流程，坐着首先通过一段虚拟人物对话辨析了“项目”与“流程”这两个词的关系，我觉得说的很好，摘录如下：

大毛：项目只做一次，所以追求可行解即可；流程要反复做，所以要追求最优解。相似的做多了，就不会满足于可行解而想追求最优解……

小明抢话：这时会出现流程，比如结婚对于每一对新人来说都是一个很特别的项目，而对于婚庆公司来说就有整套的流程。装修也一样，如果自己做新家装修，那一定会起个项目来处理这件事，而如果是外包给装修公司，他们就可以走流程了。

大毛：嗯，例子不错，生活中的做事原则也是一样。项目是跳跃式发展，有始有终，比如历朝历代的开国皇帝，虽然打江山易，但它在价值链上更重要；流程是常规活动，周而复始反复应用，都说守江山难，是有点吃力不讨好啊，江湖地位总是差一些。但是项目管理是独特工作，风险大，效率低；流程管理则是例行工作，风险小，效率高。

小明：啊，我发现了，其实中国人不擅长做项目是有传统的，因为我们是农耕文明，生产制造大国，所以擅长做流程管理；而西方的狩猎、游牧文明，就有明显的项目管理的影子。

大毛：好吧，你真能扯……

经过几十年上百年的积累，传统行业的流程明显细化了很多，不过，毕竟都是产品研发的流程，总还是有相似之处。下面是通用的做产品的流程：

概念：启动阶段，关注商业规划，DCP（decision check point，商业评审点）1。

方案：立项，项目执行层面的非关键成员加入，关注规格、计划，DCP2。

开发：控制过程。

验证：测试，DCP3。

发布：项目团队解散，成立LMT，老人带新人做生命周期管理。

生命周期维护：DCP4。

前面两个阶段需要高手做，进入第三个阶段，高手应该去做新项目。这里有个通用的原则：新人做老产品，新人不挑活，老产品不容易出事；老人做新产品，老人需要变化才有激情。

流程的本质目的

流程不是一开始就有的，而是需求驱动的。

项目最初阶段，团队主要成员都是新人，所以靠的是几位老大和“随机应变”式的个人控制来把握项目进程。那时每个人对产品的一切都非常了解，对需求的响应速度也超快。

到了后来，加入的人越来越多，产品也越来越庞大，大家越来越感觉已经不能掌握产品的全部，于是渐渐地不敢那么快了，不然出了问题都搞不清原因。

于是，产品、团队、项目进化了以后，再依靠个人英雄主义是不行的，那样英雄会累死，项目也会失败。这时候出现的流程和规范都是一种管理的方法，产品在“快”和“稳”的平衡上，也要稍微向“稳”偏移。

在淘宝UED团队的博客上有句话：设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”。作者在华为的同学说过：流程的好处是人走了，事还能做，减少特定的人的影响。还有一位前辈告诉说过：路况（即软硬件环境）与开车水平（即个人能力）的要求成反比，流程的目的就是改善路况。

其实上面这些话说的都是一个意思，小结一下：当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力。一件事情总是有它的两面，流程帮助了产品，但对于后来者的个人成长也许不利，比如只能接触到产品工作的某一个层面，缺乏对大局的了解和把握，从而成为一颗“螺丝钉”。这就需要后来者自己寻求突破了。

那么多会议与评审，可以省么

产品会议：必须有，决定“做不做、做多少”实在太重要了，方向错了很可怕，如果没有多个产品之间的资源争夺，同一个产品的不同需求也必须争夺，可以把确定需求商业价值的需求讨论会、初评工作量等工作都放在一起作为产品会议。参与者最少得是产品团队、开发、测试、销售、服务等各个部门的头，或者有话语权的接口人。

Kick Off会议：最好有，鼓舞士气，可以考虑与需求评审合并为一次会议，安排在最开始的15分钟，因为它们参加的人员差不多。这个会议，项目干系人都应该到场，有的人可以在Kick Off结束后离开，不参加需求评审。

需求评审：如果项目Kick Off之后只做一次评审的话，那就是需求评审。具体的PRD、UC、Demo评审，很少分为三次，看项目情况，任意两个都有可能合并，甚至三个合并。

设计评审：表面上看起来经常在时间紧的情况下省略，实际上是在开发人员实力很强的情况下省略（他们在需求评审时会问很多问题），而开发较弱、新人多、业务不熟的团队，则必须进行设计评审，否则后面出问题很麻烦。

TC评审：仅次于需求评审，这是在项目KO以后第二重要的评审，敏捷方法很看重测试，实在要省也可以，那么PD会更辛苦一些，需要做更细致的验收测试。与设计评审类似，TC评审也属于纯技术的评审，商业团队一般就不参加了。

功能评审：这其实也是必须的，而且需要项目干系人都参与，但我之所以没有把它列为和需求评审一样重要，是因为功能评审经常采取线下的方式进行。当然，对于重要的项目，还是建议开一个产品演示会。

发布评审：可以让开发经理决定是否需要。

评审会议本身并不产生价值，应该尽量简化。而基本原则就是一句大白话：重要的评审不能省，最好单独评审，参与者取决于评审内容偏商业还是偏技术，而这些判断，没有统一标准，与产品、项目、团队的特点相关。

商业评审与技术评审

上一节把所有常见的评审放在一起又分析了一遍，其实它们大体上可以分为两类，即“商业评审”与“技术评审”。简单地讲，商业评审决定“做不做”，是产品会议与功能评审；而技术评审决定“怎么做”，是需求、设计、TC、发布评审。

商业评审的三个决定是：项目继续、重新定向、项目终止，很重要的目的就是砍项目。商业评审也是分阶段分发资源的时间点，会给通过评审的项目发放到下一个商业评审点之前的资源。

技术评审的三个决定是：项目继续、有风险的继续、必须解决某问题后再继续。需要避免的情况是技术评审三步曲：抓壮丁，随便找有空的人来参加；科普会，来的人根本不了解情况，说很多基本信息；批斗会，没完没了的争论。

商业评审与技术评审两者最好分开，或者说在任何评审会议上不要同时讨论商业与技术问题，否则会被技术人员带入细节讨论，或者商业人员打击技术人员，或者决策者思维被搅浑。评审是流程中的关键节点，节点设置的顺序正确、数量合适，才能保证流程的通畅。