---
title: Brooks法则：“向进度落后的项目中增加人手只会使进度更加落后”
canonical: "https://xiaofeng.dev/writing/brooks-law/"
pubDate: 2016-06-10
author: 唐小锋 Xiaofeng TANG
description: A：“离系统上线只有3个月时间了，还有这么多功能没有做，怎么办？”
tags: [Software Engineering, Project Management]
---

A：“离系统上线只有3个月时间了，还有这么多功能没有做，怎么办？”

B：“可以从隔壁团队抽调一个工程师来帮忙吗？领导对这个项目很重视。”

A：“好，应该可以抽调两个来，他们都是经验丰富的程序员，争取在1个月内完成。”

最后他们成功地把项目拖延了4个月，比没有添加人手的预计还要晚。

向进度落后的项目中增加人手只会使进度更加落后。

——《人月神话》里面提到的Brooks法则

软件项目的特征

软件项目的估算和进度安排一直是个难题，无论多么努力都很难保证精确，总需要在过程中不断调整，要么重新安排进度，要么削减任务，但追加人手要慎之又慎。首要原因还是软件项目团队需要高强度的沟通和协助，不是单纯的工作组。

![图片](/writing/wechat-tech-assets/brooks-law/b651ebd1bd383f2d.png)

沟通接口增加。每增加一个人，就会增加n个接口。如果项目中有n个工作人员，则有(n2-n)/2个项目交流的接口，团队组织的目的是减少所需的交流和合作的数量，清理交流障碍。

培训时间和额外的测试。不培训是灾难性的。无论多么能干员工，都需要接受一位或者多位项目中原有员工的培训，还需要重新划分任务，安排系统测试，更别提刚刚上手的员工所带来的必不可少的混乱（沟通摩擦、代码上的bug）和原有员工填补混乱的时间。

项目估算的原则

小心使用人月，人数和时间是两个独立要素，不能互相替代，你不能把“2个人花2个月”变成“4个人花1个月”。人数和时间可以互换仅仅适用于如下情况：如果某个任务可以分解给参与人员，并且他们之间不需要相互交流——在软件项目中这几乎不可能。

对项目经理而言，仍然存在很强的诱惑去添加更多人手，如果非要这样做，请在早期做，而不是等到进度落后才添加。