进度落后所带来的必然失败
事实一次又一次地证明,向进度落后的项目中增加人手,只会造成进度更加落后: 一方面,向新成员解释目的、概念、思路、方法以及解决他们不能完全理解和掌握这些目的、概念、思路、方法所造成的问题带来大量的时间消耗;另一方面,原本的任务必须被重新分解成更多的可以并行工作的若干的单元,这些单元之间的协同和交叉测试所占用的时间也不容忽视:一个简单的模型如下,划分为四个单元的任务需要六条交流链条(如果两两之间都存在协作关系),而重新划分为六个单元后,交流链条就爆增为十五条,人手增加一半,协同工作和交叉测试所用的成本增加两倍。 我们已经观察到很多——今后还将观察到更多这样的现象:某些错误并不是因为新加入成员的水平无法达到项目的基本要求,如果这样的话,他们根本不会被当作“生力军”甚至项目的救星出现在工作岗位上,但由于对现有的问题不甚了解,他们往往犯下最严重而又最愚蠢的“罪行”。这样的“罪行”的出现,完全不应该归咎于新老成员中的任何一方,而必然是因为盲目将他们引进这一泥潭的主管所致。 而相反,减少人手也不会带来速度的提高。 固然,减少人手——以及带来的任务重新划分为较少的若干单元,会使得交流协作的成本能够降低,但除非团队中原本存在一个trouble-maker,我们并不能期待最终的进度会朝着好的方向发展:而trouble-maker的存在,本身是任务第一次划分就应该避免的问题。 那么,我们已经知道了,对于一个已经进度落后的项目,无论是增加或是减少人手,都无法从根本上解决进度落后的问题,那么,我们如何能够缓解这一问题呢? 一种较乐观的估计是,存在某种能够使得效率提高的“灵丹妙药”,它也许是一种框架,一种新的实现方法,总之,是能比现在所使用的系统在效率上更加优越的系统。下面我将分类讨论以证明这种“灵丹妙药”的不存在——而非存在——更具有必然性。 任何可能属于“灵丹妙药”的东西都可以被归类为以下两种之一:它要么是某种较为传统的,被项目中的大部分人所熟知的东西;要么是某种较为新潮的,仅为少部分人所知,甚至在项目的一开始尚未出现,不存在第三种情况。 假如存在某种传统的“灵丹妙药”,那么它必然具有“功能上不比现有系统更差”以及“效率上比现有系统更好”这两种特性(否则,我们无法苟同它是一种解决方案),那么我们必须扪心自问,我们一开始为什么没有采取这种大部分人都了解,性能又更令人兴奋的方案呢? 那么,是否