项目(二)规划

文章来自 https://time.geekbang.org/column/article/156858 修改

计划是贯穿始终的重要课题，是各个角色协同工作的基准

作为项目经理，你要利用一切可以利用的资源、尽自己最大的努力达成项目目标，那么计划，就是你可以借助的重要工具。从一个执行人员，转做项目经理，你需要学习的是，从全局的视角出发，去推进项目整体目标的落地，优化各个角色的协同过程。
计划是“市场需求或发起人的期望”和“团队生产力”之间平衡的结果。从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程。如果我们省去对焦的步骤，就会给后续的执行工作埋下很多“地雷”。在执行过程中，这些“地雷”一旦被引爆，就会把我们的项目拖向失控的深渊。

计划的步骤

1.具体

使用 WBS 分解法将需求分解成任务

计划是一种集体对焦的方式。好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦
可以使用 WBS 工作分解法, WBS 是项目管理领域非常重要的方法。创建 WBS 的过程，也就是把项目工作按阶段可交付成果分解成较小的、更易于管理的组成部分的过程
拆解需要将工作项拆解到 3 个工作日以内，每项任务都对应到个人

2.全面

识别依赖并画出关键路径

计划需要有任务列表，有识别关键资源和关键依赖，并且有考虑研发之外其他环节
需要让我们明确实现目标的关键路径，明确是否可以完成目标以及如何完成
关键路径是项目计划中耗时最长的那条路径，关键路径的工期决定了整个项目的工期，所以，任何关键路径上的延迟都将直接影响项目的预期完成时间

3.准确

定义完成标准

完成标准就是某时间点需要完成的事项列表，或者是应该达到的某项指标（特定水平的 Bug 数量 / 性能指标等）。进度计划中的任何重要时间节点，都应该有一组完成标准。越早定义完成标准，计划按照期望完成的概率就越大
例如:

• 需求 / 设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
• 功能完成 / 提测：所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把冒烟测试通过率，CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
• 里程碑完成：质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑。

4.共识

没有达成共识的计划，是不具备任何效力的

在全员规划会上，除了对齐信息之外，更重要的是当面达成共识，这其实也是仪式感和承诺的象征，对于计划后续的有效执行，是至关重要的。因此，达成共识并公开透明，就是做计划的第四个标准动作
要在确认计划之后，向所有项目组成员，包括项目的所有干系人，发送计划邮件，正式周知，这可以尽早发现共识的偏差，是非常有必要的。

5.即时

计划永远是个反复修正、渐进明晰的过程

在整个项目周期中，由于随时会可能出现变更，加上对估算的不断细化，计划永远是个反复修正、渐进明晰的过程，我们要对计划进行持续地跟进与调整。重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。而变更及时调整，就是做计划的第五个标准动作。
你需要注意的是，与进度计划有关的任何变更，都需要提交给项目管理人员，最好由团队中对应功能小组的成员（该功能模块涉及的策划、设计、开发、测试）及其他相关干系方共同讨论，明确计划变动可能对各方造成的影响，最终做出决策，并公开告知所有项目组成员。

总结图