编辑导读：产品经理面对项目中繁琐又细致的工作，要如何做好管理，提高效率呢？本文作者根据自身工作经验，给出了一些建议，一起来看看吧。

毫无疑问，产品经理是一个综合性的创造型岗位，用三个词来形容主要职能可以归纳为想清楚，做出来，推出去。

人人都是产品经理，毕竟每个人都有提问题和出方案的天性。

从狭义上来讲，这句话也有其道理。从自身出发，每个人的人生由自己定义、设计和执行和完成。因此，每个人至少都是自己的产品经理。然而，当用户不再是自己且规模无限扩大时，就衍生出了广义上的产品经理。简单来说，企业以产品或服务为媒介，通过交易和用户交换价值，最终使双方获益，形成一个正循环。

产品经理需要想清楚用户模型（用户是谁、用户痛点、什么时候需要）和交易模型（如何创造利益、如何分配利益）后，使这场交易中达到接近于用户价值和商业价值的平衡。

欲望不止，用户预期也永远不会满足，在相对完美中寻求两者的平衡。因此，在完成前期的需求分析、权衡、决策后，如何做出来并推出去，让某个产品需求的快速进入市场产生价值，也成为了产品经理的一个核心能力。

“自我欣赏的是艺术，他人接受的才是商品”。

产品经理如何有效进行项目管理，本文将从以下几个章节出发：

1. 都是 PM，有何不同
2. 启动：师出有名，齐心协力
3. 规划：运筹帷幄，决胜千里
4. 执行：审时度势，依计而行
5. 收尾：累土聚沙，积土为山

一、都是 PM，有何不同

项目经理和产品经理两个职位的的英文缩写都是 PM，实际上，项目经理英文是 Project Manager，Project 除了有项目的含义，还有工程、计划、方案、生产等翻译。而产品经理英文是 Product Manager，Product 除了产品的含义，还有产物、结果等翻译。

众所周知，英文讲究“精确”。因此，从英文来看也印证了两个岗位的差异点：项目经理以项目为核心，通过计划、方案、生产等措施来创造价值，产品经理则是一切围绕产品，一切又以产品来说话。

从两者核心对象而言，项目在本质上是独特的、临时的非重复性工作，要求使用有限的资源，在有限的时间内为特定的人（或组织）完成某种特定目标（产品、服务或成果）。

• 独特意味着项目不会重复，和其他项目迥异；
• 临时则是指明确的起点与终点，需要按时交付。

而产品的本质是是用户需求的集合，满足了用户价值和商业价值，是一个长期、含杠杆、复杂的重复工作。

• 长期是指在产品生命周期内，无论哪个阶段都需要产品经理去进行维系。
• 杠杆则意味着产品需要以小博大，优先满足大部分用户的高频次需求。
• 市场变幻莫测，在用户和场景变化的背景下，可能还需要针对一个产品进行反复而又复杂的迭代。

市场都是充满竞争和遍布友商的（不包括垄断），在这种背景下，如何更快速满足用户需求，成为决定了产品成败的关键点。项目是过程，产品是结果，对于产品经理这个角色而言，两者需紧密结合，借助强有力的项目管理能力来保证按时按质交付，是为产品赢得竞争优势的前提。

二、启动：师出有名，齐心协力

正如前文所描述的，项目的特点之一是临时性，即每个项目都会有明确的开始时间和结束时间。因此，以终为始，在启动阶段时就需要对项目进行通过阶段化管控，从而清楚每个阶段的主要矛盾是什么。

对于项目而言，主要可以分为 4 个阶段：启动、规划、执行和收尾。

每个阶段最关键的就两个事情：需要完成哪些工作和如何量化可交付成果。

在启动阶段，最核心在于师出有名，齐心协力。

一般而言，产品经理会组建“虚拟团队”（产品经理如何抢人力资源这是另外的 topic），里面会包含各类角色，例如前端、后端、QA、设计等等。往往产品经理都是有责无权，即和其他成员角色属于平级，而角色之间的利益可能不同，举个例子，设计可能更多考虑好用，开发可能更多考虑能用。因此，产品经理需要在其中充当润滑剂，协调和沟通，促使团队成员齐心协力。

始于需求而终于需求，产品经理会在调研中确定评估需求的优先级和利弊，当确定好后，就有了目标。这个目标也许产品经理自身权衡决策，也许是从领导层自上而下的“命令”。无论如何，就像大海里的游轮，方向已经定好。

项目经理会有项目任务书，产品经理也有产品需求文档，尽管产品需求文档已经在尽可能的完善，但是不同的角色会基于自身角度出发给出自己关于“航线”的建议和看法。如何选择航线，这需要产品经理在自身想法的基础上，尝试找到能使各方达成一致且投入产出比最高的方案。有时候，这也被成为“需求初审”。

