起源故事 · 从工厂瓶颈到项目管理
Origin Story · From Factory Bottlenecks to Project Management
1997 年,Eliyahu Goldratt 又写了一本小说《关键链(Critical Chain)》,把约束理论从工厂搬进了项目管理。
他盯着传统的关键路径法发难:它假设资源取之不尽,可现实里一个专家被三个任务同时抢,谁先谁后早把计划打乱了。
他还揭穿一个公开的秘密 —— 每个人报工期时都偷偷多报 50% 当安全垫,
结果学生综合症(拖到最后才干)和帕金森定律(时间填满)把这些垫子全浪费光。
高德拉特的解法:把安全垫从每个任务里抽出来,汇成项目末端一个共享缓冲,
统一保护整个项目,工期反而更短、更准。
In 1997, Eliyahu Goldratt followed up The Goal with a second business novel, Critical Chain, moving the Theory of Constraints out of the factory and into the project room.
He took aim at classic Critical Path: it pretends resources are unlimited, but in real life one expert is being yanked between three tasks at once, and the plan unravels before the first week ends.
He also called out an open secret — every estimator quietly inflates their numbers by about 50% as a private safety pad,
and then student syndrome (waiting until the last minute) and Parkinson's law (work expanding to fill the time) burn those pads anyway.
Goldratt's fix: pull the pads out of each task and pool them into one shared buffer at the end of the project,
protecting the whole schedule as a single system — and the project actually finishes sooner and more reliably.
1 项目网络:依赖之外,还有资源冲突 Project Network: Dependencies Aren't the Whole Story
关键链(含资源)Critical Chain (with resources)2 抽出安全垫,汇成项目缓冲 Pull the Safety Pads, Pool the Project Buffer
上排:每个任务各自留 安全垫(浅橙),全程被浪费。下排:把垫子抽出来压成纯工作量,末端汇成一个项目缓冲(绿)。聚合后的缓冲比各自相加更小 —— 这就是更短工期的来源。 Top row: every task hugs its own safety pad (pale orange) — and burns it. Bottom row: strip the pads out, leave just the pure work, and pool the slack into one project buffer (green) at the tail. The pooled buffer is smaller than the sum of the individual pads — that's where the shorter schedule comes from.
3 现实里的关键链 Critical Chain in the Real World
CCPM 工期:研发/建造项目用关键链法,缓冲集中管理,按缓冲消耗率(不是任务完成率)追踪进度。
CCPM scheduling: R&D and construction projects run on Critical Chain — buffer is managed centrally, and progress is tracked by buffer burn rate, not task percent-complete.
资源冲突:关键专家、共用设备被多任务争抢,是项目真正的瓶颈,远比纯依赖路径致命。
Resource contention: a star engineer or a shared piece of equipment being yanked between tasks is the real bottleneck — far more lethal than the longest dependency path.
缓冲集中:与其每个任务都留安全垫被浪费,不如汇成共享缓冲,统计上更省、更能吸收波动。
Buffer pooling: instead of every task hoarding a private pad that gets burned anyway, pool them — statistically you need less total slack to absorb the same variation.
缩短工期:去掉学生综合症与多任务并行,关键链项目常把交付期压缩 20%~40%。
Shorter delivery: kill student syndrome and bad multitasking, and Critical Chain projects routinely cut delivery time by 20–40%.
一句话In One Line
关键路径只回答"哪条依赖链最长",却假装资源无限;关键链多问一句"同一份资源被谁抢,谁该先干",
于是找到了项目真正的约束。再加上一个统计学洞见:把分散的安全垫聚成一个缓冲,波动相互抵消,总量反而更小。
于是关键链法把工期缩短、把进度从"盯任务完成率"改成"盯缓冲消耗"。
这正是约束理论在项目世界的化身:识别约束(关键链)、保护约束(缓冲)、按约束节奏调度。
Critical Path only answers "which dependency chain is longest" and assumes resources are infinite. Critical Chain asks one more question — "who is fighting for the same resource, and who goes first" —
and that's how it finds the project's real constraint. Add a statistical kicker: pool the scattered safety pads into one buffer, let the variations cancel out, and the total shrinks.
That's how CCPM cuts schedules and switches the progress signal from "task percent-complete" to "buffer burn rate".
It's the Theory of Constraints reborn for projects: identify the constraint (the critical chain), protect it (the buffer), and schedule everything to its drumbeat.
常见误用Common Mistakes
只算关键路径,忽略资源争用。用关键链:资源冲突常让真正的瓶颈链与依赖路径不一致。
Running pure Critical Path and ignoring resource contention. Use Critical Chain — resource conflicts often make the real bottleneck chain diverge from the longest dependency path.
每个任务各留安全垫还层层加码。抽出安全垫汇成项目缓冲,聚合后总量更小、更抗波动。
Padding every task individually and then padding the padding. Pull the pads out and pool them into a project buffer — the pooled total is smaller and absorbs variation better.
用任务完成百分比追踪进度。用缓冲消耗率预警:缓冲被吃得越快,越该提前干预。
Tracking progress by task percent-complete. Watch the buffer burn rate — the faster the buffer is being eaten, the earlier you intervene.