产品项目管理的流程

产品项目管理的流程

日前听到同事对产品经理工作的概括“取舍需求，控制进度”，觉得第一个项目做到尾声，需要总结一下第一个项目关于项目管理的一些思考。接下来为大家推荐的是产品项目管理的流程，欢迎阅读。

项目启动阶段

任何一个项目，能够被启动，至少从战略层面是得到公司认同和支持的，也就意味着这个项目是要背负着实现公司的某一个战略目标而存在的。产品经理在项目启动前，有这么几个问题需要提前去了解和熟悉：

1、为什么要立项？

2、项目目标是什么？

3、项目的相关人员都有哪些？

4、怎么立项？

第一个问题，为什么要立项？

这个时候，作为产品经理的你需要去了解这个项目的来龙去脉，最好的方式是和你的上级或者BOSS沟通，因为他们掌握的信息量远远比你大且比你多，所以通过和他们沟通再加上自己理解，就能够对项目立项的原因有一个清晰的认知。当然，有时候项目立项，可能就是产品版本的定期迭代，这个时候产品经理对为什么要立项恐怕是比谁都更清楚了。

第二个问题，项目目标是什么？

产品经理作为项目的负责人，是一定要明白整个项目的目标是什么，然后在里面找出最核心的目标。例如有的项目是时间（越快越好，花多少钱无所谓），有的项目是钱（做慢点没关系，但是要花最少的钱）。这些都可以通过跟你的领导聊一聊聊出这些信息，知道了项目目标后你需要把这个目标用准确的文字写下来。

对，一定要写下来，因为口说无凭，再一个写下来的东西才能成为所有人具体执行的方向和准则。

第三个问题，项目的相关人员都有哪些？

关于干系人，宝洁的方法论是找出PACE。P是Participant（参与者），A是Approver（审批者），C是Consultant（顾问），E是Executor（执行者）。当然，产品经理（尤其是创业公司的产品）在日常的项目工作中，恐怕不会有这么繁琐的流程，所以，也就遵循一切从简的原则。

项目相关人员，可以从这几个角度去考虑下，如哪些人或部门会受到项目结果的影响，哪些人可为项目提供资源（人、财、物）等。当然，在互联网公司，常见的相关人员也就是老板、产品经理、项目经理、项目团队（包含设计、开发、测试、运维等）及用户等。

找到了项目的相关人员后，现在你要做的就是把团队成员绑到自己的船上。你需要去了解团队里每个成员的核心KPI，也就是他们于这个项目的需求是什么，做这个项目可以给他们带来什么。如果这个项目没被囊括在这个成员的工作评价list里面，你需要去找他的老板沟通。根据我的经验，85%出工不出力的情况都是因为你的项目

根本不会对这个成员的KPI有什么正向的帮助。当然，如果找他的老板沟通无效，还有最后一招，感情投资，请那个成员撸串、吃饭，利用感情让他帮你做好这个项目。

第四个问题，怎么立项？

通常来说，这个时候需要开一个项目启动大会。这个启动大会的目的是召集项目团队成员，成员之间初步认识一下，产品经理主持会议，然后清楚地传达项目要做什么，目标是什么，为什么要做，怎么做，谁来做等等。另外，跟所有的启动大会一样，项目的启动大会，也需要给团队成员来点鸡汤、打点鸡血。产品经理需要去统一团队的思想，明确团队的管理和运作方式，以及团队的沟通机制等，产品经理需要动员团队成员积极参与项目，并高质量地完成项目。

这个时候，项目相关的文档其实应该已经完成了，因为只有当详细的产品需求文档有了之后，开发团队才能估算项目时间及里程碑等。也有另一种情况，那就是项目本身包括了需求分析阶段，所以详细的需求文档是在立项之后才开始进行调研和撰写。不管怎么说，明确的产品需求和详细的需求文档，都是项目得以顺利进行的基本前提保障，所以，产品经理的规划能力、撰写文档的能力在这个时候就显得尤为重要了。

项目计划阶段

完成了项目的启动，接下来就要开始进行项目计划了，所谓的项目计划，其主要工作就是工作任务分解，任务优先级安排，资源、工期、成本估算，以及风险计划和沟通计划等。

工作任务分解，在项目管理中也有专门的术语叫做“工作分解结构”（WBS），指的是以可交付成果为导向对项目要素进行的分组。它其实归纳和定义了项目的整个工作范围，从项目目标开始分解，逐层下降，每下降一层，代表对项目工作的更详细的定义。

产品经理在每一个版本的迭代规划中，都需要从产品需求池中捞一些比较重要的需求出来放到项目需求里来，这正好符合敏捷开发的思想，饭是要一口一口吃的，项目也是一样，不可能一次性把所有需求都搞定。所以，我们需要通过一个版本一个版本来完成，在做版本的工作任务分解的时候，一定要将任务分解到不能再分为止，任务的粒度一定要细，如果太粗，则很有可能会出现一些任务被忽略，从而影响整个项目的进度和计划。

