编辑导语：产品经理在日常工作中要负责整个产品的流程，项目经理是负责阶段性的工作，但是项目经理和产品经理工作范围有很多交集，所以产品管理和项目管理的差别很多吗？本文作者分享了关于产品经理和项目经理的相同和不同，我们一起来看一下。

自从进了产品经理这个圈子，时不时看到身边的一些朋友从从项目管理转到产品线上，经常会听到或者被问到的问题是，“你觉得产品经理和项目经理的区别是什么？”

我记得那时候我的答案是这样的“产品经理是产品的爸爸，负责着产品的诞生和整个生命周期；而项目经理则是负责阶段性工作，以最有效，最省成本的方式完成任务…”是的，我认为他们是两个不同的东西。

一、起因

让我想法有所改变，是发生在一次面试当中，那时候面试的是一个AI公司，在细分领域中算得上独角兽公司。

在面试的过程当中，我们聊一些关于需求管理，产品管理的内容，包括需求的筛选，以及如何让团队快速实现产品demo的实现方法等等。

聊完之后，面试官问了我一句：“你考了PMP（项目管理资格证书）么？”听到这个问题之后，我有点心虚，撒了个谎“准备考。”

后来就没有下文了，我复盘这次的面试，在交谈过程当中，感觉到面试官对于我某些的回复是满意的；而拒绝我的原因并不是因为我没有得到PMP的证书，他的目的，他希望在公司快速发展的时候，能够有人顺带梳理内外的业务逻辑和执行效率；也就是说，我在这方面还不够专业。

其实那时候我有些纳闷，我做的产品管理，关项目管理什么事？不过既然这次碰到了，我也就认真了解下吧；然后，一个星期后，报名了其中一家培训机构（所以当初说准备考其实也不算撒谎）。

二、项目管理是怎样的？

虽然自己也曾经有幸能够在成熟的项目团队工作过，但从这次系统的项目管理学习中，还是发现原来项目管理并不是原来想象中那么简单；即便是运用到现在的产品管理上，有不少的地方依然适用。

在这里先给哪些不了解PMP的小伙伴介绍一下基本情况，我学习的时候，教材已经是第六版了（对，它也会迭代），整本书（下面称PMBOOK）围绕这个如何管理单个项目进行（有一些是面向项目集的，不过那是另外一个证书了）；它把这个项目分为几个过程组：启动，计划，执行，监督，收尾。

各个过程组中包含着各自的知识板块，每个知识板块都有各自的输入项，技术和工具以及输出项；这实际的项目中，这些知识板块并不全部都是按线性顺序依次进行，有时候是会穿插在整个项目管理过程中，例如监管过程组的各个知识点。

所以在实际项目借鉴的时候，往往需要对这些知识板块进行“裁剪”，截取有用的部分，这也是这部书一直强调这本书的本意是作为可用于参考的“指南”，而不是可以用于照搬的“工具书”。

下面是我根据自己的经历和理解，再结合书本内容对整体的项目流程进行简化的梳理；其实不难发现，在日常的产品工作当中，很多方面也会用到项目管理的知识，例如需求管理、进度管理等等。

当然，无论是实际工作中，还是书本上的讲义，对项目流程的叙述都更为细致和严谨。

每一个环节在运用到实际工作中都需要仔细考究和裁剪，在这里边幅有限，在这里我就挑选几个我觉得比较有意思同时也对我平时工作有所启发的几个论点和大家分享一下（用我自己的话术）：

• 凡事皆有计划，凡事皆需计划；
• 千万不要忘了管理你的相关方；
• 监控过程，优先于监控最终可交付成果；
• 风险的定义，源自于不确定性，而非其影响效果；
• 如果你觉得一个东西过于宏大，那么把它拆开来做吧。

1. 凡事皆有计划，凡事皆需计划

西方的管理理论讲究模型和框架，因为他们相信只要做的方法正确了，那么答案也自然正确，所以在PMBOOK也同样不例外；在所有阶段中，重头戏是规划阶段——制定项目管理计划（Project Management Plan）。

但这个“计划”可能和平时大家理解的计划有些不同，举个简单的例子，一般人要去一趟中途旅游，他们可能是这样做计划的：

• 目的地：XXXX
• 路线：路线A或B
• 住宿点：XXXX

但是在PMBook中，上面那个应该称为“基准”，这里的“计划”指的却是这样：

• 目的地：XXXX，怎样才算顺利到达，中午前，傍晚？（定义成功标准）
• 路线：通过什么方法查找路线，有多条路线选择时，以何种要素为优先考虑，时间，费用？（定义方法论和监控标准）
• 住宿点：通过何种途径找到住宿地方，以何种因素考虑为优先；
• 其他：出现什么情况时候，延期或搁置出行（定义退出条件）。

在项目管理计划中很大一部分（除了基准部分），其实和业务本身无关，它所限定的是项目的管理方法；他的作用在于让所有的项目相关方之间制定了一个游戏规则，让在整个项目工作中的每一步都变得“合情合理，有理可循”（勿谓言之而不预）。

出现项目问题时，也方便快速定位到底是哪一个板块出现了问题；总之，计划做一件事前，先计划好做事的方法。

