產品功能開發排序邏輯: Cost of Delay
這是這個系列的第六篇。
回顧一下這個系列走過的路：MoSCoW 讓你快速分類；艾森豪矩陣引入了急迫性；後來的價值/複雜度矩陣、Kano 分析、RICE/ROI，方向越發明確地往「價值」靠攏，試著回答「這件事值多少」這個問題，並且想辦法讓這個答案跟組織的 OKR 掛鉤。
但有一件事有點悄悄消失了：時間。
不是指「做這件事要花多久」，是「如果不做，隨著時間會造成多少損失」。
艾森豪矩陣算是有觸及這個問題的邊緣（急迫性本來就跟時間有關係），但後來的幾個框架，包括我自己比較常用的 RICE，基本上都沒有正式處理這一塊。
Cost of Delay（延遲成本，下稱 CoD）試圖把時間這件事拉回來，而且講得比艾森豪矩陣更精確。
CoD 在說什麼
精實開發的倡議者 Don Reinertsen 在《The Principles of Product Development Flow》中提出：每一個工作項目，每延遲一個單位時間，都在損失一定的經濟價值。這個每單位時間的損失，就是它的 Cost of Delay。
這個概念的延伸是一個排序原則：如果你只量化一件事，就量化這個。當多個待辦事項的 CoD 不同、完成時間也不同，理想的排序方式是 WSJF（Weighted Shortest Job First）：
優先序 = Cost of Delay ÷ 工作量
邏輯很直觀：同樣的延遲代價，先做比較快完成的那個，整體損失最小。Reinertsen 的書裡也提到，根據 CoD 和完成時間排序，比單純看 ROI 高低更能最大化投資組合的整體收益。
在概念上，WSJF 是很優雅的答案，問題在於計算實務。
計算 CoD 有多麻煩
要用 WSJF 排序，你得先知道每個工作項目的 CoD。而這件事說起來容易，做起來很麻煩。
大多數產品功能沒有明確的「晚一個月損失多少錢」的數字：
收入影響難以估算、涉及假設、各方對數字的解讀不同。就算你花了工夫去估，精確度也很可疑。
更棘手的是技術債、基礎建設、風險降低、研究探索這類工作，它們的 CoD 難以量化成金額，但又確實存在，強行估算反而可能製造「精確」的假象。我常跟朋友說：既然是估計，就有錯誤的空間；但是一旦東西化為數學，感覺起來好像就過於理所當然，這點在 ROI 當節也有提到過。
Kanban 的實務解法：四種 Archetype
Kanban 方法借用了 CoD 的概念，但用一個更務實的方式解決了計算困難的問題：與其精確估算每個項目的 CoD，不如先判斷它屬於哪種「延遲曲線的形狀」。
《Essential Kanban Condensed》整理了四種 CoD archetype：
- Expedite（緊急型）：CoD 極高，而且損失從一開始就持續猛烈地累積，沒有盡頭。系統當機、關鍵流程中斷、直接影響正在進行中的業務，只要還沒解決，每一刻都在虧。這類工作應該打破所有排序邏輯、立刻優先處理。
- Fixed Date（死線型）：在截止日期之前，CoD 幾乎是零；一旦錯過，損失瞬間垂直飆升。諸如法律合規、合約的上線日期、節慶檔期等等，這類工作的重點不是越快越好，而是要確認在最後責任時間點之前開始、在截止日前完成。
值得注意的是：Fixed Date 在截止日前其實不「急」 — — 用艾森豪矩陣的語言，它更像是「重要但不急」，直到接近截止日才會跳進「又急又重要」的格子。這是艾森豪矩陣沒有明確處理的地方，把「急迫性」和「死線」混在同一個維度，可能讓人太早或太晚開始處理這類工作。
- Standard（標準型）：大多數一般產品功能屬於這類。隨著時間推移，損失逐漸累積，曲線像一個緩慢爬升的平緩 S 型，最終在機會耗盡之後趨於平緩。這是 Kanban 的「基準等級」，越早做越好，但不是緊急。
- Intangible（無形型） 表面上幾乎感受不到 CoD，看起來不急，可以無限期往後推。技術債、品質改善、基礎建設、探索性研究都是這類。但風險在悄悄累積，在某個不確定的時間點，問題可能突然爆發，從「感覺不急」瞬間變成 Expedite。
這裡有個關鍵觀察：Intangible 的危險性恰恰來自它「看起來不急」。讀過艾森豪矩陣那篇的話，這跟「重要但不急」的象限幾乎是同一群東西 — — 都是對未來有幫助，但在當下永遠會被眼前的急事擠掉。
艾森豪矩陣那篇提到，「又急又重要」的事情數量很多，往往是先前「重要但不急」沒有好好照顧的結果。CoD 的 Intangible 提供了更精確的因果描述：被長期忽略的 Intangible，終在某個時間點爆發，變成 Expedite。那個時候再處理，代價通常遠比當初預防性地投入更高。
如何用這四種 Archetype 協助排序
實務上，善用四種 Archetype 的排序方法是先問「這個工作項目屬於哪種型態？」
不需要計算 CoD 的精確數字，光是判斷形狀，很多時候就已經足夠指引排序和排程的決定。
- Fixed Date 的東西要往前看時程，算清楚「最晚什麼時候必須開始」，而不是「應該什麼時候做完」。
- Standard 的東西依照正常流量處理，但它們的損失也在持續累積，不應該永遠排在 Expedite 和 Fixed Date 後面。
- Intangible 的東西容易被無限擠壓，最終突然爆發。建議明確保留一定比例的產能給這類工作，不要等到它「變成 Expedite」才處理。
- 而 Expedite，只要出現就快點認命做一做吧！同時也要時時留意各種跡象，避免所有事情都變成緊急。
使用 Cost of Delay 的優點
- 連結了時間與優先序的決策：前幾篇的框架沒有正式處理「晚做」的代價，CoD 讓這件事有了語言，不管是精確計算還是用 archetype 估算，都能把時間因素帶進討論。
- 改善討論品質：「這件事很重要」容易各說各話；「這個屬於什麼型態、晚做代價是什麼」通常能讓討論更快落地。
- 提醒不要讓 Intangible 永遠被排在後面：這是很多團隊的通病，技術債和基礎建設一直被擠壓，直到出問題。四種 archetype 的框架讓這件事有個名字，有名字才比較容易被正視。
缺點
- 計算與比較不同單位還是很難：實際使用 WSJF 計算排序需要估算 CoD 的數值，而這件事本身就很費力。四種 archetype 解決了「不知道怎麼分類」的問題，但沒有解決「不知道值多少」的問題。
- Expedite 容易被濫用：什麼都說緊急，就等於什麼都不緊急。如果沒有明確的政策限制 Expedite 的數量，這個框架會失去意義。
- 需要全隊有共同認知：archetype 要發揮作用，前提是參與排序的人對「什麼是 Fixed Date、什麼是 Intangible」有一致的理解，否則分類本身就會變成爭論點。
如果你要用 Cost of Delay 的話，這些想法給你參考
- 一樣，先對齊目標。判斷「這個是什麼型態的損失」還是要回到對產品和業務的共同理解，不然分類本身就沒有根基。這大概是我每篇都說的第一點了。可以考慮使用 ROI 那篇所說「所有的 R 基本上都對著 OKR」的想法。
- 不需要全部精確量化。光是判斷 archetype，就已經足以協助排序決定。如果能估算相對的 CoD 大小，再用 WSJF（CoD ÷ 完成時間）排序，是更完整的做法，但不是非這樣不可。
- 嚴肅對待 Intangible。明確決定產能裡有多少比例要給這類工作，不要讓它一直等到爆炸。
- 限制 Expedite 的數量。同時間最多一到兩件 Expedite，其餘的要求重新分類，否則「緊急」這個詞就失去了它應有的重量。
這個系列寫到這裡，我自己用過的和研究過的排序邏輯大致都講完了。比起前幾篇的 RICE/ROI，CoD 的框架又需要更多團隊共識才能真正運轉，但它提供了一個前幾篇都缺少的東西：讓「時間」在排序決策裡有正式的位置。你也許有其他結合時間這項因素進 RICE 的做法，但一切終歸就是這幾項元素：
- 成本（複雜度）
- 效益（與成本有時可以結合計算）
- 時間（警急程度）
- 信心指數
真的只剩一篇拖了很久的 HiPPO，簡言之跟資訊充足程度、責任分配情形有關，但總之再讓我多富奸一下…
- MoSCoW（近似 Now/Later/Future）
- 艾森豪矩陣 （重要性/急迫性矩陣）
- 價值/複雜度矩陣
- Kano 狩野分析
- ROI/RICE
- Cost of Delay（就是這篇）
- 也許不見得那麼沒道理的 HiPPO
我不時會在 LinkedIn 或 Facebook 分享些關於產品管理的看法/見聞/活動，另有讀書會跟線上諮詢，有興趣可以前往 https://www.bobchao.net
如果你覺得這篇還不錯的話，何不幫我按幾下掌聲，幫助演算法讓這篇飄遠一點，幫助其他跟你一樣的人？