在众多软件项目中，缺乏合理的进度安排是造成项目滞后最主要的原因，很多时候比其他所有因素加起来的影响还要大，特别是在软件项目开发中。为什么这种情况会如此普遍？

4.3.1 对项目范围规定不明确

准确地说，我们可能从来没有估算准确过。常用的估算方法有类比估算法、参数估算法、三点估算法和自上而下估算法。最常用也最准确的是自上而下估算法，也就是通过从下到上逐层汇总WBS组成部分的估算而得到项目估算。看到这个名称就知道估算工作既复杂又烦琐，还要基于范围管理中分解合理的WBS。

WBS是基于什么？基于范围说明书。范围说明书又基于项目需求文件，而项目需求文件又基于项目章程、合同、相关方的期望等。是不是感觉非常复杂，逻辑关系太长，中间有一点出错，后面的偏差就会越来越大。

项目范围历来是项目经理碰到的第一个也是最大的“拦路虎”，项目进度计划的准确与否就与项目范围息息相关。所以，这是造成进度安排缺乏合理性、项目滞后的第一个原因。我们采用的估算技术通常都是假设人是通用的，在软件中简单地把“人”和“月”当作可以互换的单位，这样极易造成进度与工作量相互混淆。

4.3.2 忽略专业技能和沟通成本

如4.2.1节所述，我们用来制订项目进度计划常用的关键路径法，就是在不考虑资源限制的前提下，当然能得出理论上的最短路径，也就是项目最快的完成时间。但是，软件开发不是简单的体力劳动，不是简单的工作堆叠，是拥有复杂逻辑的系统性的工作，其中人是最重要也是最核心的因素，特别是随着技术的发展，分工越来越细，岗位要求也越来越高。现实情况是，很少有人能够同时具备两个细分领域的专业知识并且把事情做好。

比如我们要开发一个仓库管理软件（WMS），经过确定范围、WBS分解、定义活动、排列活动顺序后，就开始估算时间，一般情况会怎么估算呢？比如张三做需求分析需要1个月，李四做设计需要1个月，王五、赵六做开发需要2个月，孙七、周八做测试需要1个月，那么这个项目最快完成时间是5个月，一般需要8个月。在很多项目经理眼里，如果这项软件开发投入6个人完成时间为8个月，那么投入16个人是不是不到3个月就能完成？或者让做开发和测试的也投入需求分析和设计工作，是不是就能压缩需求分析和设计的时间了？

这种想法在软件开发领域看上去是无稽之谈。但实际上，这在软件项目中每时每刻都在发生着，在我十几年的软件项目生涯过程中，几乎就没有中断过，包括我在写本书的时候，我所在的组织也在不停地犯这种错误。项目经理或者发起人，甚至利益相关方，从来就没有考虑过开发人员根本就不具备设计的技能？或者说他们知道，只不过选择忽视，只想让项目经理早点交付。

除了没有考虑的团队成员的专业技能之外，我们在估算时经常会犯的第二个错误就是忽略沟通的时间和成本。一旦某项工作被分解且需要相互协作，只要是人来承担这些工作，那么必然就会需要沟通交流，这是不可能避免的事情。

人数和时间的简单互换仅仅适用在工地搬砖或者田里割稻子的情况下，这些极其简单的工作能够被分解且人们之间不需要交流沟通，但是这在系统性的软件开发项目中几乎不能。当任务因为逻辑上的先后顺序的限制不能分解或者并行时，增加人手对于进度没有任何帮助。就像每一位母亲，孕育一个生命需要10个月。无论如何，都改变不了这个时间进程。

所以，我们必须把沟通的工作量和时间加入估算中，而沟通成本又分为两部分。第一部分是培训，每个成员都需要进行技术、项目目标、总体计划及工作计划的培训，每加入一位成员，都必须重复这项工作且无法避免；第二部分是相互之间的交流，我们知道交流沟通的通道就是成员人数来计算的，具体公式如下。

