项目管理技能，作为产品经理你还没掌握吗？

原码诗 2023-07-28 15:51:02

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

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

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

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

产品经理的需要掌握的项目管理技能

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、产品、测试都需要在场，以免上线出现问题，至少大的项目要做到如此，方能规避上线后给用户第一时间造成的风险。
上线后测试：上线后，必须在正式环境再测试一遍，这也需要测试、产品提前做好准备，并且有相应研发在场随时解决问题。