2. 千万不要忘了管理你的相关方

在PMBOOK的调查中，他们发现很多项目失败的原因，来源于相关方的管理失败；而在笔者复盘自己和听别人复盘的时候，也发现两个经常出现和相关方有关的问题。

• 认为给自己直接提需求的人是主要的相关方；
• 认为在执行过程当中的相关方是不会发生变化的。

PMBOOK中关于“相关方”的定义非常广，其中包括项目团队成员、发起人，和工作相关的上下级；同级的其他部门、客户，某些情况下甚至是包括政府部门。

根据不同的划分模型，可以把相关方划分为不同的类别。

相关方模型图片来源于：《汪博士解读PMP考试》

在执行过程当中，相关方的范围是可能会发生改变的，所以相关方的识别是一个持续的过程。

识别到他们，并且了解他们的期望只是第一步；根据他们对项目的态度（支持、反对、中立），我们还要去管理他们对项目的参与程度，之后用合适的沟通途径和方法去进行沟通；包括小到沟通所用到的形式和内容，大到汇报的机制和团队例会的流程。

（PMBOOK另外一个重要章节，沟通管理），而当出现和相关方的问题时（特别是需求理解这块），我们往往需要先检查沟通方面是不是出现了问题，是不是把错误的信息传递出去。

3. 监控过程，优先于监控最终可交付成果

PM的工作，有时候真的很忙，我自己在很长一段时间中，白天的时候需要进行各种的沟通工作，到了晚上才有空去处理自己的事情，理逻辑、原型设计、写文档。

一路辛苦，然后在评审的时候被评价用时过长且不符合业务要求，心中真的是扎心的不要不要的。

现在复盘下来，觉得其实在这个过程当中缺少了一些必要的项目管理工作，例如对工作进度监控和控制、沟通方式和工作流程的优化、工作工具的优化、相关方的有效管理、团队建设等等；这些项目管理的工作，都是需要花额外的时间进行的，有些时候，甚至需要花不少精力在上面，但是磨刀不误砍柴功。

其实在执行过程当中，通过过程监控就可以发现不少问题，就可以借此推测出产品的质量状态，及时修正，而不需要等到最后产品评审时才重新复盘。

4. 风险的定义，源自于不确定性，而非其影响效果

这是PMBOOK中一个非常有趣的观点，一般人认为评价风险，是看它所造成的后果，如果造成的后果很严重，那么这就是一件风险大的事情。

但是在PMBOOK里面有两个概念一个是“风险策略”，另一个是“风险应对”；PMBOOK中并不排斥风险，因为风险是随项目与生俱来的，而且风险中会带有机遇，对于一个已知的后果影响可能会很大的风险（例如某个可以预见的自然灾害）；我们可以通过合适的“风险策略”（转移、上报、接受、减轻、规避），选取对应的“应对风险”工作（购买保险、转移资源、增加资金准备、增加资源等等），对这些风险进行提前准备或应对；只要风险影响的不超过控制值或组织的承受范围，我们还是会认为这个风险得到有效应对和控制。

PMBOOK认为真正的风险是根源于不确定性，这包含两种含义，“你知道自己不知道什么”（已知的未知）和“你不知道你不知道什么”（未知的未知）；所以在PMBOOK的执行思路中，建议项目经理在执行项目时，在规划和迭代的时候尽可能地将这种不确定性降低，把不知道的地方搞清楚。

一个正常的项目中，风险应该是随着项目进行逐渐降低；因此，风险识别这个环节是贯穿了整个项目生命周期；换而言之，如果当你做完一个项目，但是回头发现，其实在中间环节还是有些部分还是一面懵逼，那这次做成可能只是幸运，下次就不一定了。

5. 如果你觉得一个东西过于宏大，那么把它拆开来做吧

有时候，我们会碰到一些规模或用户体量比较大产品或项目，这些工作包含了很多的工作和细节，可能一下子让人无从入手。

在PMBOOK中，介绍了这样一个方法“项目生命周期法”，也就是说把一整个项目按顺序拆分几个子项目，每个项目都有自己独立的启动、规划、执行、监控、收尾阶段；然后通过对上个阶段的成果验收，来判断是否止损，调整或者继续下去；当然，如果你要采取这种方法，必须要先获得的相关方认同（是的，又回到相关方部分）。

看到最后，可能还是有小伙伴觉得还是有些疑惑，我现在做的是产品工作啊，为什么你的例子都是项目的例子，里面都是说项目经理做的事情啊。

其实，项目工作和产品工作并不是那么泾渭分明，阶段性是项目工作的特点；但是产品工作也是靠一个个阶段性的工作链接而成的，从一个业务场景构架，到一个具体功能的设计，其实都可以从中看到从“启动“到”收尾”阶段的影子；这里的项目管理其实不单单指的是项目，而更加是一种做事的逻辑和方法论，希望我的文字能对大家有所启发。

作者：Leo，一个喜欢研究的产品汪，一个新晋的猫奴，在创业公司待过，也在500强的外资咨询公司待过，我相信人的一生应该是为了做成某一件事而活，希望可以结识更多同样喜欢产品这条路的朋友。

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

题图来自Unsplash，基于CC0协议