沟通成本 = n（n-1）÷2

也就是说，三个人沟通的成本是两个人的3倍，四个人沟通的成本是两个人的6倍。增加人手以后带来分担任务的帮助被所增加的沟通工作量完全抵消，甚至还会产生很大的副作用。所以，增加更多的人手，实际上是延长而不是缩短进度。

4.3.3 对估算过程缺乏耐心和信心

软件项目经理通常不会有耐心地自下而上，持续有耐心地进行估算这项工作，越没有耐心，估算出来的持续时间，以及以此为基础的进度计划就越不准确，越不准确对自己的估算越缺乏信心，越缺乏信心就越没有耐心去估算，这是一个恶性循环。

事实上，项目经理缺乏耐心，很大程度不是不专业，而是来自发起人或者关键相关方，也就是甲方无休止地催促和不合理的要求。

就像去餐厅吃饭，客人要求两分钟内吃到一个煎蛋，要不然就去别的餐厅，厨师表示无法在两分钟内完成一个煎蛋。但是负责人不仅收了客人的钱，还亲自来厨房催促厨师。厨师怎么办，没有办法，他只能选择把火开到最大，去做一件完全超出他的经验和把握的事情，但是结果是这个蛋一面焦了，另一面还是生的。客人不仅没有在两分钟内吃到煎蛋，还浪费了很多成本。

项目经理往往为了满足甲方的期望和发起人的要求，计划了不合理的进度。不能说项目经理缺乏勇气和坚定，只能说现实的情况使软件项目经理缺乏足够的方法、技能、策略去制订更优的进度计划。或者在基于可靠基础的估算出现之前，项目经理需要挺直腰杆，坚持自己的估计，确信自己的经验和直觉比其他非专业人士从各自利益角度出发而派生出来的结果好。

4.3.4 对项目进度缺乏跟踪和监督

在其他工程领域中，比如汽车制造、建筑业等有非常完整的质量保证体系和跟踪体系，而在软件项目中，质量是非常容易被忽略的因素。很多人认为软件不像制造汽车、建一栋楼，错了就不能改了，因为建楼不能拆了重新建，所以中间会设置很多检查点，由专门的人员进行检查和监督，甚至还有第三方的监理公司。

在软件开发项目中，常见的现象就是在开发阶段配置一两个测试人员，甚至连专职的测试人员都没有。因为大家普遍的观念就是：几行代码而已，发现不对了随时可以改。

软件项目中，质量并不是由一个测试人员就能够保证的，它是一个体系，具体内存可参考第6章的项目质量内建七步法。

当意识到进度发生偏差时，通常是进度落后的时候，第一反应就是加人。这也是人们在碰到赶工期时候的第一反应，人多力量大。就像第二点谈过的那样，向进度落后的项目中增加人手，只会使进度更加落后。

当然，人多力量大这句话在一些劳动密集型的行业，或者只需要体力劳动的工作中，比如工地搬砖、田里割稻子，似乎是成立的。为什么是似乎，就算再简单的工作，也需要合适的方式方法，要不然简单的堆人，效率也不一定高，你会感觉人越多越乱。

更何况是软件开发这种知识密集型领域，简单地增加人手不仅没有任何正向的作用，反而会加重项目的延期情况。

项目管理本身就是一个系统性工作，何况项目进度管理计划也是按照资源来设计和计划的，特别是软件项目，最重要的是人，并且也是按照某人完成活动需要多少时间估算的，活动的逻辑顺序先后排列的。

增加人手意味着要把一切计划打翻重新做，这不是在做负功吗？加几个人？增加的人是不是具备相应的技能？增加的人是否能够管理好？沟通成本上升了多少？协作成本上升了多少？更何况增加人手必定会增加成本，又会引发一系列的问题。

所以，“人月”看上去很美，在软件项目中，可以用来代表项目规模，也可以用来估算项目时间，甚至还能粗略计算出项目成本，但它是一个“神话”，永远实现不了。