前不久，我半路接手这样的一个软件开发项目，项目像遇到了一个黑洞，不断地吞噬着项目组的时间。原来的项目经理因为时间很紧张，在匆忙中了解到客户需求后就开始着手做，也没有分具体什么阶段，到产品最后阶段要集成和测试的时候，大量原来没有预计到的问题都“冒”了出来，才发现项目进度完全失控。

　　业内流传着这样一句令人心酸的话：“规划规划全是鬼话，计划计划全是空话”。实际上，开发管理模式选择不当将极容易造成进度失控，也将会导致两个问题: 一是质量无法控制，二是时间无法控制。因为，项目进度的延迟总是在快到计划结束的时刻暴露出来，结果是谁也不知道到底什么时候才能够结束项目，到最后项目经理只好请辞。那么，到底问题出在哪呢?

　　艰难的项目进度管理

　　软件开发管理一直有一个令人困惑的难题，就是如何确保项目进度管理。项目进度控制是项目管理工作中的重要一环，也可以说是最艰难的工作之一。在软件开发中项目进度失控受到很多因素的影响，主要有以下几种情况：

　　(1)缺少进度指路明灯

　　当我们在路上行走的时候，会在沿途观看路标，当到达某一个路标时，我们便知道还有多少路或多少时间才能够到达终点。这些路标是我们在旅程中的里程碑，让我们可以清楚地知道目前所在地离开目的地有多远，也让我们能估算何时才能够到达目的地。

　　对于在路上行走的我们，可以通过路边的里程碑这一个简单工具来获知自己的进度信息。当进行软件开发的时候，我们也需要建立开发项目的里程碑，使我们知道项目的进度。里程碑是项目管理不可忽视的一部分，通常意味一个时间点上可交付成果的完成，好的里程碑管理就像一张地图指示我们走向项目目标的进度。

　　(2)项目进度估算准确性差

　　软件项目开发进度控制面临的最大挑战就是项目进度估算的准确性差。据统计，在对软件项目进度与成本估算时，大多数项目实际完成时间超过估算进度的25%到100%。根据我的经验要想对项目进度进行有效的估算，必须抓好以下两个方面：一是项目计划的可行性和可操作性，这是进度估算的基础。二是要对项目进度进行合理的度量，这样才能够获得项目的真实进展情况，并对项目估算做出相应调整。

　　(3)前松后紧，项目进度缺乏有效监管和控制

　　一般人在工作时都有前松后紧的习惯，而里程碑强制规定在某段时间做什么，从而合理分配工作，细化管理粒度。对复杂的软件开发项目而言，每一阶段的进度都需要逐步逼近目标，里程碑产出的中间“交付物”就是每一步逼近的结果，也是控制的对象。如果没有里程碑，中间想知道“现在进度做的怎么样了”是很困难的。

　　(4)没有尽早发现和降低项目风险

　　在软件开发中错误发现得越晚，对于开发造成的损失越大。里程碑式开发模式可根据每个阶段产出结果分期确认成果，避免血本无归。通过早期里程碑评审一般可以提前发现需求和设计中的问题，降低后期修改和返工的可能性。例如，在需求分析阶段发生的错误，那么最多就是把需求分析写一遍，损失的是一个人的劳动;而到了测试阶段发现了需求错误，再回去重新做需求分析，那么损失可能是致命的。

　　目标导向衍生里程碑式管理

　　一般来说，在项目开始时项目经理都会对开发项目进度制定一个详细的计划。通常情况下，这需要采用一些具体的开发模式技术，最常用的技术是网络计划和里程碑计划。网络计划是任务导向，以工作分解结构(WBS)为基础;里程碑计划是目标导向，以目标分解结构(OBS)为基础。有时两种方法可以混合使用，如在网络计划中设置里程碑。

　　(1)什么是里程碑式管理

　　里程碑是一个目标导向模式，它表明为了达到特定的里程碑需要完成的一系列活动。里程碑式开发是通过建立里程碑和检验各个里程碑的到达情况，来控制项目工作的进展和保证实现总目标。

　　软件开发项目生命周期中有三个与时间相关的重要概念，这三个概念分别是：检查点、里程碑和基线。检查点是指在规定的时间间隔内对项目进行检查，比较实际进度与估算计划之间的差异，并根据差异进行调整。我们可以将检查点看作是一个固定“采样”时点，而时间间隔根据项目周期长短不同而不同。里程碑是指一个具有特定重要性的事件，通常代表项目工作中一个重要阶段的完成。在里程碑处，通常要进行检查。基线则是指一个配置在项目不同时间点上通过正式评审而进入正式受控的一种(里程碑)状态。

　　三者的关系是：重要的检查点是里程碑，重要的需要客户确认的里程碑，就是基线。有一句通俗的话是这样描述：没有检查点，工作难进展，不设里程碑，项目往后推，基线不评审，客户吃不准。