实事求是的说，计划总是有其风险性，因此，产品经理不能过于乐观，要学会善于控制风险。同时，在做规划时，抱有悲观心态，即最好的方式是在最后收集时间总包下，还需要提供一个冗余时间。冗余时间是一个“容错机制”，用于容纳那些未曾预见的问题和一般的生产力损失（临时会议、突发情况等）所消耗的时间。冗余时间的多少，这需要产品经理估算风险发生的概率、依据经验和情况具体分析决定。
四、执行：审时度势，依计而行当一个项目已经完成了启动和规划，也有了一个集众人之力合力产出的里程碑和甘特图，项目也终于可以进入执行阶段。在产品开发中，这个执行主要可以分为两步：开发和测试。
在这个阶段，产品经理无需做其他画蛇添足的事情，无论是开发还是测试过程，都只需要完成这三件事情，即管理进度、管理变更和管理 Bug。在里程碑和甘特图的基础上，做到审时度势，依计而行。
4.1 管理进度
在进度管理上，产品经理需要正确认识到自己的角色，在这个过程中，产品经理的核心在于让项目走在正轨上。同时，自己和开发童鞋属于平级关系，并无领导关系，像评估用时与实际用时之比这个衡量指标除了能够让你了解开发是否靠谱外，并无其他用处。
产品经理最需要跟踪的是完成任务所需剩余时间，通过该时间和任务时间成本对比，就可以评估出工作细分风险性。如果发现时间不足可能导致的风险，就需要引入解决风险的流程。
因此，产品经理需要盯着两个剩余时间：里程碑剩余时间和工作细节剩余时间。前者达标依赖于后者的进度，要记住：没有好的过程就很难有好的结果。当工作细节完成时间一拖再拖，里程碑自然也不可能一帆风顺完成。
每个人都不想频繁被打扰，特别是沉入代码世界的开发，打断研发就等同于生产停滞、生产工具质量下降（这句话来自我司技术大牛）。因此，在项目前期，一种比较好的方式通过周会来管理进度，这种节奏可以防止团队被频繁打扰。首先，通过周会，产品经理需要将里程碑的压力传递给项目中的每一个人，其次，让团队成员有机会了解并告诉大家为什么开发会快于预期或慢于预期，这个过程还有助于产品经理识别谁的进度受阻。最后，面对一些复杂问题，可以在周会上同步信息，互通有无，达成共识。
事实上，无论是产品经理还是开发自身，往往都会过于乐观评估。当产品经理发现整个项目有严重时间上的风险时，可能就需要启动敏捷进度管理模式，比如开启的 5 分钟站立日会，在日会上，每个人只需要回答三个问题：
- 昨天我做了什么？
- 现在我遇到了什么困难？
- 今天我计划做什么？
毫无疑问，这种模式可以帮助项目快速的精确管理进度，进度跟进的时间粒度变小，也使产品经理能够更准确的识别风险，找出偏差并实施纠偏措施，但是代价自然就是每个人负荷变重。
以我自身的项目经验总结，哪怕项目规划做的再好，看似时间分配得井井有条，但到最后可能需要冲刺一把才能赶上发布时间。因此，为了使项目有条不紊的推进，心脏少一点惊吓，无论是周会还是日会，都是一个可以让产品经理去营造紧迫氛围，快速推进项目进度的不错选择。
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协议
