人人都是产品经理总结 第三章2

本文对应人人都是产品经理的3.5、3.6两节，其中3.5节重点讲了项目管理中的文档管理、流程管理和敏捷方法，3.6节重点讲了作者亲历的一些项目。

文档管理

1、pd的文档主要分为以下几类（详细的看p156的图）：

商业需求文档：BRD。

产品需求文档：PRD。

需求规范类：PD做什么、用户体验规范：交互规范、视觉规范、文案规范等，主要让负责用户体验的同学负责。

需求管理类：用户调研文档：用户调研的前中后都需要做什么，调查问卷、用户访谈怎么设计等；产品需求列表；产品信息架构：用来描述产品的页面或功能之间的关系，网站地图、导航结构等。

流程管理类：日常发布流程；变更事件流程；

项目管理类：项目管理制度（原则性内容，例如产品会议制度、项目经理、开发经理、测试经理的权责利等）；项目任务书；kick off的ppt；项目组织结构；项目WBS；项目日报周报；项目发布预告及公告；

日常工作类：会议记录；个人日报与周报；

今后不管去哪里工作，这些模板都是自身的知识积累，已经融入了自己的理解，是一笔宝贵的财富，因此，上面所说的各种模板，工作以后需要根据自己的需要进行定制，多思考这些制度与规范，团队大了以后要用制度去约束人，而不是靠人去管理人。

模板主要有三方面作用：让经常看同类文档的人提高效率；让写文档的新人可以尽快上手；让写作者不会漏考虑某些内容。

模板与规范应该在需要的时候自然生成，逐步从简单到全面，不断迭代优化。

2、文档的版本管理问题

一种方式可以使用SVN，但问题是同一时间只能由一个人来编辑，另一种方式用wiki。苏杰文档版本号的含义：第一次给别人看是0.5，以后每次自己的修改，改小数点后第二位，如0.51、0.52等；有过集体讨论后的较大修改，会修改小数点后第一位，比如改成0.6，直到第一次正式对外发布，改成1.0。

流程管理

1、长视者把目的当手段，短视者把手段当目的。

2、通用的做产品的流程（适用于其他行业）：概念->方案->开发->验证->发布->生命周期维护。前两个阶段需要高手做，进入第三个阶段，高手应该去做新项目。新人做老产品，新人不挑活，老产品不容易出事；老人做新产品，老人需要变化才有激情。

3、流程的本质目的在于知识的传递。当年的“英雄”把自己的个人经验转变成显性知识表达出来，而对于经常做的事情，就可以用流程这种形式固化、传承，后人在做这些事的时候起码不会太无助。在这点上，规范、模板的作用也类似，这就是团队的核心竞争力。

4、评审是否可以省略

评审会议主要由以下几个：

产品会议：必须有，决定“做不做、做多少的问题”。

kick off会议：最好开一下，鼓舞士气的，磨刀不误砍柴工。

需求评审：如果项目kick off之后只做一次评审的话，那就是需求评审。

设计评审：表面上看起来经常在时间紧的情况下省略，实际上是在开发人员实力很强的情况下省略，而开发较弱，新人多，业务不熟的团队，则必须进行设计评审。

TC评审：仅次于需求评审，项目KO之后的第二重要评审。

功能评审：也是必须的，且需要项目干系人都参与，功能评审经常采用线下的方式进行，例如邮件里通知大家测试环境地址，然后大家自己去看。

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

上面的几个会议可以分为下面两类：

商业评审：决定做不做，包括产品会议与功能评审，商业评审得出的三个决定是：项目继续、重新定向、项目终止。

技术评审：决定怎么做，包括需求、设计、TC、发布评审。技术评审得出的三个决定是：项目继续、有风险的继续、必须解决某问题后再继续。

商业评审与技术评审最好分开，或者说在任何评审会议上不要同时讨论商业与技术问题，否则会被技术人员带入细节讨论，或者商业人员打击技术人员，或者决策者思维被搅浑。

敏捷方法

实践中的总结

1、项目计划应该不断修正，开始订的项目计划，一个月后很可能已经面目全非，强行遵守是没有意义的，而应该不断的修正。

2、迭代周期内尽量不加任务。如果某次迭代内的任务无法完成，可以为了时间点的要求，移出一部分任务到下一个迭代。

3、持续细化需求，强调测试，测试执行的过程可以用来补充和细化需求。

4、通过不断地发布来分解问题，让需求方不断的，尽早的看到结果。不断地发布是为了把大问题分而治之，先解决最核心的，风险最大的问题。

5、当每周两次发布时，阿里一般选择在周二和周四，如果只有一次的话，周三是个不错的选择。

敏捷过程中的沟通

苏杰书中有一句话写的很好，摘录在此：“无论最终发现什么，我们必须理解并完全相信：每个人在其当时所处环境下，在其能力范围中，做了最大的努力。”

1、每个项目，项目经理都会建立一个即时通信的IM群

2、项目相关的第一封邮件，会把大家的email收集齐。

3、每日站立晨会

4、项目看板视情况而定，板上横向为各个功能点的进度百分比，纵向为项目成员。红黄绿不同颜色的便签可以用来代表不同类型的人物。

作者亲历过的几个项目实战

1、老板项目

老板项目的Time是给死的，但是老板经常是一时说最好怎样，结果我们千万不要理解成必须怎样。订项目计划的时候给自己留一段富裕时间。

Quantity是可变的，开始的时候，尽量把Q搞大，并合理的给出一个巨大的Quantity，然后老板会因为Resource不够而自己砍Quantity，此时pm应该排出各种功能的优先级和所消耗的资源。

由于是老板项目，因此一般Resource资源是很丰富的

2、封闭开发

封闭开发的好处是交流非常方便；小空间更容易产生讨论，参与者更加积极；

3、项目外包

任何一个项目开始的时候，合作的多方必须要明确合作模式、划分权责利。

项目外包的话，乙方应该主动向甲方收集需求，并维护PRD等文档；而开发外包由甲方驱动更合适，走甲方的需求流程，不断给外包的工程师更新需求。项目外包过程中，甲方一定会有验收测试，但是乙方一定要在项目范围内安排比验收测试更详尽的测试，千万不能把找bug的测试寄托在甲方的验收测试上。

三边六拍项目

三边指的是：边计划、边行动、边修改，敏捷开发的过程中就是这样的，重要的是，关键的方向、目标一开始就要清晰，一些原则、约定不能总是改变。

六拍指的是：领导拍脑门决策、领导拍员工肩膀表示信任、员工拍胸脯承诺、领导拍桌子骂娘、员工拍屁股走人、领导和员工拍大腿后悔。六拍之后的关键是吸取经验教训，防止下次再犯同样的错误。