今天学习了一下什么是:人月神话
"人月神话"是 Fred Brooks 1975 年写的一本软件工程经典书,英文叫 The Mythical Man-Month。
核心意思就一句话:往一个已经延期的项目里加人,只会让它更慢。
因为"人月"这个单位本身就是个神话。管理者觉得一个人干十个月的活,十个人一个月就能干完,但实际上人一多,沟通成本指数级增长,新人还需要老人带,老人被拖慢,项目反而更晚交付。
Brooks 当时在 IBM 负责 OS/360 项目,踩了这个坑踩得死去活来,然后写了这本书。
五十年过去了,这个问题在AI时代反而更严重了。
因为以前加人好歹能分摊一些机械劳动。现在机械劳动agent干了,加人带来的几乎纯粹是沟通成本。
今天最好的模式是一人闭环。一个人加上agent,从想法到成品,中间不经过任何人。其次是两人闭环,再其次三人。
超过三个人,不管你怎么管理,都会陷入人月神话。
所以正确的做法是把大项目拆成一堆小项目,每个小项目最多三个人闭环。节点之间用协议连接,不用会议连接。
Brooks当年的结论是"没有银弹"。
五十年后银弹来了,但它不是让团队更大,而是让团队更小。
"人月神话"是 Fred Brooks 1975 年写的一本软件工程经典书,英文叫 The Mythical Man-Month。
核心意思就一句话:往一个已经延期的项目里加人,只会让它更慢。
因为"人月"这个单位本身就是个神话。管理者觉得一个人干十个月的活,十个人一个月就能干完,但实际上人一多,沟通成本指数级增长,新人还需要老人带,老人被拖慢,项目反而更晚交付。
Brooks 当时在 IBM 负责 OS/360 项目,踩了这个坑踩得死去活来,然后写了这本书。
五十年过去了,这个问题在AI时代反而更严重了。
因为以前加人好歹能分摊一些机械劳动。现在机械劳动agent干了,加人带来的几乎纯粹是沟通成本。
今天最好的模式是一人闭环。一个人加上agent,从想法到成品,中间不经过任何人。其次是两人闭环,再其次三人。
超过三个人,不管你怎么管理,都会陷入人月神话。
所以正确的做法是把大项目拆成一堆小项目,每个小项目最多三个人闭环。节点之间用协议连接,不用会议连接。
Brooks当年的结论是"没有银弹"。
五十年后银弹来了,但它不是让团队更大,而是让团队更小。