互联网产品管理属于复杂的工程管理，因此对产品经理和项目经理的能力要求在逐年增加。

几年前，我惯于单兵作战，秉持着有活抢着做的观念工作，一个人大包大揽什么都做，对于产品的管理基本上依赖对自我的管理来完成，结果并不理想。后来我有机会担任产品总监后，才逐渐形成了最适合自己和团队的产品管理方法，并非说有权限了才能实施这些方法，而是这些方法只有在一个完整的环境中才能更好地开展。

因此，以下的内容或许更多地面向那些正在从事产品管理工作的同仁，也部分解答了有些朋友私信我的关于产品工作中为何总是容易碰壁的原因。

一、什么是产品管理？

产品管理工作严格说是产品经理工作的一项重要内容，在有些团队中，也被称之为项目管理，国内对这两个概念并不会严格区分，所以有些公司会有项目经理和产品经理，而另外一些公司只有产品经理。

产品管理的概念范围实际上是小于项目管理的，但继承了项目管理的一部分属性，其中有最为关键的三个特点：

1. 独特性：有时也被称为一次性，每个项目和项目管理的过程都存在差异性，都不一样。哪怕相同的需求，但是不同的人参与，不同时期的外部环境不同都会带来变化。
2. 临时性：项目都有明确的开始时间和结束时间，开始时间和结束时间所持续的时间称为项目的周期或工期，项目的临时性不意味着项目周期短，另外项目是临时的，但是项目的交付成果有的却是永久的。
3. 渐进明细：项目相关方对项目的要求/产品特征以及管理要素的认识是一个渐进的过程。

产品的管理工作，其定义简单，但由于环境复杂多样，组织的管理意识层次不齐，特别在创业型企业中，想要养成良好的产品管理习惯和成体系的流程困难重重。这也是许多产品新手经常感到困惑的原因，工作确实繁忙，每天都做了很多事情，但更多的状态是不知道下一步该做什么。

二、组织环境决定管理方式

大部分项目失败是从源头开始的，创业者最爱说的一句话是：这个点子特别好，一定能成功！我相信好点子和创新是一个产品成功的开始，但这绝对不是最大的影响因素，反而往往是看起来不起眼的人事关系/组织架构影响了产品的发展方向。

为了偷懒，直接挪用了项目管理中的组织结构对项目的影响示意图，对于互联网产品类型的项目，其实同样适用。

对于一般的创业型公司，系统型组织结构最为常见，这是受资源可用性影响的，老板往往就是“产品经理“兼”项目经理”，因为资金有限，很难在前期招揽到优秀的管理人才，所以凡事亲力亲为，发现问题也常常是看到谁就分配给谁，没有额外精力去进行产品管理工作。当然，这也极大程度地增加了项目失败的风险。

更成熟的单一业务公司中，职能型组织结构偏多，因此身处其中的产品经理会经常觉得，部门之间的矛盾好像非常多，多到难以化解，要调用资源时往往是互不买账。于是就有产品经理觉得，自己的能力没有问题，主要是公司氛围太差劲了，其实是没有看明白自己的位置和所处的组织结构。

对于业务更为广泛的公司而言，往往按照项目导向或者强矩阵来开展工作，而这些项目成长起来后，甚至可以脱离母体生存，形成新的公司。这类组织结构下的产品经理会有两个选项，一个是承担起整个的产品管理压力，另一个是公司另外安排项目经理，产品经理为其提供对于商业论述和产品设计方案等方面的可靠输出。

其他还有一些组织结构，都有各自的特点，如果常常觉得自己的工作有阻力，我建议各位产品工作者从了解公司的组织结构开始，从头了解自己工作的意义。当然，正如前文所述，也经常存在公司本身忽视组织结构重要性而导致分工不当的场景，理论都是完美的，但执行起来却是错漏百出，那就需要单独进行分析和判断，不在此处赘述。

三、管理工作的生命周期

在管理领域，通常认为好的产品项目管理模式，是成体系/可进化/约定俗成的。根据国际PMI的标准，我们将项目管理分为五个过程十大领域。

五大过程组分别是：启动/规划/执行/监控/收尾。

十大领域分别是：整合管理/范围管理/时间管理/成本管理/质量管理/资源管理/沟通管理/风险管理/采购管理/干系人管理。

在不同的过程阶段，产品的管理者需要针对各个知识领域做各种各样的工作，从上面的表中可以看出，规划过程组的工作是远远多于其他过程组的，这由绩效成本曲线决定：计划越周密，在执行/监控/收尾过程组中产生的风险成本就越少。

四、产品管理流程

在我的定义中，更希望将产品经理和项目经理的职能界限分开讨论，但在产品管理工作过程中，我们也常常发现，产品经理很大程度上承担了一部分项目经理的职能。但在接下去的讨论中，我仍然将其严格分开说明。

互联网产品管理属于复杂的工程管理，因此对产品经理和项目经理的能力要求在逐年增加，这些要求集中体现在对风险和资源成本的判断上。