曾经我一直好奇，为什么会有七夕节需要送花，端午节需要吃粽子、中秋节需要吃月饼。仿佛不同节日总有一个约定俗成的一个象征物品。后来我发现了，时间没变，变的只是人们赋予节日的意义，人需要有仪式感，所以就有了一个象征物品。

《小王子》里说：仪式感就是使某一天与其他日子不同，使某一个时刻与其他时刻不同。

项目同样需要仪式感，每个阶段的开始或结尾都是一个里程碑，每个里程碑都需要不同仪式来让团队成员意识到已经进入下一个阶段，从而都意识自身责任和项目节奏。

项目启动的仪式感可以通过启动会的形式来完成，在项目启动中，产品经理需要力争达到以下三个目标：

1. 传达业务目标、需求价值和产品方案；
2. 同步项目各大关键里程碑，确认好可交付物和量化标准；
3. 合力消灭产品方案的不足点并达成共识。

好的开始是成功的一半，项目启动会的作用，在于能够通过一个会议让每一个团队成员尽可能的明确业务目标和把握项目里程碑，同时合力让需求文档更加完善，进而达成初步共识，增强凝聚力。

三、规划：运筹帷幄，决胜千里

启动会，也就是产品方案初审，在会议上我们已经同步了几个关键里程碑，但是还需要进一步细化每个里程碑的时间点，而产品经理则需负责整体规划和把控细节，运筹帷幄，方可决胜千里。

产品规划有两种做法，一种是固定发版周期，然后从版本发布时间倒推可完成功能时间节点，一种是由版本上的功能，由产品经理统合后确认最终版本发布时间。

对于产品经理而言，如果是负责的是整个版本，那么就要确认版本发布时间。如果负责的是版本上的某个功能，那么就需要保证这个功能能够赶上版本发布，俗称“上车”。
“凡事预则立，不预则废”。

毫无疑问，规划是整个项目管理中的灵魂，好的规划能够让项目事半功倍，为每个工作项设定Deadline，是规划的核心。

就我自己项目经验而言，实际不可能完全按照计划进行，但是计划可以量化工作，从而把控风险。根据布利斯定理： 用较多的时间为一次工作事前计划，做这项工作所用的总时间就会减少。 事前想得清，事中不折腾。

当然，这里规划的前提，是已经在和技术总监/架构师确认了技术可行性，评估大致工作量后，现在需要进一步精确工作量。

在项目启动时，会议其实还有另外一个隐含的目的：让每一个计划执行者参与规划，从而提高准确率。

那么如何做规划呢？

做规划，说来也简单，核心就是拆拆拆，拆分工作量也就是项目管理中的工作分解结构（WBS），工作分解结构（WBS）是把项目可交付成果和项目工作分解成较小的、可度量的工作细节的过程。正所谓魔鬼藏在细节中，对细节的把握程度也反映了一个产品经理的项目管理水平。

在整个团队会有不同的角色，最简单的工作分解即按照角色来分，包含设计、前后端、客户端、测试等，然后再由每个角色根据产品需求文档细化功到工作细节，最后形成产品规划。

在拆分时，这里有几个需要注意的点：

• 首先，也是关键点，作为产品经理，不要越俎代庖，在尊重团队成员拆分和估算的基础上，如有必要，可继续请技术总监/架构师审核。
• 其次，工作细节需要遵循 MECE 法则：“相互独立，完全穷尽”，也就是既不重复，也无遗漏。
• 再次，对于一个工作细节需要从从两个维度考虑：空间和时间，即交付成果和时间成本。时间成本的度量单位可估算到人天，即 1 人全力投入所需要的天数。
• 最后，单个工作任务，应只分配给一个责任人，避免旁观者效应，即分配的人都觉的“与我无关”。

坦白来讲，在项目早期阶段的拆分，因为还没正式开始，所以无论是设计还是开发，基本都是使用类比估算，即根据以往经验来估算现有项目工作细节所需时间。因此，实际项目中，技术和经验的积累可以提高估算准确性，比如引入技术总监/架构师参与评审，其次开发还可以通过手工实验等方式来进一步精确时间。

实事求是的说，计划总是有其风险性，因此，产品经理不能过于乐观，要学会善于控制风险。同时，在做规划时，抱有悲观心态，即最好的方式是在最后收集时间总包下，还需要提供一个冗余时间。冗余时间是一个“容错机制”，用于容纳那些未曾预见的问题和一般的生产力损失（临时会议、突发情况等）所消耗的时间。冗余时间的多少，这需要产品经理估算风险发生的概率、依据经验和情况具体分析决定。

四、执行：审时度势，依计而行

