确定完项目的模型之后，我们开始开展项目的规划了，菜多多大体分为三个大版本，第一个版本会在2022年12月完成，第二个版本会在2023年4月完成，第三个版本会在2023年10月完成，菜多多App的版本的里程碑计划如图3-9所示。

图3-9菜多多App的版本的里程碑计划

基于里程碑计划，把产品的实现路线图绘制完成，如图3-10所示。

图3-10 路线图

在2022年3月到6月之间，项目完成的需求阶段，暨2022年6月中旬，项目经理陈恭召开了一次项目开发启动会，把项目目标、背景、里程碑计划、团队成员、项目风险等跟大家同步后，在6月下旬，项目经理陈恭在为项目V1.0版本的详细计划而焦虑着，他的疑问是选择什么样的模型去制订计划，以及对于这样一个软件App项目，计划做到多细才好落地。

他去找马丁寻求帮助，马丁顾问听了陈恭的焦虑的点，很淡然地说：第一个问题，我们这个项目是混合型的，既不是传统的预测型，也不是纯增量型的，所以要两者结合规划。大的版本的里程碑节点属于传统的预测型的，而在版本内部，第一个版本我们会选择预测型去规划，毕竟它属于从0到1；第二个版本，因为是在1.0版本上优化，增加功能，所以建议做增量型的迭代计划；第三个版本，要看跟其他系统的耦合关系，优化的功能点具体是什么，再来选择它的规划模型。如图3-11所示。

图3-11 迭代型开发和增量型开发（插图来自PMBOK第七版）

至于第二个问题，项目计划要做到多细，我们要结合团队成员的意见，建议你组织召开一个计划沟通会，但是大的原则是颗粒度不能太粗，太粗不利于监督执行，也不利于团队成员分解落地。

凡事预则立，不预则废。对于一个项目做一个详细的规划是非常重要的，为什么这么讲呢？

（1）项目进度是项目的目标之一，例如，我们的菜多多预计要在今年12月份第一版上市。这个上市的节点目标很重要。

（2）项目计划是对项目工作的细化，只有被分解的工作才能够被执行和完成。例如，菜多多App的详细计划，见表3-4。

（3）事务之间有一定逻辑关系，需要识别、澄清和排序（因果、先后、并行），项目的工作是团队协作完成的，团队的工作需要有一定的共识，这个共识就是逻辑，能把事务之间的逻辑关键展现在大家面前，并且达成共识，未来团队的工作就更加容易推进。

陈恭是一个行动力极强的项目经理，第二天，他就拉着项目团队成员一起召开项目计划沟通会，他让团队成员分别把自己领域的关键事项列出来。他先按照产品功能、UI、开发、测试、验收这几个大节点列出来，然后把团队成员讲的关键事项按照时间先后的逻辑关系排序，再与团队成员沟通每个关键事项需要的时间。最后形成一个具有串联和并联逻辑关系的项目WBS计划。

图3-12是陈恭做计划的参考模型。我们做软件App项目基本都会参考这个增量规划形式模型。制定进度计划的方法之一是基于迭代和发布计划制定的。

图3-12 增量规划形式模型（插图来自PMBOK第七版）

陈恭做计划会考虑余量，不会做得很满，这样未来会有调整的空间。

作为项目经理，陈恭到底应该计划什么？

​ 具体有哪些关键的事情并且预估每件事情的时间；

​ 事情之间的逻辑关系；

​ 完成这件事情的负责人；

​ 事情完成的标志（关键交付物+关键工作成果）。