编辑导语：产品经理需要具备哪些能力呢？ 35%的项目管理能力，15%的个人能力，20%的业务能力，15%的技术能力，15%的沟通处理冲突能力。那么问题来了，既然项目管理能力这么重要，产品经理应该如何去提升它呢？

产品即作品，一个产品经理需要对最终创造的产品负责，作品生产过程中的流程、涉及到的人事物、发展脉络、抗风险能力需要做到心中有数。

类似于杂志社的编辑、电影的导演、音乐的制作人一样，产品经理作为一个统筹性质的职业，对产品的把控是其需要掌握的职业技能之一，在互联网行业中，称之为项目管理。

一、与项目管理有关的几种模型

在计算机系统架构设计中，业界会将常用的软件开发流程归纳为模型，如果产品经理在产品项目推进过程中感觉到冲突，可能是公司采取的开发模式不同。以下是我了解到的一些模型：

1. 瀑布模型

瀑布模型是将软件生存周期的各项活动规定为按固定顺序而连接的若干阶段工作，形如瀑布流水，最终得到软件产品。由1970年温斯顿·罗伊斯（WinstonRoyce）提出，直到80年代早期，它一直是唯一被广泛采用的软件开发模型。

这种模型常用于大型产品的开发和管理，若产品一个环节出错，牵扯到的部门较多，容易返工反而不利于开发。

当开发的系统是有积累的已知领域和行业，也非常适用，现在大的网络公司往往采取这种模式。或者对安全和性能有极其严格的要求，容不得半点疏漏，例如航空航天软件，这样用瀑布模型的话能够有效地控制每一环节，所有流程都有文档可循。

2. 原型模型

原型模型是在瀑布模型基础上一个重要环节的推进，也是产品经理最常接触和了解的形式。

80年代后，随着计算机辅助设计的应用，产品造型和设计能力得到极大提高，可以在产品设计完成后，批量生产前，制出样品以表达设计构想，快速获取产品设计的反馈信息，并对产品设计的可行性作出评估、论证。

几乎目前所有的系统，设计都适用并且无法避免地涉及到这种模式。

3. 螺旋模型

1988年，巴利·玻姆(BarryBoehm)正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和原型模型结合起来，强调了其他模型所忽视的风险分析。

螺旋模型基本做法是在“瀑布模型”的每一个开发阶段前引入一个非常严格的风险识别、风险分析和风险控制，它把软件项目分解成一个个小项目。每个小项目都标识一个或多个主要风险，直到所有的主要风险因素都被确定。

特别适用于庞大、复杂并具有高风险的系统，对于这些系统，风险是软件开发不可忽视且潜在的不利因素，它可能在不同程度上损害软件开发过程，影响软件产品的质量，例如金融系统、公共事业系统。

二、产品经理的项目管理能力

由于公司的开发模式、营业规模、行业领域不同，产品经理往往要兼顾项目管理的工作；并且产品经理要把控整个项目、整个产品、整个迭代，项目管理能力也是产品经理的基础能力之一。

1. 经过验证的项目管理流程

好的项目管理其实非常简洁明了，一个20-50人的研发团队，所涉及的项目不会超过20个。而再往大了说，大公司的团队对具体某个部门的项目把控已上升到OKR的管理模式。

因此，如果项目管理的模式过于复杂，反而不利于团队对项目的理解，产品经理实际实施阶段的项目管理基本上只需要做到：

1）明确产品需求

产品经理在需求前期要判断并作出设计，这部分更属于产品经理需求分析的能力。在项目管理中，需要注意的是，需求与各方的明确，以减少后续需求插入和变更的风险。

2）确定产品迭代内容

一般来说，采用的方式为评审。评审后形成共识，这个功能要做如何做什么时候做好。

3）达成排期

这是项目管理中最关键的环节，首先要确认好工时，最好对每个功能小到接口大到技术问题的解决都确定好工时，并且对应到相应的研发人员。在确认工时阶段，工时是可以根据研发调研情况自行调控的。

在大致确认好工时后，一定要按工时进行项目排期，不管项目是大是小，都确定好一个交付时间。这个时间可以根据研发人员上一个项目的完结时间依次顺延。

最后，不要忘记联调和测试时间。

4）明确重要时间点

是指每个项目的交付时间、联调时间、测试时间、上线时间、发布时间等，只有明确好重要时间点并在团队中形成共识和契约，整个项目管理才会在一个可控的范围内进行。

5）把控项目风险

最常见的项目风险就是需求变更，或无法按照如期完成。这时，产品经理一定要在第一时间了解项目风险，并解除。

2. 不良项目管理导致的问题

不良的项目管理相当于一段有bug或者冗余的代码，在产品开发过程中需要注意的不恰当的管理方式：

1）项目无具体排期表，多个项目无连接

迭代过程中，会有一些误区，排期由研发来定，而产品经理在评审之后，难以确定某个模块、一个功能或整个项目的交付时间。

采用这样项目形式的公司往往追求一种灵活的研发方式，并以研发为主来调控整个项目，意为研发驱动，例如让研发作为一个项目的负责人。

