如果说做项目不需要计划，恐怕没人会认同。是否每个项目计划都起到了作用呢？却不尽然。知道要做计划，但不知道为什么做计划，如何做计划的还是大有人在。所以很多计划沦为依样画葫芦，成了摆设。

IT项目计划的用意其实非常明确。因为我们无法事先知道系统最终会长什么样，和用户想象当中的是否一致，和用户的需求是否匹配，我们就需要通过一个计划，从需求，到设计，到测试最后做出来。每前进一步，都要保证不再返工回前一个阶段。如果一个计划不能起到应有的作用，项目都会在原地逗圈子。而这点绝不是靠某个天才的系统就能解决的。因为一个IT系统在完成之前，没人知道它到底长什么样，大家就不得不借助一些想象。即便有一些原型或者样板，也只是窥一斑而想象全貌。而群众的想象力是无限的。

其实乔布斯给人们的苹果，并不是人们想象中想要的东西，也不是超出你想象的东西。他给的是一个载体，一个窗口。通过它找到各自想象的东西。从而满足了人们的多样性需求。IT系统里也存在这样的系统，即工具层面的东西，随便你怎么用，但不要提要求。对于面向特定需求的系统，我们所做的就是先找到一个大体适用的方向，然后一起奔着这个方向走，且要不逗圈子或少逗圈子。

曾经遇到一个项目，每次项目回顾会上，都有一堆问题。很多问题都说不清楚需要花多少时间解决。还有一些问题，有了解决方案，也有了实施计划。但是，每每问起对整个项目进展有何影响时，项目经理都信心满满地说“没影响”。一次两次也就算了，后来明明某个任务推迟的不像话了，怎么还说不影响项目上线呢？让项目经理把里程碑计划展示一下，这才发现，这些有问题的任务都不和里程碑节点相关（所谓不在关键路径上），以至于都推迟到后一阶段，后后阶段了，还是不用调整里程碑计划。

---那确实需要推到上线时间点以后的问题呢？有这种事情吗？

---有！

---那如何不影响项目上线？

---放到上线后完善阶段了

做了十多年IT项目的我，一时间没听懂，上线后完善是个什么玩意。 只见过上线后支持，哪里又出来个上线后完善呢？　

后来才明白，这个项目计划，除了里程碑时间节点不变，其他都在变。凡是不能按时间完成的任务，都推迟、推迟，等推倒上线节点也兜不住了，就上线后再去完善了。

听懂之后，真有种想骂人的冲动。这是做项目吗？这不就是脚踩西瓜皮吗？ 整个一个不拿里程碑（milestone) 当石头。当它不存在，透明的，一概穿越。 最后完全是以任务节点构成的网络结构图在管项目进度，而没有了项目阶段的概念。

也许是为了心里安慰，因为有任务被推迟，项目经理又把能早安排的事情就提前安排了做。问题是，很多事情如果不是在里程碑节点上有个清楚的交代，那些提早做的事情完全有可能返工重做。比如开发还没结束，就安排一部分用户做试运行（pilot）。　如果开发完成后，有些地方又调整过，那么pilot小股部队就被牺牲掉了，成pioneer先驱了。　

至于那些所谓上线后完善的事情更是后患无穷。等到项目都剪彩、放鞭炮庆祝成功上线了，谁还会管完善不完善的事情呢。比这更糟的结果是，这“完善”最后成了没完没了的终生事业。那也就不叫项目了。

其实，项目里程碑节点就意味着质量门。在某些情况下确实会让步放行。但让步的时间和内容都是有底线。这个底线就是，让步放行的东西我是可以不要的。到总体验收的时候，确定无法完善了，也就认了。没有这个共识，就不可以让步放行。

IT项目其实就是从粗到细的设计，从细到粗执行。制定计划时，先做里程碑计划，明确大阶段目标。而明细计划只要做到当前阶段，所谓的“渐进明细”。不要急着把最后一天做什么都想好。但一定要从第一天就知道最后一个阶段的目标。

等到计划执行起来则从细到粗。在最细节操作层面的事情，需要反馈到最上层的里程碑计划中，以确定里程碑是否需要调整。在上文的案例中，常常是某件具体的事情都有计划了，比如项目上线时的数据迁移（通常是指未完成的业务操作，例如未关闭的采购订单等）计划。但这是一个个孤立的任务计划，和里程碑计划的关系完全忽略。而作为一个项目，因为其独特性，非常有必要把网络化的任务关系分派到各个大阶段上，然后在里程碑节点上进行“前进还是后退”的评估。里程碑是项目进程中真正的基石，打下桩，就可以继续向前，不再回头看。