《人人都是产品经理》：项目坎坷的一生（下）

“计划与控制，就是项目管理”，项目管理中有几个关键问题，是：文档管理、流程管理、敏捷方法。

文档只是手段

PD的文档管理可以简单的以下面的这张图来表示：

1. 需求规范类：
   PD做什么：这是对产品和团队的PD工作内容的一份总结，可以让新人快速了解自己的工作职责。
   用户体验规范：又细分为如下几个部分，这部分最好让负责用户体验的同事编写。
   包括交互规范：视觉规范：文案规范
   通用原则：不断地去补充
2. 需求管理类：
   用户调研：这份模板说明了典型的用户调研前、中、后要做什么，调查问卷、用户访谈提纲怎么设计、有哪几块内容。
   产品需求列表：产品需求列表的模板、需求管理文档模板、需求状态变化流程图。
   产品信息架构：待补充，用来描述产品页面或功能之间的关系
3. 流程管理类
   日常发布流程
   变更时间流程、如紧急发布流程、需求变更流程、需求搭车流程、
4. 项目管理类
   原则性的东西，比如产品会议制度、项目经理、开发经理、测试经理的权责。
   项目任务书：可以用BRD来代替
   项目进度表：
   项目日报和周报：
   项目发布预告与公告：大量内容模块化，为了节省时间。
5. 日常工作类
   会议记录：大家都十分地痛恨没有结果的会议，有了这份东西，至少说每一次的会议都能够产出一些基本的内容，比如说会议决议、遗留问题和行动方案。
   个人日报周报：用于团队分享每个人的工作情况。

模板的作用

让经常看同类文档的人提高效率
让写文档的新人能够快速上手
让坐着不会漏掉某些内容

多人协作与版本管理

每个人对自己的文档进行维护，多人合作，共同办公。

流程只不过是手段

长视者吧目的当做手段，短视者吧手段当做目的。
不论如何流程只不过是为了完成公司的使命、实现公司的愿景
整个流程类似于IPD

这么多评审，可以省嘛？

总共的评审从立项之前的产品会议、到Kick Off会议、需求评审（又可分为PRD评审、UC评审、Demo评审），设计评审、代码评审、TC评审、功能评审、以及发布评审。
产品会议：必须有，决定“做不做、做多少”实在是太重要了，方向错了是十分可怕的。
Kick Off会议：最好开一下，鼓舞士气，磨刀不误砍柴的功夫，可以考虑和需求评审结合在一起。
**需求会议，**决定做不做，做多少，实在太重要了，方向错了很可怕，如果没有多个产品之间的资源争夺，同一个产品不同需求也必须要争夺，可以吧确定需求商业价值的需求讨论会，初评工作量等工作放在一起作为产品会议，参与者最少得是产品团队、开发、测试、销售、服务等各个部门的头，或者有话语权的接口人。
**需求评审：**具体的PRD、UC、Demo评审，基本上很少分为三次，看项目情况，任意两个都有可能合并，甚至三个合并，。
**设计评审：**我们一般在时间紧张的情况下会省略，而开发较弱、新人多、业务不熟的团队，则必须要进行设计评审，否则是给自己找寻不自在，后面出问题很麻烦。
TC评审：仅次于需求评审，这是在项目KO过后的第二重要的评审，敏捷方法很看重测试，实在要省也可以，那么PD就会辛苦一些。
功能评审：这其实也是必须的，而且需要项目干系人都参与，功能评审基本上采取大家一起去看的方式，对于重要的项目，建议可以开启一个产品演示会。
发布评审：可以让开发经理决定是否需要

敏捷更是手段

应用瀑布模型。

有计划、更拥抱变化

随着时间变化，必然有新的信息出现，特别是市场环境、用户情况等瞬息万变的场景下。

迭代周期内尽量不增加任务

敏捷再灵活，也不能容忍毫无控制的变化。如果某次迭代内的任务我们无法完成，我们可以移出一部分任务到下一次迭代，我们可以把每个迭代看作一个小的瀑布模型，瀑布模型对于一个需求固定的项目还是很不错的，比如它在管理一个工厂的时候就非常的有效。

集中工作、小步快跑

一般的团队小于十几个人，我们在工作中提倡较少的文档，更多的口头沟通，这点对团队成员的要求很高。

持续细化需求、强调测试

需求唯一不变的特征就是“不断地变化”，项目和产品都要小步快跑，用不着在需求阶段纠缠，有些需求在开始的时候是提不出来的，或者说没办法细化，所以试图一次性的完成需求分析工作就会存在过度的需求，是浪费时间的行为。
并且由于需求的不断变更，我们特别看中测试驱动项目，更早的测试、重度的测试，会帮助我们更加的去细化去求，比如说一些业务逻辑里面的限定条件一般都是由测试人员提出来的。

不断地发布，尽早交付

让需求方不断地、尽早地看到结果，并给予反馈，我们不断地发布一些版本，先解决最核心的，风险最大的问题。

项目中的敏捷沟通

首先记住一点，“无论发生了什么，我们必须理解并完全相信，每个人在当时所处的情况再，在其能力范围内，做了最大的努力了”
我们相互理解，激发团队力量。

总结

任何情况下，我们都要做好手头的事情，确保“就算这件事情黄了，我也要通过做事有所收获。”

老板项目

我们做项目的通常情况下，要保证品质的前提下，在时间要求T、人财物花费R、项目范围Q三点上去做平衡。
T可以试着商量以下，我们通常认为老板的项目的T是给死的，但老板只是一时说好是这样，但我们如果理解成了必须这样，那就亏大了，但也确实很多时候很难改变，但我们定项目的时候仍然应该给自己留一段，因为这是救命用的。
Q是可变的，先说Q，一般越大的老板给出的指示越有战略性，越不具体，锁体具化出来的Q可大可小，这是我们可以发挥的地方。开始的时候，尽情施展自己的聪明才智，尽量把Q搞大，并合理地计算出一个巨大的R，然后你就可以欣赏到老板因为无法付给你这么多R而自己砍Q的表演了，当然我们尽职地帮老板排出各种功能的建议优先级和所耗的资源，好让老板知道刀往哪里挥。
R是丰富的，老板项目，第一优先级，R就是大大的有，其他项目统统让路，让多少路，这个问题应该抛回给老板决定，我们只提供专家意见，狮子大开口，千万不要在这个时候为老板着想。