我们常常说互联网产品经理是越老越吃香，那是因为随着经验的累积，从业者对于不同知识领域的考虑维度越来越细致，真正能够做到运筹帷幄决胜千里之外。而初级的产品工作者，在这些方面很难做到面面俱到。

系统性地学习产品管理流程，在我看来，其实是从业者的第一课，也是漫长职业生涯中一直需要反复验证的课题。

1. 制定项目章程

在制定项目章程之前，我们有一些必须要做的工作，那就是对我们将要做的产品进行商业论证，这往往是整个高层团队去决策的事情，其中包括对产品在宏观价值上的定义，对资金流的预估和测算，对市场的预测和判断。在很多公司，这个环节往往会被遗漏掉，项目在启动前如果未能经过全局性的判断，在后期执行过程中以及完成项目后有极大的可能出现纰漏。

制定项目章程的过程，就是一个定义产品目标的过程，项目章程中包含以下几个最重要的信息：

1. 产品的目的；
2. 由谁发起；
3. 授权由谁管理；
4. 产品描述；
5. 产品的高水平要求（难点）；
6. 总预算是多少；
7. 启动风险有哪些；
8. 里程碑；
9. 基本验收标准；
10. 管理人的授权范围以及反馈制度；
11. 发起人的书面签字授权。

项目章程的重要性在于，保证一个产品的启动具有其合理性与合法性，而非“拍脑门”的产物，产品经理常常会在项目章程制订前做充分的市场调研和竞品调研，这就是商业论证的一部分。而一旦经过商业论证后，公司高层决定启动项目，那么就会由发起人委派产品经理或者项目经理进行接下去的一系列为达到目标而进行的工作。

2. 识别干系人

识别干系人，通俗地说，就是找到和这个项目相关的所有人，可能是利益相关方，也可能是发起人，也可能是某个资源，也可能是客户。当我们在做具体的产品规划前，第一件事情不是急于动手写PRD，而是找到在这个产品中，我们需要考虑哪些人对产品的影响，而他们对产品的看法有时候往往会影响后续的实施。

应该有不少产品经理面对过这种窘境，产品都即将上线了，这个时候被某个上级指责说做的有问题，和他想的不一样。还有一些时候，产品做着做着，就多出了一些需求，上线时间一拖再拖。这些问题产生的根源就是没有在项目初期做好干系人的识别，导致在规划阶段没有将这些干系人的影响考虑在内，从而产生不必要的内部管理成本。

3. 创建WBS

项目章程确定后，项目经理召集干系人开项目启动会，并且在会后开始进行范围管理相关的工作。范围管理中的收集需求，定义范围等等，就是产品经理最为熟悉的工作——撰写产品需求文档，这个各有各的标准和习惯，因此着重讲一讲创建WBS。

WBS全称为Work Breakdown Structure，即工作结构分解，把项目按阶段可交付成果将项目工作分解成较小的，更易于管理的组成部分的过程。一个宏观的任务，被一块一块地分割成彼此独立互不干扰的小任务，产品经理尤其要注重对这种结构式思维的锻炼，才能在设计产品时同时兼顾创新性和可行性。

大家看到上面这个案例会觉得很熟悉，这不就是我们常常画的思维导图吗？没错，这就是创建WBS的输出文件，但不同于一般的思维导图天马行空随意涂鸦，WBS在制作时有几个明确的规定：

• 包含关系：分支上下100%包含；
• 不可再分：最底层相对独立不可再分，最小可交付成果；
• 信息透明：分解到可以充分估算完成该成果所需的时间/费用/资源等；
• 独立责任：分解到可安排一个责任者。

因此我们可以说，当创建WBS的工作完成时，我们已经知道产品的范围边界在哪里，做什么和不做什么得到了解释。

4. 制定进度计划

产品管理者与开发人员往往在排期二字上产生分歧，一边觉得交付时间太晚，一边觉得开发时间不够，如何合理制定进度计划是解决这个矛盾的关键点。在WBS的基础上加上对活动资源和顺序的规定，就能够制定出进度计划，一般我们会使用一些工具和方法，比如说Omniplan和Project。

上图所示的甘特图就是非常典型的用于显示进度计划的技术，左侧是层级分解的任务列表，右侧是可视化的时间区间，组合成了包含任务定义/开始时间/结束时间/持续时间/任务优先级/资源约束在内的进度计划，而开发人员只需要估算具体子任务的持续时间，就可以计算出整体的排期。

制定进度计划的核心在于估算活动资源和排列活动顺序，估算活动资源的方法有很多，比如：三点估算法等等，这里就不展开来讲，有兴趣的朋友可以百度或者私聊我咨询。排列活动顺序的方法主要是关键链法和关键路径法，活动之间往往由关联性，活动A完成后才能继续活动B，活动B和活动C之间存在资源竞争关系，因此不能同步进行。只有充分考虑了这些制约因素，才能够制定出合理可行的进度计划。

5. 制定预算

