我们常常看见，在项目初期，有一大堆计划需要制定，什么“开发计划”“需求计划”等等等等一大堆计划。可是这些计划一般有两个下场：

1、废弃不用（缺乏流程管控的项目。好像这样的项目组越来越少了，在此就不给出进一步的解释）。

2、等待“变更”（有流程管控的项目）。

其实无论什么“计划”，其差不多都是和小时候定的“学习计划”在功效上差不多的。“计划”的目的在于“执行”（以便于我们达成“目标”）。我记得，老师或者家长帮助我们制定学习计划的时候，总是要提醒我们留出足够的休息时间，娱乐时间，这一切都是为了“可执行”。“计划”是靶子，“可执行”是射箭；“按照计划执行”就是“指哪打哪”。

而我们常常遇到的是，制定计划的时候缺乏对于“可执行性”的考虑，但是为了计划能够顺利的“所谓的执行”，就不断的“变更计划”。通过变更计划，把原定的“指哪打哪”修改成了“打哪指哪”。

为什么我们上小学就知道的道理，到做项目的时候又全部忘记了呢？问题的关键在于我们只学到了“软件过程”的形，而没有学到“软件过程”的神。制定计划的目的成了为了满足“流程需要”而计划变更就更是为了“流程需要”。因此在自觉与不自觉的情况下，制定出为了“等待变更”的项目计划。

而项目计划远比“学习计划”复杂，其中不仅仅需要涉及多个项目组成员的相互配合，还需要涉及协调项目组外的相关资源；同时，由于“项目目标”也远比“学习目标”复杂。因此，项目计划的可执行性就更加的难以控制。但无论如何，“可执行性”永远是计划的第一要素，甚至高于“项目目标”。试想，有多少不切实际的 “项目目标”害了一堆堆的先烈们。

但是如果确实出现了“计划赶不上变化”的情况如何处理呢？解决这个问题的核心在于：维持可执行性，砍掉不切实际的需求。想想我们小时候如何对待“不能按计划执行”这个问题的，我们采取的措施一般都是“删除部分待学习内容”以及“减少学习时间”。同样，这也是唯一的应付项目中“计划赶不上变化”的方法。在保证计划“可执行”的前提下，删除部分待开发内容。而这些待删除的内容自然就是“低优先级”的需求。在我看来，没有“优先级”的需求就不算“需求”

如果需要深入了解“计划”，建议大家暂时放下“项目管理”这个课题；去了解一下“时间管理”等这些相对粗浅的理论。这样反而有助于理解“项目计划”真正的内在含义。从这里面，也可以充分的了解到“工具”对于“本质”并没有什么实质性的改善。当理解了“项目计划”的本质，工具可以起到帮助作用；但是工具绝不能帮助理解“项目计划”的本质。

呵呵~~个人看法,欢迎指正