进度落后所带来的必然失败

事实一次又一次地证明，向进度落后的项目中增加人手，只会造成进度更加落后：

一方面，向新成员解释目的、概念、思路、方法以及解决他们不能完全理解和掌握这些目的、概念、思路、方法所造成的问题带来大量的时间消耗；另一方面，原本的任务必须被重新分解成更多的可以并行工作的若干的单元，这些单元之间的协同和交叉测试所占用的时间也不容忽视：一个简单的模型如下，划分为四个单元的任务需要六条交流链条（如果两两之间都存在协作关系），而重新划分为六个单元后，交流链条就爆增为十五条，人手增加一半，协同工作和交叉测试所用的成本增加两倍。

我们已经观察到很多——今后还将观察到更多这样的现象：某些错误并不是因为新加入成员的水平无法达到项目的基本要求，如果这样的话，他们根本不会被当作“生力军”甚至项目的救星出现在工作岗位上，但由于对现有的问题不甚了解，他们往往犯下最严重而又最愚蠢的“罪行”。这样的“罪行”的出现，完全不应该归咎于新老成员中的任何一方，而必然是因为盲目将他们引进这一泥潭的主管所致。

而相反，减少人手也不会带来速度的提高。

固然，减少人手——以及带来的任务重新划分为较少的若干单元，会使得交流协作的成本能够降低，但除非团队中原本存在一个trouble-maker，我们并不能期待最终的进度会朝着好的方向发展：而trouble-maker的存在，本身是任务第一次划分就应该避免的问题。

那么，我们已经知道了，对于一个已经进度落后的项目，无论是增加或是减少人手，都无法从根本上解决进度落后的问题，那么，我们如何能够缓解这一问题呢？

一种较乐观的估计是，存在某种能够使得效率提高的“灵丹妙药”，它也许是一种框架，一种新的实现方法，总之，是能比现在所使用的系统在效率上更加优越的系统。下面我将分类讨论以证明这种“灵丹妙药”的不存在——而非存在——更具有必然性。

任何可能属于“灵丹妙药”的东西都可以被归类为以下两种之一：它要么是某种较为传统的，被项目中的大部分人所熟知的东西；要么是某种较为新潮的，仅为少部分人所知，甚至在项目的一开始尚未出现，不存在第三种情况。

假如存在某种传统的“灵丹妙药”，那么它必然具有“功能上不比现有系统更差”以及“效率上比现有系统更好”这两种特性（否则，我们无法苟同它是一种解决方案），那么我们必须扪心自问，我们一开始为什么没有采取这种大部分人都了解，性能又更令人兴奋的方案呢？

那么，是否存在一种较为“新潮”，甚至刚被“研制”成功的“灵丹妙药”呢？答案也是不乐观的。一方面是软件界广泛存在的有意或无意的夸大：一种宣称更有优势的方案在迭代若干个版本以前，常常并不能表现出它自称的那样大的优势；另一方面，因为只有少数人知道这一方案的“精要”，那必然带来的结果是，像是加入新成员那样的解释和培训目的、概念、思路、方法以及解决不能完全理解和掌握这些目的、概念、思路和方法的时间消耗同样存在。

那么，既然一种较为乐观的估计被证明并总是具有客观上的可行性，较为悲观的估计又是怎样的呢？

答曰：重新审视项目的需求和进度，裁剪掉部分低优先级的、非功能性的模块，以降低任务本身的复杂度。

通常来说，这似乎是项目主管在发现进度落后之后仅剩的可行方案。缺乏顶层设计的团队和任务模式必将带来灾难性的后果，当然，采用某些项目组织上的变通手段可能会缓解以上的问题，一些可能有用的方法包括：以总线式的布局来组织所有子团队，以降低任务重新划分所带来的单元测试时间的爆炸性增长；或是以非均分的方式划分进度考察点，以保证在较早的时间发现可能出现的进度落后：但我十分怀疑以上的方法能否从根本上解决项目进度落后的问题。