如何制定一份完整计划

前言

最近工作中在接触一些项目管理的内容，在工作中上级要求对于某件事情叫我做一份计划，做计划这个过程中反反复复改了几次。才形成最后的计划。

计划的重要性

在项目管理过程中计划的重要性不言而喻，不管你是项目经理还是普通的开发人员、测试人员在工作中实际上都需要有计划，在项目管理领域中，项目管理中的五大过程组中，规划过程组就是其中一个，规划的核心其实就是计划、一份计划基本上是贯穿了整个项目管理过程。

在项目管理中，一份计划其实是项目经理和相关干系人集体对焦的过程。它指引着项目的进度的推进、直到完成。

一份计划这么重要，但实际工作中大部分人做的计划其实称不上一份完整的计划。下面我将从计划的几个注意要点来和你讲一下如何做出一份完整的计划。

任务要具体

刚刚转管理时，上级分配任务下来，可能会叫你列举个大概计划，这个时候的计划就是这样的：我将在xxx时间完成这个模块的功能。这种计划对于个人来说问题也不大，如果对于管理人员来说简单的回复是不行的，因为这样的计划太不具体了。

好的计划要给出时间节点，并给出依据。所以我们拿个一个任务之后需要通过wbs过程，分解任务过程，就是把项目工作按阶段可交付成果分解成较小的、易于管理的组成部分的过程。

计划要全面

通过wbs工作分解任务之后的计划还不是一份完整的计划，因为
计划不是简单的任务列表，程序员只需要关心自己什么时候把任务列表作为结果，而项目管理人员需要整体看计划，需要有关键路径， 做计划的方式的转变，背后其实是思维方式的根本转变。 明确整个项目分成多少块工作内容、涉及哪些角色和哪些环节工作项、每个任务对应到个人，每项工作拆解到 3 个工作日以内。

如果一份计划只有任务列表，没有识别关键资源和关键依赖，也没有考虑研发之外其他环节是不够的。

识别依赖并画出关键路径，这一步意味着我们开始从目标的角度对资源进行统筹思考。同时如果在计划中增加里程碑标识。就会使得计划更加清晰。

定义完成标准

在计划中节点完成标准需要统一。需求、设计确认完成 功能完成、提测、里程碑完成、这些完成怎么才算完成，例如是开发人员说开发完成，还是需要测试才算完成，提测的标准是什么？是开发人员说可以提测了就可以吗？还是bug率要达到某个标准才行。这个标准最好提前定义好

达成共识

有些项目经理定出计划之后和相关人员说完之后就等最后的成果检查，这样是不行的，口头说可能后面都说不清，可能相关人员也没有正确吸收计划。

计划要透明，而不能只是口头和相关人员说。需要将计划发到各个相关人员手上， 做计划本身并不是最难的，真正难的是什么？对焦！没有达成共识的计划，是不具备任何效力的。 达成共识并公开透明
只有大家对节点的状态达成了共识，才能够更加顺利的推进项目，如果没有共识，可能就出现一种情况，到了某个里程碑节点，准备进行成果检查时，发现事情的结果压根没有达到预期的要求，从而导致项目推后。

及时更新

在项目进展过程中，总是有一些特殊的事情发生或者开始做计划时没有考虑到的事情，所以说做计划是个反复修正、渐进明晰的过程，如果有变动我们要对计划进行持续地跟进与调整。重要的是，每一次进行调整，都要确保项目中的每个人知道当前的计划是什么，调整计划需要怎样的决策过程，都需要谁参与决策。而及时调整变更。 即时调整 并告知相关人员。

总结

从上面几点可以总结，一份完整的计划需要几个过程，

1. 计划工作分解
2. 识别依赖及各环节关键路径
3. 定义完成标准
4. 达成共识并公开透明
5. 即时调整变更。