这种形式在初期的创业公司非常受欢迎，而此时产品经理往往作为一个界面设计者，而缺失了多个项目的连接者和管理者，多个项目管理陷入空白。

2）需求由上级触发，随意插入项目、延长工期

产品在研发过程中，往往确定性低。若项目管理、研发排期分配不够合理、没有公开并形成公认文件。随时会由于各种各样的原因空降上级，对当前项目作出指示，加入某某需求或改动某某需求。更有甚者，会直接插入一个项目，延长了工期。

这个问题主要在前期需求和项目立项启动时，调研不够充分，并且没有形成相应的契约。产品总是在不断迭代升级的，需求的变更不可避免。但一旦涉及到来回变更、随意插入、延长工期的变更，会变成整个团队项目管理中的风险。

三、项目管理使用到的工具

1. 一个excel表就可以解决这一切

前面说到项目管理需要简洁明了更有利于团队理解，因此一般来说，项目排期表一个Excel表格就可以解决这一切，如果不涉及到牵扯20人以上的项目，无需甘特图。

至于表格里的内容也可根据项目大小和团队需要进行调控，工时、相应研发、交付时间是必不可缺的。

2. 过程中进度把握：项目管理工具

几乎每个公司都会有其相应的管理工具，有的是公司自研的系统，有的公司使用付费系统，有的使用Jira、teambition等系统，核心功能差别不大，使用熟练，达到团队协作顺畅即可。

四、产品经理项目管理的关键节点

项目管理中的关键节点皆可具化成相应时间点，以便更好的调控进度。

1. 重要时间点

• 后端建表时间：若是一个大项目的研发，一般需要进行后端建表，那么在确定完产品研发方案后，可与研发人员敲定一下后端建表时间，产品可适当参与建表，以明晰整个项目映射关系，并且可以double-check一下，以免一些小疏忽影响整个项目。
• 前后端联调时间：在研发项目完成前会进行前后端联调，这是前后端研发交付的第一步，需产品进一步跟进。
• 研发完成时间：这是最终研发开发完成、自测完成，交给测试的时间。是整个项目完成的基石，若这个阶段平稳度过，项目风险大大下降。
• 测试时间：测试需参与评审，并提前做好项目测试相关文档，在研发提交分支后，在测试环境中进行测试，最终交付给业务和产品。
• 交付时间：交付时间是上线时间的前夕，产品需让业务参与，确认产品研发结果，产品需进行自测，多方确认后，准备上线。
• 上线时间：往往上线会统合多个功能项目一起上线，一般团队也会规定每周几为上线时间，可根据公司情况自行调配。需要注意的是，上线时，该项目的所有研发、UI、产品、测试都需要在场，以免上线出现问题，至少大的项目要做到如此，方能规避上线后给用户第一时间造成的风险。
• 上线后测试：上线后，必须在正式环境再测试一遍，这也需要测试、产品提前做好准备，并且有相应研发在场随时解决问题。

2. 里程碑

一般较大的项目，例如涉及到20人以上、跨时2个月以上等，需要立个里程碑，里程碑一般设立在一个节点:

1. 某个feature研发完成；
2. 进入某个阶段：灰度/ABtest；
3. 检验团队的工作成果：管理层需要看到的效果。

3. 晨会&站会

同样的较大的项目，时间跨度较长，需在研发过程中同步进度，这时候晨会站会就变得非常必要。每日/每周明确每人开发进度灵活调控，及时上报研发问题，快速响应解决。

五、项目管理中的风险把控

1. 出现需求变更

研发过程中不可避免的会出现需求变更。接到变更需求时，1.进行需求评估。2.划分需求优先级。3.评估工作量大小。4.需求做与不做的影响范围。

公式非常简单，只有当优先级高、工作量小、不做的影响范围危害极大时才能插入项目，其余任何组合可放在下次迭代或另起项目跟进。

2. 出现新项目

一个团队会处理多个项目，在一个项目受到另一个项目冲撞时，首先要明确互斥的项目中有没有重叠的人员，将重叠人员按照项目先后顺序进行工时排序后是不是最佳组合，若为最佳组合，则新项目上线时间顺延。

若非最佳组合，可进行人员调配，达到最佳。再者，需调研并与全团队明确项目风险与重要程度，将项目进行排序，更改排期顺序。

3. 预留时间

几乎所有项目，都会延期，区别在于延期长短。而产品在风险管控中要做的，是对这延期长短的把控：

1. 根据团队情况，预留出应急时间、延期时间；
2. 留意每次预留时间的反馈，并进一步调控；
3. 公开知道预留时间的人不能超过3位，哪怕大家心里都知道有预留时间，也不能形成公认现象。

4. 项目复盘

不同团队的研发风格、项目管理模式不同，这是一个不断磨合和适应的过程。让所有人参与进项目管理中，提高团队的风险和守时意识。

因此每次项目后，尤其是大项目后需进行项目复盘。跌过一次的跟头不再跌这是把控风险的重要方法。相当于团队在一起枚举各种研发中出现的风险，慢慢形成环环相扣的团队。

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

题图来自 Unsplash，基于 CC0 协议