产品项目管理的流程

1、产品工程管理的流程 度”，觉得第一个工程做到尾声，需要总结一下第一个工程关于工 任何一个工程，能够被启动，至少从战略层面是得到公司认同 和支持的，也就意味着这个工程是要背负着实现公司的某一个战略 目标而存在的。产品经理在工程启动前，有这么几个问题需要提前 这个时候，作为产品经理的你需要去了解这个工程的来龙去 量远远比你大且比你多，所以通过和他们沟通再加上自己理解，就 能够对工程立项的原因有一个清晰的认知。当然，有时候工程立 项，可能就是产品版本的定期迭代，这个时候产品经理对为什么要 产品经理作为工程的负责人，是一定要明白整个工程的目标是 什么，然后在里面找出最核心的目标。例如有的工程是时间（越

2、快 越好，花多少钱无所谓），有的工程是钱（做慢点没关系，但是要 对，一定要写下来，因为口说无凭，再一个写下来的东西才能 关于干系人，宝洁的方法论是找出PACE。P是Participant 司的产品）在日常的工程工作中，恐怕不会有这么繁琐的流程，所 工程相关人员，可以从这几个角度去考虑下，如哪些人或部门 等。当然，在互联网公司，常见的相关人员也就是老板、产品经 理、工程经理、工程团队（包含设计、开发、测试、运维等）及用 找到了工程的相关人员后，现在你要做的就是把团队成员绑到 们于这个工程的需求是什么，做这个工程可以给他们带来什么。如 的老板沟通无效，还有最后一招，感情投资，请那个成员撸串、吃 通

3、常来说，这个时候需要开一个工程启动大会。这个启动大会 的目的是召集工程团队成员，成员之间初步认识一下，产品经理主 持会议，然后清楚地传达工程要做什么，目标是什么，为什么要 做，怎么做，谁来做等等。另外，跟所有的启动大会一样，工程的 启动大会，也需要给团队成员来点鸡汤、打点鸡血。产品经理需要 去统一团队的思想，明确团队的管理和运作方式，以及团队的沟通 机制等，产品经理需要发动团队成员积极参与工程，并高质量地完 这个时候，工程相关的文档其实应该已经完成了，因为只有当 详细的产品需求文档有了之后，开发团队才能估算工程时间及里程 碑等。也有另一种情况，那就是工程本身包括了需求分析阶段，所 以详细的需求

4、文档是在立项之后才开始进行调研和撰写。不管怎么 说，明确的产品需求和详细的需求文档，都是工程得以顺利进行的 根本前提保障，所以，产品经理的规划能力、撰写文档的能力在这 完成了工程的启动，接下来就要开始进行工程方案了，工程方 案，其主要工作就是工作任务分解，任务优先级安排，资源、工 工作任务分解，在工程管理中也有专门的术语叫做“工作分解 ）， 组。它其实归纳和定义了工程的整个工作范围，从工程目标开始分 产品经理在每一个版本的迭代规划中，都需要从产品需求池中 捞一些比拟重要的需求出来放到工程需求里来，这正好符合敏捷开发的思想，饭是要一口一口吃的，工程也是一样，不可能一次性把 在做版本的工作任务分解

5、的时候，一定要将任务分解到不能再分为 止，任务的粒度一定要细，如果太粗，那么很有可能会出现一些任 一般的工作任务分解方法有：按照产品的物理结构分解、按照 产品的功能模块进行分解、按照实施过程来进行分解、或者是按照 工程的地域分布等。比拟常用的是按功能模块来进行分解，再结合 这里需要注意的是，分解任务的过程中，需要将任务给描述清 楚，否那么团队成员会不太明确自己究竟要做成什么样子或到达什 工程的工作任务分解，其实也可以运用我们之前提到过的MECE 原那么去进行检查，工作任务必须全面、清晰、细分，任务责任需 就是需要产品经理去识别工程任务清单里的各种任务的相互关联和 依赖关系，并根据自己对需求优先

6、级的判断，来对工程里各项任务 通俗地来说，产品经理要定义的就是先做哪些任务，后做哪些 任务。其实这个时候往往又会用到我们在需求管理中使用到的工具 在处理任务的优先级安排时，有另一个非常重要的点需要明 白，那就是有些任务与任务之间，存在着前置后置关系，只有在完 成了一项任务的时候，我们才能开始下一个任务。所以在规划优先 很多工程管理的书籍都推荐使用甘特图来进行工程进度方案的 进行绘制，还可以通过这些专业软件直接查看工程的关键路径。也 表，毕竟他们对于表格的操作熟练程度已经足够驾驭一个工程的进 我是个比拟注重用户体验的人，所以，上面两种工具其实我都 不怎么使用，一般来说，我更喜欢通过团队协作软件中

7、的工程管理 通俗地来说，风险就是发生不幸事件的概率。任何一个工程都 有风险，这就好比任何一次手术都有风险一样，风险其实是无处不 在的，是一种不以人的意志为转移，独立于人的意识之外而存在的 如果你们公司的一个工程恰好是给客户做的一个定制产品，但 是在工程启动、方案和执行的阶段，都没有客户的参与，客户只是 在最开始的时候给了一份文档，然后在工程收尾的时候来进行验收，中间没有丝毫地参与到工程中来，那么客户一旦发现最后的成 果和自己当初设想的需求相去甚远，结果就会变得非常糟糕。客户 有可能因此就不同意验收工程，要求工程团队重新返工开发，这个 时候造成的工作量及时间的损失、及对相关事件的影响那么是不可

8、产品经理的需求说明文档出现不明确或不完整的情况，工程出 现风险的概率也会比拟大，因为工程的开发成员都是围绕着需求设 计文档来进行开发、测试的，如果产品经理能够随叫随到，和开发 及时讨论清楚需求，那么还能一定的损失；而如果是异地开发，那 工程没有如期完成，很有可能本身工程方案就是有问题的。比 位、工作任务的分解没有细化没有责任到人（这样就会导致工程组 也会发现影响工程进展）、还有一个就是任务的优先级安排的不合 一个工程能不能如期按时按质地完成，其中最主要因素还是人 发组织和管理，参与工程的积极性比拟高，工程风险就会大大降 这里的领导变更，主要是指工程开发到中途，领导突然说这个 需求不对，应该朝另

9、一个需求方向开发，那么我们就称之为领导变 更。这里的变更，大致分为两种情况，一种是不太伤筋动骨的，也 就是只是小的需求修改，不涉及底层架构的重建；另一种呢，那么 是产品的规划和定位不够清晰，导致修改起来比拟伤筋动骨，一个 需求方向的改变，就可能让开发重新搭建后台架构，前端很多页面 也得跟着修改。当然，有时候产品经理也常常会犯这样的错误，就 是中途变更需求，这就要求产品经理在工程筹划的时候就把需求都 这里说到的技术风险，指的是工程的开发组成员，他们在用代 码实施工程的过程中，会发生一系列意想不到的情况，比方开发去 可能最后的结果是光光是调研事件就话费了一两个礼拜，留着开发 的时间几乎仅剩无几。比方说网站挂了，一处理就一天时间进去 这里列举了一些常见的技术风险，产品经理们在做工程管理的 那说了这么多的风险，有没有什么比拟好的方法来躲避这些风 大家有没有同感：出现工程偏离日程安排的情况，很少是因为 工作消耗了比预期更长的时间，更常见的原因是，根本不在方案中 的工作使工程泥足深陷？如果身兼工程经理的你，深有同感，那 么，我们就可以体会到，工程中的风险是可以互通的。昨天