尽信书不如无书：《人月神话中》外科手术团队模式的瓶颈

这次出差深圳, 有幸看到了一个真的按"外科手术团队"模式来构建队伍的组织. 当然他们不一定看过《人月神话》，组织结构“自然生长”地成为这种样子了：部门经理做架构设计、做技术攻关和主要编码工作，每周工作60小时忙得不可开 交，每个经理手下的6~10个人在编码上面基本帮不上什么忙，只是帮忙搜集搜集资料、写写文档、打打下手，没事了就上班时间上上网。他们之所以会自然生长 为这种结构，我认为是有原因的，一方面涉及核心技术的地方公司不愿意让太多人接触；另一方面深圳的人员流动率确实太高了，老板只能抓住稳定住几个核心人 员，而放任基层人员的流动，结果就够成了经理自己做设计写代码，部门成员帮不上忙只能打杂的这种团队模式。

 

《人月神话》里的观点，强调的是沟通成本会随团队规模的扩大而呈几何级数上升，因此团队大不一定好，反过来把设计和编码集中在少数几个高手身上，就可以降低沟通成本提高效率，所以提出了由“首席程序员、副手、项目管理员、编辑、秘书、程序职员”构成的开发团队结构。而我在实际中看到这个团队的很大瓶颈是：当需要开发大系统、大项目时，无法靠堆开发人员数量来压缩开发周期。 经 理们的时间就这么多，需要往前继续赶进度，除了他们没其他人可以帮上忙；团队的梯度建设得不足，招人进来后还需要培训，甚至连培训文档都得重新补，这件事 情还只能由经理自己来干。当开发周期无法压缩时，问题就很多了，最大一点就是风险变很高了，竞争对手的东西不断在变，新产品不断在出，谁能保证现在定下的 设计在将来一年后还保持一定的竞争力和领先性呢。

 

所以，《人月神话》更倾向于程序员的角度，程序员希望自己只做核心部分、不用沟通、少被杂事打扰，在这种环境下工作。这可能在求伯君开发WPS、史 玉柱开发汉卡的时代是不错的方法，或许也适合于现在做SNS游戏和做移动应用挂到AppStore上卖钱的小团队；而另一方面，想做点大的项目，都是动辄 上百人的并行开发工作，这需要架构师把框架设计得能够让尽量多的人在上面并行开发而不相互影响，然后再招几十几百个程序员并行开发把项目快速做出来，这种 情况下，没有团队梯度、无法并行开展工作的外科手术团队的模式就不适合了。