当一个项目已经完成了启动和规划，也有了一个集众人之力合力产出的里程碑和甘特图，项目也终于可以进入执行阶段。在产品开发中，这个执行主要可以分为两步：开发和测试。

在这个阶段，产品经理无需做其他画蛇添足的事情，无论是开发还是测试过程，都只需要完成这三件事情，即管理进度、管理变更和管理 Bug。在里程碑和甘特图的基础上，做到审时度势，依计而行。

4.1 管理进度

在进度管理上，产品经理需要正确认识到自己的角色，在这个过程中，产品经理的核心在于让项目走在正轨上。同时，自己和开发童鞋属于平级关系，并无领导关系，像评估用时与实际用时之比这个衡量指标除了能够让你了解开发是否靠谱外，并无其他用处。

产品经理最需要跟踪的是完成任务所需剩余时间，通过该时间和任务时间成本对比，就可以评估出工作细分风险性。如果发现时间不足可能导致的风险，就需要引入解决风险的流程。

因此，产品经理需要盯着两个剩余时间：里程碑剩余时间和工作细节剩余时间。前者达标依赖于后者的进度，要记住：没有好的过程就很难有好的结果。当工作细节完成时间一拖再拖，里程碑自然也不可能一帆风顺完成。

每个人都不想频繁被打扰，特别是沉入代码世界的开发，打断研发就等同于生产停滞、生产工具质量下降（这句话来自我司技术大牛）。因此，在项目前期，一种比较好的方式通过周会来管理进度，这种节奏可以防止团队被频繁打扰。首先，通过周会，产品经理需要将里程碑的压力传递给项目中的每一个人，其次，让团队成员有机会了解并告诉大家为什么开发会快于预期或慢于预期，这个过程还有助于产品经理识别谁的进度受阻。最后，面对一些复杂问题，可以在周会上同步信息，互通有无，达成共识。

事实上，无论是产品经理还是开发自身，往往都会过于乐观评估。当产品经理发现整个项目有严重时间上的风险时，可能就需要启动敏捷进度管理模式，比如开启的 5 分钟站立日会，在日会上，每个人只需要回答三个问题：

1. 昨天我做了什么？
2. 现在我遇到了什么困难？
3. 今天我计划做什么？

毫无疑问，这种模式可以帮助项目快速的精确管理进度，进度跟进的时间粒度变小，也使产品经理能够更准确的识别风险，找出偏差并实施纠偏措施，但是代价自然就是每个人负荷变重。

以我自身的项目经验总结，哪怕项目规划做的再好，看似时间分配得井井有条，但到最后可能需要冲刺一把才能赶上发布时间。因此，为了使项目有条不紊的推进，心脏少一点惊吓，无论是周会还是日会，都是一个可以让产品经理去营造紧迫氛围，快速推进项目进度的不错选择。

4.2 管理变更

说到变更，任何一个产品经理都不会陌生，每一个变更都会让开发望而生畏、胆战心惊，然而产品经理对此也是无可奈何。客观来讲，每个需求都会有两次创造，第一次是在脑海里，第二次是在实践中。因此，哪怕产品经理在充分的调研、考量和评估，都无法避免需求在后期开发过程产生不可预估的变更。可能，唯一的不变就是变化了。所以，我们首先必须有一个有一个好的心态拥抱变化。
要记住，发生变更不是问题，问题是许多变更处于“非管理状态”！

鲁迅曾说：“发布手中有的，而非脑中想的”。因此，进入开发阶段，产品经理要尽可能避免修改产品的需求和设计，一切以发布为优先原则。

一个项目可以仅由三个部分组成：范围、时间和成本。

范围即需求范围，一般是指要做哪些事情，时间即完成时间，即完成该范围时间需要多久，在软件项目中，成本主要指人力成本，即完成在时间和范围的限定下，需要多少人力投入。

任何的变更，都会带来范围的调整，因此，不可避免的直接影响时间和成本，导致了项目交付的不确定性。

如何让变更进入可管理状态，我认为可以从三个方面考虑：

• 设立变更流程：通过如 Jira、teambition、Tapd 等工具来管理所有变更，降低管理成本，并评估变更范围、变更成本和变更时间。
• 定义好优先级：根据对发布的影响，设立优先级，如 P0/P1/P2，其中 P0 为直接影响使用，比如该功能设计逻辑有问题或者其他问题严重影响使用。
• 把控变更风险：将变更的带来的风险纳入里程碑管理，尽可能避免里程碑无法完成。

变更不可避免，整个里程碑过程中，通过管理变更，可以让项目有条不紊的继续进行。产品经理为了保证按时发布的目标，必须警惕范围蔓延，此时可以采取“抓小放大”的策略，即安排在里程碑的某段周期统一处理一些 P1/P1 变更，以最小成本实现，比较大的变更且在不影响能用的前提下，可以通过后续版本统一处理。

