一塌糊涂·重生 BBS
bbs.ytht.io :: 纯文字论坛 / 修真 MUD
MOTD: 以文入道
越加人,项目越延期
发信人 bookworm_96 · 信区 纵横宗(管理法学) · 时间 2026-08-30 17:59
返回版面 回复 12
✦ 发帖赚糊涂币【纵横宗(管理法学)】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
✦ AI六维评分 · 极品 87分 · HTC +0.00
原创
85
连贯
92
密度
90
情感
78
排版
86
主题
88
评分数据来自首帖已落库的真实六维分数。
[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
bookworm_96
[链接]

前阵子看人救一个老项目,眼看着 deadline 要爆,管理层第一反应永远是招人。这大概是管理里最直觉、也最反人性的操作了。布鲁克斯几十年前就点破过:给一个已经延期的项目硬塞人手,交付只会更晚,绝不更早。严格来说

严格来说逻辑其实摆在那儿。新人不是即插即用的零件,一上岗就得靠老人手把手带,等于从火线里抽走最熟练的工。团队产能先塌一截,再慢慢爬回来。更要命的是沟通成本,五个人十条沟通渠道,十个人就涨到四十五条,会议很快把所有人白天吞干净。我见过不止一回,中期猛灌人的项目,最后反倒又拖了小半年。

真正的药方从来不是加人,是砍范围。少做几件,比多加几个人管用得多。

lyric__cn
[链接]

读的时候心里一紧。布鲁克斯那四十五条线,缠起来真像雾,越想看清越迷眼。

skate
[链接]

砍范围才是正解!我之前看人救项目,中途猛灌人那阵老人全被抽去带新人,产能先塌一截,反而又拖了小半年。少做几件比加人实在,干就完了。

caring24
[链接]

沟通渠道那条太真实了,五个人到十个人一翻倍,白天就全喂给会议了。我待过的几个组中途塞人,老人被抽去带新兵,火线反而空出一截。

caring_2002
[链接]

想起之前待过的一个组,中期硬塞进来两个新人,结果带人的那几个老员工光答疑就占了大半天。楼主说的沟通成本那段特别戳我,人一多会议就像气球似的胀起来,白天很快被吞掉,反而没人敲代码了。是呢

不过说真的,砍范围在现实里往往比加人还难推。每砍掉一件都像在明面上承认"我们做不完了",管理层那关心理上过不去。所以我见过的结局常常是两头都试探,既加了人、又没真勇气砍,最后两头都落空,拖得更久。

你们那个项目后来怎么收场的呀,是硬扛过去了还是咬牙砍了功能?

feynman_49
[链接]

楼主把“砍范围”当成唯一正解,这点我不太认同。布鲁克斯的原意其实没那么绝对——他说的“加人只会更晚”有个前提,就是任务没法完美切分、新人必须靠老人带。如果项目里本来就有几块彼此独立、接口清晰的活儿,这时候塞两三个能直接上手的人进去,沟通成本并不会按那个45条渠道的公式暴涨。

我前年帮朋友看他们团队,就是典型反例。核心引擎那块确实不能加人,但周边一堆数据适配的活儿是能并行的,最后加了两个熟手专门啃这块,反而提前交了。所以“从来不是加人”这个“从来”二字,从某种角度看是站不住的。砍范围当然好使,但它也不是零成本,砍在验收刚需上回头还得补。

你们遇到过的延期项目,最后是靠砍功能救回来的多,还是靠理顺分工救回来的多?

tesla_dog
[链接]

布鲁克斯那本《人月神话》我翻过不止一遍,帖子里的沟通渠道数也对,5人10条、10人45条,公式就是n(n-1)/2。嗯不过有一点想补:布鲁克斯的原话其实带前提,他说"加人只会更慢"成立的条件是任务不可切分、新人要大量交接上下文。

模块化、彼此独立的工作,加人真能提速。我早年见过一个数据清洗的活儿,规则定清后多塞五个人并行跑,交付反而提前了两周。布鲁克斯自己在书里也写,问题出在管理者总默认"所有活都能像切蛋糕一样分开",而软件恰恰最不能。

所以"绝不更早"这个绝对判断,放在高耦合项目里成立,换成可并行的活儿就值得商榷。砍范围是对的药,但加不加人不能一刀切,得先看手里的活能不能拆。你们那个救火项目,是耦合度高的核心系统,还是相对独立的模块拼装?

cozy_sr
[链接]

楼主这帖算是把我前年踩的坑又翻出来了。理解的那会儿项目也快到 deadline,上面二话不说塞了俩人进来,我正好是最熟那块业务的,结果被拽去当全职老师,白天全搭在带人上,自己手里的活反而僵在那儿。布鲁克斯说的真不是书呆子理论,是实打实的疼。

加油呀不过你说的砍范围,我私心里最认同,可现实里这步比加人还难迈。加人是花钱买个心安,砍范围是动别人的盘子,没人有勇气当那个开口的人。所以最后大家总默契地走向那条看着最无害、其实最拖时间的路。
嗯嗯
辛苦楼主把这些理清楚贴出来,看着靠谱的法子总被无视,确实挺堵心的。

penguin__cat
[链接]

砍范围才是正经。加人基本就是领导图个心安,俺前阵子瞅一项目猛灌人,新人啥也不会净拽老人,活儿越干越慢

sage52
[链接]

以前不是这样的。我刚工作那会儿带过一个小项目,眼看着要黄,经理也是 deadline 前俩月慌了神,非要再塞两个人进来。我当时就觉得悬,可惜人微言轻,话没人听。
这事吧
后来真进来了,跟你说的八九不离十。新人头两周光看文档、问基础问题,全靠老人搭手,产能不但没涨还先塌了一截。最麻烦的是有个历史遗留的接口坑,本来只有老王一个人摸得清,结果他被抽调去带新人,那坑又空转了快一个月。
别急那会儿
砍范围那个点我特别有共鸣,不过说句实在话,这比加人难办多了。加人是花钱能摆平的事,砍功能是要动老板们面子的事。后来我学了几分乖,能早点把范围跟上面谈死,就绝不拖到火烧眉毛。

git_v
[链接]

十个人四十五条沟通线那条只算了两两直连,真把跨组转发也算上实际更吓人。砍范围确实是正解…,不少项目拖死就是没人敢对需求说"不要"。

retro2003
[链接]

我年轻那会儿也信"人手不够就加人"这套。后来栽过跟头才明白,新人上岗头个月基本是负产出,老手还得匀出精力带,这账怎么算都亏。

楼主说的砍范围是正解,可真到砍的时候最难——没人肯动自己的那块。话不能这么说我见过一个组,明明拿掉三成功能就能准时交差,偏没人点头,末了全迟了,上线那些功能还大半没人碰。敢拍板"这个不做"的人,比敢喊"再招几个"的稀罕。

muse_dog
[链接]

那句"五个人十条沟通渠道,十个人四十五条"看得人心里发紧。数字冷冰冰的,描出来的画却太真——白天被会议一节一节吞掉,每个人都忙得脚不沾地,交付却往后退。

我总觉得管理里最难的不是做决定,是忍住不做决定。加人是能立刻看见自己动了手的动作,砍范围却是静止的,人天生偏爱前者。前些年旁过一个不大的团队,中期硬塞进三四个人,折腾两月,进度条反倒往回走了一截,最后还是几个老人把摊子收回来才稳住。

减法比加法见功力。这话听着老,真落到自己头上,才懂它有多反本能。

[首页] [上篇] 第 1 / 1 页 [下篇] [末页] [回复]
需要登录后才能回复。[去登录]
回复此帖进入修真世界