项目计划与日程表的悖论

 

笔者问过不少做软件项目管理的人，问他们感觉最困惑的事情是什么，大部分人的回答是“如何制定一个真正有意义的项目计划”。

项目开始不久，客户和老板就会来要项目的计划；而此时项目组还不清楚项目的规模等细节，自然也定不出具体的工期与日程表；被逼无奈之下，项目经理只好先编造一个计划来应付了事。

这里出现了一个悖论：项目初期是否需要制定一个计划来指导项目后续工作的开展；如果需要，那么在项目细节不清楚的情况下，是否可能制定出一个足够准确的日程计划；如果计划本身不正确，那么又如何指导项目的工作。

打破悖论的关键在于我们如何理解“计划”本身。人们常常将计划plan等同于详细的日程表schedule，这是对计划的一种狭隘理解。所谓计划，指的是人们事先对未来要做什么、以及如何做的一种约定，它并不一定要具体落实到日程表上。

工程项目的最初计划，描述的是项目组选择怎样的工程方法来解决项目问题。具体到软件项目计划，其内容应当包括：项目组选定了什么样的开发生命周期模型（比如迭代模型），设定了几个里程碑阶段；准备采用什么样的软件过程（比如UP统一软件过程）来组织项目的开发活动；以及按照什么顺序来从事相关活动（比如是否在需求开发前先做业务建模）。总之，项目计划实质上可以看作是标准的工程方法与过程在当前项目中的一次实例化。

项目组明确项目的性质并不需要太多时间，项目经理很快就能够在计划中，记录下如何应用适合本项目性质的方法的决定，并定下较近时间（比如一周）内的日程安排；之后项目组遵照计划中的方法来执行各项活动；当项目组对项目的了解程度足以支持精确估算项目规模、工作量时，才正式制定详细的日程表，它规定了较长时间内（例如几个月）的日程安排。也就是说，先决定怎么做，然后才确定做的具体时间。

作为客户和老板，总是有一开始就想知道项目的工期和成本的冲动。这种心理虽然可以理解，但却违背了自然规律。项目初期问项目组要项目计划的真实目的，不是了解项目何时能够结束，而是用来监督项目组是否选择了正确的方法，项目是否在朝着正确的方向推进。我们必须清楚一件事情——时间搞错了会使项目延期，但方法搞错了却可能使项目失败。