4.3 管理 Bug

之前听过一句话：开发软件如果不通过测试，那等同于上茅坑不擦屁股，不负责任。

可靠的软件质量是是产品成功的基石，“质量就是生命线”这句话不应该只是一句口号，而应该成为产品经理恪守的原则。而软件测试的目的是用尽可能发现并改正软件中潜在的各种故障及缺陷，提升软件的可靠

客观来讲，无论研发团队多么优秀、编写了多少单元测试，总是避免不了 Bug。因此，产品经理在规划初期，就应该为 Bug 修复留出固定的周期。另外，和管理变更类似，管理 Bug 需要先建立流程、再定义好优先级。但是和管理需求变更不一样的是，Bug 一般是因为质量问题或者和预期不符，所以大部分 Bug 都需要在固定时间内进行修复。

如何让 Bug 进入可管理状态，也有以下首先，可以明确流程，“工欲善其事，必先利其器”，和管理需求变更一样，通过如 Jira、teambition 或 Tapd 等工具来管理所有 Bug，提高管理效率。其次，在团队建立共识，即修复 Bug 紧急性和严重性，设立 Bug 优先级，并针对优先级给出预估修复时间。

最后，产品经理应保持固定频率来根据现有的 Bug 来评估项目风险，可以结合管理进度中的流程，通过周会/日会来保持沟通，通过评估新出现的 Bug 严重性、修复成本和频次等来定义优先级进行分级。

于我而言，会比较常用项目管理工具里的两个功能：Bug 看板和 Bug 燃尽图。

看板的可以在任何时候看到 Bug 的整体情况，如待处理/修复中/已解决等状态的 Bug，产品经理可基于看板快速进行下一步管理，如调整优先级、分配责任人等。同时，还可以根据剩余待处理的不同优先级来识别潜在风险。

Bug 燃尽图可以反映项目的 Bug 数量随时间变化情况，最重要的价值，在于可以预测产品何时能够交付。

这些 Bug 下降斜率，被称作新增 /修复率。当新增/修复率小于 1，即每天修复的 Bug 数量超过每天发现的 Bug 数量时，即确定风险处于可控范围内，并可以粗略估算 Bug 清零的时间。

五、收尾：累土聚沙，积土为山

当产品经理成功把需求发布，也意味着项目暂时告一段落。正如前文说的，项目需要仪式感，而收尾阶段的仪式感来自复盘，复盘的目的绝不是出于追责，而是在于找出问题并改进。正所谓累土聚沙，积土为山，只有通过一次次复盘积累，才能规避下一次同样的问题。

复盘一词来自于围棋，指棋手对战后重演旧局分析得失，这个把对弈过程还原并且进行研讨、分析的过程，就是复盘。黑格尔曾经说过：“我们从历史中吸取的唯一教训是人们从未吸取教训”，需求发布并不等于结束，要学会从历史中吸取教训。

人类的错误可以分为两大类型。第一类是“无知之错”，我们犯错是因为没有掌握相关知识。第二类是“无能之错”，我们犯错并非因为没有掌握相关知识，而是因为没有正确使用这些知识。

“无知之错”可以原谅，“无能之错”不可原谅。在整个项目周期过程中，很多时候错误来源于“无知之错”，即第一次接触，哪怕走了弯路，也实属正常，只能通过学习、刻意练习等途径去克服。而对于期间产生的“无能之错”，只是因为很多知识没有被正确使用或者总结的经验教训没有落实，才导致同一错误重复发生。

对于任何问题的思考，想透彻，写清楚，讲明白是三个完全不同的维度。我们自以为“想清楚”的事情，未必能“写清楚”，而写清楚的，也未必能够“讲明白”。

因此，在复盘的过程中，产品经理可督促成员复盘会议前想透彻，写清楚，如通过文档形式落实总结，描述每一个问题和改进措施，同时，在复盘会议时讲明白。通过这种方式复盘，也意味着“无能之错”将会越来越少。此外，另外一个小技巧，通过将频次较高的 “无能之错”总结为 Checklist 也不失为一个不错的方法。

想透彻，写清楚，讲明白的过程，也是将问题在建立体系化的逻辑结构过程。这篇文章，也是我自己在把“项目管理”这个问题写清楚的一个过程，希望能够对你有所有帮助，谢谢。

参考资料：

《极简项目管理》

《产品方法论》

#专栏作家#

零度Pasca，公众号：大兵闲记，人人都是产品经理专栏作家。关注前沿技术趋势，理性数据主义者；热爱阅读，坚信输出是沉淀输入的最好方式，致力于用产品思维解决用户共性问题。

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

题图来自Unsplash, 基于CC0协议