身边有产品朋友总是和我抱怨，不明白为什么产品经理还需要在做完方案之后参与制定预算，他们都觉得这是财务的工作，这就是工作中的常见误区。制定预算的工作，不参与具体业务执行的财务人员往往无法获得第一手信息。

通常情况下，产品经理将根据投入的资源和预期的回报来评估这个项目是否值得去做，他才是最了解预算的人，因此这项任务落在产品经理头上并不奇怪。

预算和进度计划一样，是通过各项活动所需要的子预算组合得到的，主要包括项目本身需要的成本（人力时间成本/采购成本等等）和管理需要的成本。前者是通过活动使用计算得到，而管理所需要的成本往往是项目成本的10%到15%。

因此我们的预算，在不考虑各种干扰因素或者不可控因素的情况下，是总体成本的110%到115%左右。当项目中遇到了不可预测的风险时，就需要动用这多出来的部分来应对。

6. 实施整体变更控制

由于篇幅有限，资源管理/沟通管理/风险管理/采购管理/干系人管理中的大部分内容就不在这一篇文章中一一去讲，如果有需要可以私下沟通。当然，如果问的人多也许会考虑另外花点时间写一篇来说明一些细节。

重点想要说的是如何应对变更。

我们监控产品的开发实施过程，有时候突然发现一些预料之外的事情，比如前面提到的，未将核心干系人的意见纳入到产品中，或者说发现了一些新的风险将打乱原先的计划，这些都是随时可能发生的事情。

在实施整体变更流程之前，首先要做的事情是了解需要变更的原因和变更可能带来的影响。这些影响可能包括进度/质量/资源/成本/采购方/干系人等所有我们前面提及的知识领域，这要求产品经理或者项目经理召集各位在这个领域的专家以及团队成员一起来协助评估变更的影响范围。

按照正规的流程，我们有以下步骤：

1. 有人提出变更申请；
2. 产品经理/项目经理召集小组开会讨论评估变更；
3. 将评估结果汇报给需求变更控制委员会；
4. 根据需求变更控制委员会的决议实施变更并记录变更过程；
5. 更新问题日志。

这里有两个新词汇：一个是需求变更控制委员会，一个是问题日志。

需求变更控制委员会往往是一个由公司高层组成的团队，该团队中的成员有承担需求变更带来的影响的能力，在有些公司，它就是老板一个人乾纲独断，而在更大规模的公司中，可能是股东或者董事会来决策。它由哪些人组成并不是最重要的，最重要的是这个团队将负责根据产品经理提交上来的需求变更及评估报告来判断是否允许通过变更。

我和多个公司打过交道，发现越是不注重变更控制流程的团队，其团队氛围和项目执行结果往往越差，这是有道理的，如果在规划阶段没有很好的定义好产品需要做的事情，反复变更需求时又不按照标准的变更控制流程走，每个人都会下意识地认为制定计划是没有意义的，只有尽可能让需求变更不那么随意，才能反向彰显出产品管理计划的重要性。

问题日志是用于记录产品管理过程中出现的问题的，一旦出现了变更，往往意味着原先的规划是存在一定问题的，将问题记录下来，才有可能在今后的管理工作中提前规避掉。

总之，实施变更控制流程是整个产品管理环节中，经常被忽略但又极为重要的环节之一，掌握了这个技巧，产品经理的在应对问题上的能力将会有长足的进步，这远不是一个“原型”经理能做的事情。

7. 结束项目或阶段

虽然很多环节都跳过了没有讲，但是结束项目或阶段这个环节，仍然没有办法草草地一笔带过。

我们做事情常说一句话：有始有终。这在产品管理工作中同样如此。

产品上线了，组织一场结案会议，讲一讲项目中遇到的问题，对项目的成果进行汇报，提醒大家各自在工作中表现得出色或者不足的部分，给工作画一个阶段性的句号。当然，还可以在会后组织一场小小的团建来庆祝项目收尾。

在产品管理过程中需要那么多的技巧和工具，管理者依靠发起人的授权开始了整个项目，并在项目过程中与成员们磨合出默契，而在结束项目的过程中，通过回顾和展望往往能够碰撞出更多的情感。

尾记

产品管理是由方法和工具指导的艺术，单纯依靠人格魅力获得产品成功的案例至今我还没有看到过，反而是善用产品管理方法和流程但不拘泥于其中的团队创造出无与伦比的价值。

互联网大公司之所以能够源源不断地产出高质量的产品，其根本原因就在于对产品管理流程的合理运用与控制，大公司出来的创业者容易成功的原因也在于此。而中小型公司必须意识到，想要在市场中立足，就需要充分理解产品管理方法，并根据自身公司的实际情况来制定出适用的流程来。

而身为产品管理工作者，经验的积累是一部分，借鉴好的方法和理论来降低走弯路的可能性也是非常重要的，希望本文中分享的这套成体系的产品管理方法可以帮助到大家。

实践出真知，也希望大家通过实践不断自我验证，在产品职业生涯上越走越顺利，敬谢支持！

本文由 @路遥 原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议。