估時,一直是敏感問題。我甚至懷疑:它是必要之惡嗎?

儘管敏捷陣營發展出一些方法,像故意不給絕對數字,而是相對數字的 Planning Poker,但實際運作下去,仍然可能遇到〈專案的一般症狀〉點出的根本問題。

人性問題,不是 Delphi 法、PERT 法、Planning Poker 法就能完全解決的。



針對此問題,高德拉特博士的 CCPM 關鍵鏈,有一招很駭人的「對半腰斬」法:

Therefore, ask for task durations within the context of what the workers understand --- the way they usually commit durations if they commit them at all --- with full embedded safety included. Use these durations on the PERT. Let the CCPM software you have chosen later cut them in half to determine the overall un-buffered length of the Critical and Feeding chains and install half the remaining safety as buffers. What could be simpler?
--- Quote: The Critical Chain Implementation Handbook, p.157

不過,箇中道理,不是三言兩語講得完。

事實上,一年前的今天,寫〈明示的藝術〉這篇文章時,我也似懂非懂。

所以我還不敢用。



一年後的今天,在《瓶頸理論手冊》讀到 S-DBR 演進史,突然茅塞頓開。

原來「對半腰斬」法,並不只是用在 CCPM 方法身上,早在經典的 S-DBR 時期就已經出現了:



本章也提醒:

雖然 DBR 和 S-DBR 是規劃方法,但它們不是獨立使用的方法。應該將 TOC 控制機制——緩衝管理 (BM) 視為與前述的規劃方法不可分離。

我以前一直思考觸礁的,就是只看到「對半腰斬」這部分,忽略了搭配的另一部分「緩衝管理」。

許多 TOC 的設計,如果沒注意到配套的緩衝管理機制,就無法真正體會到它精巧的一面。

難怪 TOC 大師 Oded Cohen 特地寫一篇文章 "The TOC Buffers" 來推崇它:

The TOC Buffers are MORE than just the protection against uncertainty. TOC Buffers play a significant role in managing systems and flows.
It should be very clear that the TOC Buffers are a unique feature of TOC.


經過這一番頭腦體操,以後我就比較有把握,在需要的時候,祭出「對半腰斬」這一招了。


【補充】Bryan 給我一段很棒的建議,轉載於下:

這個要 Leader 與 Member 間有非常好的互信才能達成效果。Leader 絕對不能以單一任務的延誤為由給 Member 施壓,而 Member 得相信 Leader 會這樣做。全團隊的人把專案績效完全專注在「緩衝時間」的增減,而非個別任務是否 on-time。

還有一個難題,就是有些 Member 可能會覺得不公平:Member.A 負責的每個任務都拼命如期完成,但 Member.B 負責的任務常因故延誤,侵蝕到專案緩衝。Leader 不但不處罰/警告 Member.B,還要求大家一起加速...這時基於人性,Member.A 會不會不爽?覺得不公平?Member.B 會不會心想不甘我事,更加擺爛?這些都是執行 CCPM 要處理的問題!

回到最根本,團隊間是否信任(Leader-Member 或 Member-Member)?對於專案成敗是否都視為已任?還是非常非常關鍵的!