本文转自网络
艾森豪威尔说：“没有战争是根据计划而胜利的，但是没有计划，战争也无法胜利。”这句话可以理解为，首先，我们承认战争的胜负受很多计划外因素的影响，计划不是万能的。其次，战争胜利离不开计划，计划是至关重要的。
正如同“钱不是万能的，但没有钱，却是万万不能的”，在项目管理中，进度计划也同样拥有举足轻重的作用，制订项目进度计划是项目经理的必备技能。那么如何做好这一步呢?本文从制订计划的时间点、调整计划的注意事项以及如何做好计划这几个维度来介绍，希望读者能学以致用。
别怕做计划
既然计划如此重要，可却有很多人从心底害怕或排斥做计划。表面上看，人们会声称自己不喜欢受约束或被限制，自由随性才能激发更大的创造力。这些观点看似无可厚非，特别是创意性或探索性的工作，但做计划限制了创作这种观点站得住脚吗?
英国诗人、现代派诗歌运动领袖T·S·艾略特(T.S.Eliot)说过：“严格约束下的创作会将想象力的翅膀完全伸展，并迸发丰富想法;在彻底自由下创作可能使作品散作一盘沙。”可见，自由与约束并不矛盾，相反，约束和限制反过来会帮助创作，比如唐诗、宋词的韵律等。
计划的本质是团队对何时完成任务的承诺。从心理学层面来分析，排斥做计划的真正原因，在于人们不愿轻易做出承诺。人人都有一种言行一致的愿望，一旦做出承诺，来自内心和外部的压力会迫使我们按照承诺去做。但也正是由于这种下意识的一致性倾向，才让进度计划真正有效。
或许你会说：“我们并不是没有做计划，但计划的执行往往是有问题的，做了也没用啊。”因为计划的执行有问题，就不去做计划，这种逻辑无异于因噎废食。
计划要趁早
做计划时经常会听到有人说，等策划案定了再说吧，现在也不知道具体做什么，计划做了也是白做。
的确，任何人都很难在早期估计一个项目所需要的时间。说实话，刚刚接触项目管理时，我也是这么想的，后来几次实践下来，渐渐领悟到“越有太多不确定，越应该给出计划”。在混乱不清的状况下，你根据仅有的少量信息给出了期望值，就好比挖了个坑，人们自然会来填满它。马上就会有人跳出来指出哪个时间点肯定不行，哪里不靠谱，渐渐地计划变得越来越充实，越来越准确。更有意思的是，经历了这个指手画脚的过程之后，你会发现人们开始下意识地按照计划做事，那个最初不靠谱的计划竟一步步变成了现实!
项目经理应该做头一个挖坑的人，引导团队拨开重重迷雾，将所有不确定一一落地。否则，模糊的概念永远停留在高层或某个人的脑袋里，不会对团队产生任何实质的影响。
做项目如同下棋，高明的棋手，走一步看三步。好的计划必须领先于项目实际，要有一定预见性。
调整计划要谨慎
计划绝不是固定不变的，相反，计划是调整的基础与依据。在整个项目周期中，为应对随时可能出现的变更，计划永远是个反复修正、渐进明细的过程。另外，在项目进程中，随着信息越来越详细，估算会越来越准确。因此，计划需要持续地改进与调整。
但计划的调整绝对需要谨慎，一个天天调整的计划会渐渐失去公信力。重要的是，要确保项目中每个人知道当前的计划是什么，调整计划需要怎样的决策过程，需要谁参与决策。在我们的项目中，与进度计划有关的任何变更，都会提交至项目经理，由对应功能小组成员(该功能模块涉及的策划、设计、开发、测试)及其他相关方共同讨论，明确各方影响，最终做出决策，并公告所有项目组成员。
计划诞生记
计划是“市场需求或高层期望”与“团队生产力”两者之间平衡的结果。项目的每个过程都需要做计划，计划应该贯穿项目始终，持续细化调整。具体步骤如下所述。
项目立项前
这时的计划比较粗略，可将目标按照功能体系分割成几个重大里程碑，并给出里程碑完成的时间点预期。根据项目周期长短，时间可以估算到季度或月。此时的重点要给出立项的时间表，如图1所示，何时完成初期调研及评估，何时做好立项准备、启动项目，立项时间表使得项目各资源方有了明确的预期，以便提前做好资源调配。
项目立项后
各项人力资源逐步就位，根据对团队生产力的经验估计，结合启动过程中对里程碑的大致预期，进一步推导出需求确认、设计确认、功能完成等中间节点，如图2所示。
需求确认后
由设计、开发、测试一起做WBS，将工作细化分解。根据分解后各部分工作量的详细估算，项目各方人员共同讨论，对计划进行细化调整。此时需进一步明确以下时间点：设计确认、功能完成、零缺陷(Zero Bug)、发布前代码冻结(Code Freeze)，以及里程碑完结日期，如图3所示。
至此，一个里程碑的计划已经基本成型，在接下来的执行过程中，需要不断监控计划的执行情况，识别并应对风险及各种变更，适当调整计划中各时间节点，并确保相关人员及时获知计划变更情况。
有时，我们需要对里程碑进一步划分，做更细粒度的计划，参见下面的“怎样做好计划”。
别忘了完成标准
简单来讲，完成标准就是该时间点需要完成的事项列表，或应该达到的某项指标(特定水平的Bug数量/性能指标等)。进度计划中的任何重要时间节点，都应该有一组完成标准。完成标准越早定义，计划按照期望完成的概率就越大。
以里程碑中最关键的几个时间节点为例，完成标准如下：
(1)需求/设计确认。执行所需的需求稿/设计稿已经完成(有时，并不一定需要全部完成，可以完成可接受的比例或核心部分完成，具体标准需要准确定义)，团队已准备好要编写产品代码。
(2)功能完成。所有定义的功能都已经完成(已通过冒烟测试，但允许有质量差距或Bug存在)，团队已经准备好将焦点转移到质量保证上，所有剩余问题都将作为Bug来跟踪。
(3)里程碑完成。质量已达到适当水平(如不存在高优先级的Bug等)，可以上线发布，或可以开始下个里程碑。
克服估算焦虑
做计划就离不开估算，很多人有估算焦虑症，这很正常。我们承认估算是困难的，所有估算都是一种概率事件。越早做估算，准确度越低。但只有进行粗略估算才能拥有一个起点，以做更好的估算。
大多数人利用直觉的本能反应来进行估算，通常是小团队短周期的项目，这种估算可以起到很好的效果。除直觉之外，有些方法可以帮助我们更好地估算，比如昨日天气法(Yesterday’s Weather)，通过分析团队的历史数据，得出生产率的估计。如果是一个新的团队，没有历史数据积累下来，可参考类似条件下的其他团队。
以零缺陷时间点的估算为例，我们就可以参考这个团队在之前的工作中，开发每天平均修多少个Bug，测试每天平均新发现多少个Bug，使用公式“当前有效Bug数 + 测试新报速率×X天=开发修复速率×X 天”，通过简单的计算就可得出天数X的值。去除节假日，并根据项目人员的投入情况留出一定的缓冲，零缺陷时间点就算出来了。
估算是一项能力，通过反复练习，估算的准确率能够得到有效提高。
怎样做好计划
首先，好的计划一定是团队共同参与才能制订出来的。在很多项目中，我们注意到计划往往是某个领导自己拍脑袋就确定了，其他人只有执行的份儿。这样的计划在执行过程中，会面临很大的风险与挑战。计划的本质是承诺，心理学告诉我们，要想让承诺更加有效，它必须得是当事人积极的、公开的、且经过一番努力后自由选择的。计划最终是要整个团队来共同执行的，那么制订计划就必须是一项集体活动，参与所带来的责任感能带来持久有效的承诺。千万别低估这一点。虽然共同参与会带来一定的成本，但实践表明，让相关人员公开参与计划的制订过程，对于提高计划的接受度、保障计划的顺利实施有极大的促进作用。
其次，善于规划的人，会把里程碑分割成一个个小的阶段，分而治之。例如，持续一两个月的功能开发期，一般会拆分成多次迭代来进行管理。那么计划要做到什么粒度呢?这里的原则是，方向越容易改变，变更越频繁，迭代的长度就要越短，反之亦然。每个迭代都需要制订单独的计划及完成标准。优秀的项目管理，要把握项目的节奏，张弛有道。
最后，好的计划必须跟进。最怕计划做了就不再看了，那不是计划，而是一张废纸。做了计划就必须跟进!