一般的工作任务分解方法有：按照产品的物理结构分解、按照产品的功能模块进行分解、按照实施过程来进行分解、或者是按照项目的地域分布等。比较常用的是按功能模块来进行分解，再结合产品的实施过程来进行分解。

这里需要注意的是，分解任务的过程中，需要将任务给描述清楚，否则团队成员会不太明确自己究竟要做成什么样子或达到什么样的目标才算任务完成。

项目的工作任务分解，其实也可以运用我们之前提到过的MECE 原则去进行检查，工作任务必须全面、清晰、细分，任务责任需要到人，每一个子任务都能够估算工作量和工期。

任务分配好了，但总有轻重缓急之分。项目里的优先级排序，就是需要产品经理去识别项目任务清单里的各种任务的相互关联和

依赖关系，并根据自己对需求优先级的判断，来对项目里各项任务的先后顺序进行安排和确定。

通俗地来说，产品经理要定义的就是先做哪些任务，后做哪些任务。其实这个时候往往又会用到我们在需求管理中使用到的工具KANO模型，通过明确任务的重要度和紧急度来梳理任务的优先级，优先处理的是重要又紧急的任务。

在处理任务的优先级安排时，有另一个非常重要的点需要明白，那就是有些任务与任务之间，存在着前置后置关系，只有在完成了一项任务的时候，我们才能开始下一个任务。所以在规划优先级的时候，需要把这种情况给考虑进去。

3、计划呈现——甘特图或其它

很多项目管理的书籍都推荐使用甘特图来进行项目进度计划的制作和呈现，一般都是通过微软的Project、OpenProj等专业软件进行绘制，还可以通过这些专业软件直接查看项目的关键路径。也有一些产品经理或项目经理直接使用Excel来制作项目进度计划表，毕竟他们对于表格的操作熟练程度已经足够驾驭一个项目的进度计划制作。

我是个比较注重用户体验的人，所以，上面两种工具其实我都不怎么使用，一般来说，我更喜欢通过团队协作软件中的项目管理功能，来实现项目计划的呈现。

比如下面这样的：

4、风险控制

通俗地来说，风险就是发生不幸事件的概率。任何一个项目都有风险，这就好比任何一次手术都有风险一样，风险其实是无处不在的，是一种不以人的意志为转移，独立于人的意识之外而存在的事物。

我们先来看看常见的一些风险有哪些：

a、客户没有参与项目

如果你们公司的一个项目恰好是给客户做的一个定制产品，但是在项目启动、计划和执行的阶段，都没有客户的参与，客户只是在最开始的时候给了一份文档，然后在项目收尾的时候来进行验收，中间没有丝毫地参与到项目中来，那么客户一旦发现最后的成果和自己当初设想的需求相去甚远，结果就会变得非常糟糕。客户有可能因此就不同意验收项目，要求项目团队重新返工开发，这个时候造成的工作量及时间的损失、及对相关事件的影响则是不可估量的。

b、需求不明确或不完整

产品经理的需求说明文档出现不明确或不完整的情况，项目出现风险的概率也会比较大，因为项目的开发成员都是围绕着需求设计文档来进行开发、测试的，如果产品经理能够随叫随到，和开发及时

讨论清楚需求，则还能挽回一定的损失；而如果是异地开发，则整个项目便会比较悲催。

c、项目计划的不合理

项目没有如期完成，很有可能本身项目计划就是有问题的。比如说，团队成员的分工不合理、工期安排的也不合理（一般3个月才能完成的任务，非得要求1个月之内要上线）、资源没有配置到位、工作任务的分解没有细化没有责任到人（这样就会导致项目组的团队成员对自己的任务不太清晰，即使分解了，没有指定到人，也会发现影响项目进展）、还有一个就是任务的优先级安排的不合理，导致后面任务的完成受到影响等。

d、团队成员的精神状态

一个项目能不能如期按时按质地完成，其中最主要因素还是人的因素，因此团队成员的精神状态也是影响项目成败的风险之一。如果项目成员都如Scrum敏捷开发中提到的团队成员一样，都是自发组织和管理，参与项目的积极性比较高，项目风险就会大大降低。如果项目成员工作态度有问题，互相之间经常推诿任务责任，经常互相埋怨，那么项目的成果则很令人担忧。

e、领导变更

这里的领导变更，主要是指项目开发到中途，领导突然说这个需求不对，应该朝另一个需求方向开发，那么我们就称之为领导变更。这里的变更，大致分为两种情况，一种是不太伤筋动骨的，也就是只是小的需求修改，不涉及底层架构的重建；另一种呢，则是产品的规