总结：5 个标准动作，分别是 WBS 工作分解，识别依赖及各环节关键路径，定义完成标准，达成共识并公开透明，即时调整变更。
在项目管理中，计划是贯穿始终的重要课题，是各个角色协同工作的基准；作为项目经理，你要利用一切可以利用的资源、尽自己最大的努力达成项目目标，而计划是你可以借助的重要工具；
从本质上来讲，计划是用来对焦的！做计划，是个集体对焦的过程；
雷区 1：不够具体， 好的计划，不仅要给出时间节点，还要给出依据和来源，这样才能更有效地对焦。WBS 工作分解（Work Breakdown Structure），这是我们做计划的第一个标准动作。
雷区 2：不够全面；只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节。这样的计划，无法让我们明确实现目标的关键路径，也无法明确是否可以完成目标以及如何完成。识别依赖并画出关键路径，就是我要讲的做计划的第二个标准动作，这一步意味着我们开始从目标的角度对资源进行统筹思考。
为各个阶段设定合理的里程碑节点，确保考虑周全：
把整个过程可视化出来，让计划更加直观：
雷区 3：不够准确
做计划的第三个标准动作了，就是定义完成标准。
以最关键的几个常见时间节点为例，完成标准如下：
需求 / 设计确认：执行所需的需求稿或设计稿已经完成，而且公开评审通过，团队已经准备好要编写产品代码了。值得一提的是，有些团队还会对需求稿或设计稿做一定的要求，比如把未处理的反馈意见数小于多少作为标准。
功能完成 / 提测：所有定义的功能都已经完成（比如冒烟测试通过率高于 90%），团队已经准备好将焦点转移到质量保证上，并将所有剩余问题都当作 Bug 来跟踪。一些质量基础比较好的团队，也可以把 CI 自动回归用例集通过率、静态代码检查分数、单元测试覆盖率等，作为更加细节具体的完成标准。
里程碑完成：质量已经达到适当水平（如不存在 P0 及 P1 优先级的 Bug），可以上线发布，或者可以开始下一个里程碑。
雷区 4：没有共识
对焦！没有达成共识的计划，是不具备任何效力的。因此，达成共识并公开透明，就是做计划的第四个标准动作
要在确认计划之后，向所有项目组成员，包括项目的所有干系人，发送计划邮件，正式周知，这可以尽早地发现共识的偏差。
雷区 5：不够即时
做计划永远是个反复修正、渐进明晰的过程；重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。而及时调整变更，就是做计划的第五个标准动作；
希望你在做计划时，能够对照着下表进行梳理，以免埋下“延期地雷”：
