这篇文章，我们来开始讲讲好的项目管理流程大概是什么样子的。
大体说来，一个项目管理的流程分为这么几个阶段：
项目启动——项目计划——项目执行和监控——项目收尾
如果用一幅图来表示的话，大概会是这个样子的：
在整个项目的运转过程中，从最开始的来自领导的战略规划启动了项目，到前期的项目计划、需求转化与中期的项目执行和跟进，以及后期的项目收尾总结会，每一个环节都有产品经理的身影。尤其是在初创公司，产品经理大多数的时间也担任项目经理这样一个角色。所以对于初创公司的产品们来说，了解项目管理的大致流程，合理分配资源就显得更加重要了。
我们来一一梳理下，产品经理如果来负责一个项目的管理，在每一个阶段都要做哪些工作。
项目启动阶段
任何一个项目，能够被启动，至少从战略层面是得到公司认同和支持的，也就意味着这个项目是要背负着实现公司的某一个战略目标而存在的。产品经理在项目启动前，有这么几个问题需要提前去了解和熟悉：
1、为什么要立项？
2、项目目标是什么？
3、项目的相关人员都有哪些？
4、怎么立项？
第一个问题，为什么要立项？
这个时候，作为产品经理的你需要去了解这个项目的来龙去脉，最好的方式是和你的上级或者BOSS沟通，因为他们掌握的信息量远远比你大且比你多，所以通过和他们沟通再加上自己理解，就能够对项目立项的原因有一个清晰的认知。当然，有时候项目立项，可能就是产品版本的定期迭代，这个时候产品经理对为什么要立项恐怕是比谁都更清楚了。
第二个问题，项目目标是什么？
产品经理作为项目的负责人，是一定要明白整个项目的目标是什么，然后在里面找出最核心的目标。例如有的项目是时间（越快越好，花多少钱无所谓），有的项目是钱（做慢点没关系，但是要花最少的钱）。这些都可以通过跟你的领导聊一聊聊出这些信息，知道了项目目标后你需要把这个目标用准确的文字写下来。
对，一定要写下来，因为口说无凭，再一个写下来的东西才能成为所有人具体执行的方向和准则。
第三个问题，项目的相关人员都有哪些？
关于干系人，宝洁的方法论是找出PACE。P是Participant（参与者），A是Approver（审批者），C是Consultant（顾问），E是Executor（执行者）。当然，产品经理（尤其是创业公司的产品）在日常的项目工作中，恐怕不会有这么繁琐的流程，所以，也就遵循一切从简的原则。
项目相关人员，可以从这几个角度去考虑下，如哪些人或部门会受到项目结果的影响，哪些人可为项目提供资源（人、财、物）等。当然，在互联网公司，常见的相关人员也就是老板、产品经理、项目经理、项目团队（包含设计、开发、测试、运维等）及用户等。
找到了项目的相关人员后，现在你要做的就是把团队成员绑到自己的船上。你需要去了解团队里每个成员的核心KPI，也就是他们于这个项目的需求是什么，做这个项目可以给他们带来什么。如果这个项目没被囊括在这个成员的工作评价 list 里面，你需要去找他的老板沟通。根据我的经验，85%出工不出力的情况都是因为你的项目根本不会对这个成员的KPI有什么正向的帮助。当然，如果找他的老板沟通无效，还有最后一招，感情投资，请那个成员撸串、吃饭，利用感情让他帮你做好这个项目。
第四个问题，怎么立项？
通常来说，这个时候需要开一个项目启动大会。这个启动大会的目的是召集项目团队成员，成员之间初步认识一下，产品经理主持会议，然后清楚地传达项目要做什么，目标是什么，为什么要做，怎么做，谁来做等等。另外，跟所有的启动大会一样，项目的启动大会，也需要给团队成员来点鸡汤、打点鸡血。产品经理需要去统一团队的思想，明确团队的管理和运作方式，以及团队的沟通机制等，产品经理需要动员团队成员积极参与项目，并高质量地完成项目。
这个时候，项目相关的文档其实应该已经完成了，因为只有当详细的产品需求文档有了之后，开发团队才能估算项目时间及里程碑等。也有另一种情况，那就是项目本身包括了需求分析阶段，所以详细的需求文档是在立项之后才开始进行调研和撰写。不管怎么说，明确的产品需求和详细的需求文档，都是项目得以顺利进行的基本前提保障，所以，产品经理的规划能力、撰写文档的能力在这个时候就显得尤为重要了。
项目计划阶段
完成了项目的启动，接下来就要开始进行项目计划了，所谓的项目计划，其主要工作就是工作任务分解，任务优先级安排，资源、工期、成本估算，以及风险计划和沟通计划等。
1、工作任务分解
工作任务分解，在项目管理中也有专门的术语叫做“工作分解结构”（WBS），指的是以可交付成果为导向对项目要素进行的分组。它其实归纳和定义了项目的整个工作范围，从项目目标开始分解，逐层下降，每下降一层，代表对项目工作的更详细的定义。
产品经理在每一个版本的迭代规划中，都需要从产品需求池中捞一些比较重要的需求出来放到项目需求里来，这正好符合敏捷开发的思想，饭是要一口一口吃的，项目也是一样，不可能一次性把所有需求都搞定。所以，我们需要通过一个版本一个版本来完成，在做版本的工作任务分解的时候，一定要将任务分解到不能再分为止，任务的粒度一定要细，如果太粗，则很有可能会出现一些任务被忽略，从而影响整个项目的进度和计划。
一般的工作任务分解方法有：按照产品的物理结构分解、按照产品的功能模块进行分解、按照实施过程来进行分解、或者是按照项目的地域分布等。比较常用的是按功能模块来进行分解，再结合产品的实施过程来进行分解。
以微信公众号的开发为例，微信公众号的开发就涉及微信端开发和PC管理后台的开发，这个时候如果进行任务分解，最基本的方向就要分为微信端任务开发、PC管理端任务开发。而微信端任务开发，又可细分为需求梳理、产品设计、前端页面实现、后台接口支持、测试任务等；PC管理端的任务开发也是如此，也细分为需求梳理、产品设计、前端页面实现、后台接口支持、测试任务等，如果再细分功能模块，则可分为“群发消息”、“自动回复”、“用户管理”、“消息管理”等功能模块的需求梳理、产品设计、前端页面实现、后台接口支持、测试任务等；
这里需要注意的是，分解任务的过程中，需要将任务给描述清楚，否则团队成员会不太明确自己究竟要做成什么样子或达到什么样的目标才算任务完成。
项目的工作任务分解，其实也可以运用我们之前提到过的MECE原则去进行检查，工作任务必须全面、清晰、细分，任务责任需要到人，每一个子任务都能够估算工作量和工期。
2、任务优先级安排
任务分配好了，但总有轻重缓急之分。项目里的优先级排序，就是需要产品经理去识别项目任务清单里的各种任务的相互关联和依赖关系，并根据自己对需求优先级的判断，来对项目里各项任务的先后顺序进行安排和确定。
通俗地来说，产品经理要定义的就是先做哪些任务，后做哪些任务。其实这个时候往往又会用到我们在需求管理中使用到的工具KANO模型，通过明确任务的重要度和紧急度来梳理任务的优先级，优先处理的是重要又紧急的任务。
在处理任务的优先级安排时，有另一个非常重要的点需要明白，那就是有些任务与任务之间，存在着前置后置关系，只有在完成了一项任务的时候，我们才能开始下一个任务。所以在规划优先级的时候，需要把这种情况给考虑进去。
3、计划呈现——甘特图或其它
很多项目管理的书籍都推荐使用甘特图来进行项目进度计划的制作和呈现，一般都是通过微软的Project、OpenProj等专业软件进行绘制，还可以通过这些专业软件直接查看项目的关键路径。也有一些产品经理或项目经理直接使用Excel来制作项目进度计划表，毕竟他们对于表格的操作熟练程度已经足够驾驭一个项目的进度计划制作。
我是个比较注重用户体验的人，所以，上面两种工具其实我都不怎么使用，一般来说，我更喜欢通过团队协作软件中的项目管理功能，来实现项目计划的呈现。
比如下面这样的：
4、风险控制
通俗地来说，风险就是发生不幸事件的概率。任何一个项目都有风险，这就好比任何一次手术都有风险一样，风险其实是无处不在的，是一种不以人的意志为转移，独立于人的意识之外而存在的事物。
我们先来看看常见的一些风险来源有哪些：
a、客户没有参与项目
如果你们公司的一个项目恰好是给客户做的一个定制产品，但是在项目启动、计划和执行的阶段，都没有客户的参与，客户只是在最开始的时候给了一份文档，然后在项目收尾的时候来进行验收，中间没有丝毫地参与到项目中来，那么客户一旦发现最后的成果和自己当初设想的需求相去甚远，结果就会变得非常糟糕。客户有可能因此就不同意验收项目，要求项目团队重新返工开发，这个时候造成的工作量及时间的损失、及对相关事件的影响则是不可估量的。
b、需求不明确或不完整
产品经理的需求说明文档出现不明确或不完整的情况，项目出现风险的概率也会比较大，因为项目的开发成员都是围绕着需求设计文档来进行开发、测试的，如果产品经理能够随叫随到，和开发及时讨论清楚需求，则还能挽回一定的损失；而如果是异地开发，则整个项目便会比较悲催。
c、项目计划的不合理
项目没有如期完成，很有可能本身项目计划就是有问题的。比如说，团队成员的分工不合理、工期安排的也不合理（一般3个月才能完成的任务，非得要求1个月之内要上线）、资源没有配置到位、工作任务的分解没有细化没有责任到人（这样就会导致项目组的团队成员对自己的任务不太清晰，即使分解了，没有指定到人，也会发现影响项目进展）、还有一个就是任务的优先级安排的不合理，导致后面任务的完成受到影响等。
d、团队成员的精神状态
一个项目能不能如期按时按质地完成，其中最主要因素还是人的因素，因此团队成员的精神状态也是影响项目成败的风险之一。如果项目成员都如Scrum敏捷开发中提到的团队成员一样，都是自发组织和管理，参与项目的积极性比较高，项目风险就会大大降低。如果项目成员工作态度有问题，互相之间经常推诿任务责任，经常互相埋怨，那么项目的成果则很令人担忧。
e、领导变更
这里的领导变更，主要是指项目开发到中途，领导突然说这个需求不对，应该朝另一个需求方向开发，那么我们就称之为领导变更。这里的变更，大致分为两种情况，一种是不太伤筋动骨的，也就是只是小的需求修改，不涉及底层架构的重建；另一种呢，则是产品的规划和定位不够清晰，导致修改起来比较伤筋动骨，一个需求方向的改变，就可能让开发重新搭建后台架构，前端很多页面也得跟着修改。当然，有时候产品经理也常常会犯这样的错误，就是中途变更需求，这就要求产品经理在项目策划的时候就把需求都想清楚，尽量减少项目开发到一半需求突然变更的情况。
f、技术风险
这里说到的技术风险，指的是项目的开发组成员，他们在用代码实施项目的过程中，会发生一系列意想不到的情况，比如开发去做一个从来没有做过的功能，这个时候可能需要先进行技术调研，可能最后的结果是光光是调研事件就话费了一两个礼拜，留着开发的时间几乎仅剩无几。比如说网站挂了，一处理就一天时间进去了，原先手上的项目就只好拖延一天。
这里列举了一些常见的技术风险，产品经理们在做项目管理的过程中，还是稍微了解下比较好：
那说了这么多的风险来源，有没有什么比较好的方法来规避这些风险呢？
答案是有，但是依然比较难规避掉所有的风险。
大家有没有同感：出现项目偏离日程安排的情况，很少是因为工作耗费了比预期更长的时间，更常见的原因是，根本不在计划中的工作使项目泥足深陷？如果身兼项目经理的你，深有同感，那么，我们就可以体会到，项目中的风险是可以互通的。昨天的问题就是今天的风险，你的问题很可能就是我的风险。
因此，我们能做的比较好的一个方法就是，在项目初期，对上述风险来源进行逐一参考和排查，看看是否存在什么问题。当然，更加隐秘的风险，恐怕也不是靠这种逐一排查的方法来发现的，更关键的点还是在于对日常项目状态的洞察，这样才能把所有的核心风险都呈现出来。
风险管理是一件非常耗费心力的事情，产品经理如果兼职做了项目管理的工作，就必须要做好相关的心理准备，毕竟内心强大也是产品经理必须具备的一个人格特质啊。
