在這樣一個數(shù)字化的時代，決策的實時程度是決定企業(yè)響應(yīng)力高低的關(guān)鍵。因為爭吵不休、決策過程過于拖沓而錯失良機的案例屢見不鮮。在IT組織中，隨著交付團隊敏捷與精益化的深入，對于業(yè)務(wù)決策效率的詬病與日俱增。

一、業(yè)務(wù)決策中的常見場景

場景1： 眾多項目難以開始、決策周期長、討論范圍大（V記）

團隊相當(dāng)長一段時間沒有項目可做，開發(fā)團隊之間因為寥寥無幾可以開始的項目而相互爭搶。幾次客戶的產(chǎn)品負責(zé)人來武漢出差，給團隊展示的一個項目機會Spread Sheet，里面堆滿了項目，花花綠綠的顏色代表著優(yōu)先級、時間表、估算等等，然而客戶走后還是沒有可以開始的項目。在此期間充斥著包括業(yè)務(wù)、技術(shù)、市場部門的人反復(fù)長時間的討論。團隊因為沒有真正可以做的項目而士氣低落，客戶的管理人員為了提升交付團隊的工作飽和度而安排一些并非有價值的工作，導(dǎo)致雙方信任度大幅降低。最后：

• 有的項目真的開始了，一定是最有價值的項目嗎？
• 有的項目開始了，但是沒多久又終止了
• 有的項目沒有開始，還是堆積在那張滿滿的Spreadsheet里，過一段時間又被拿出來長時間討論

場景2：項目源源不斷、交錯并行、交付不斷推遲（H記）

與場景1情況不同的是，H記風(fēng)控部門，當(dāng)前交付團隊忙的不可開交。
每個Component“團隊”有好幾個成員，好幾個項目在并行開發(fā)，每個項目上少則一個人，多則幾個人。一個團隊成員同時承擔(dān)多個項目，一會兒做A，一會兒做B，一會兒做C，每天在好幾個項目之間的切換，開各種會。每個項目要真正給終端用戶帶來價值，需要好幾個component集成，但是這個項目在不同component團隊之間的優(yōu)先級各不相同。產(chǎn)品負責(zé)人員每天開會就是跟蹤進度，發(fā)現(xiàn)進度慢，就在項目立項之初增加項目個數(shù)，意在保證最后能有幾個項目可以按時交付。結(jié)果可想而知，交付團隊疲于奔命，業(yè)務(wù)團隊也不滿意產(chǎn)品的質(zhì)量和進度。交付抱怨資源不足，需要增加人員，業(yè)務(wù)覺得錢花得不值。曾經(jīng)一個團隊負責(zé)人展示給我一個Spread sheet，里面有70多個項目已經(jīng)排定優(yōu)先級等待交付團隊完成。

二、問題在哪里？

此刻，讀者的腦子里可能已經(jīng)閃現(xiàn)出了很多問題，其中一個非常值得討論的是，在進入交付之前，產(chǎn)品負責(zé)人到底如何做業(yè)務(wù)決策？采用什么樣的決策模型？
傳統(tǒng)的方式是，產(chǎn)品（業(yè)務(wù)）部門通過主動或者被動方式收集到來自于各個渠道的需求后，將所有機會點集合起來，然后組織業(yè)務(wù)提出方、交付團隊以及財務(wù)等決策人員放在一起討論，有些公司甚至在項目交付開始之前都沒有邀請交付團隊代表出席業(yè)務(wù)決策。他們討論的內(nèi)容涵蓋大家熟知的傳統(tǒng)項目管理鐵三角- “Scope-Cost-Time”，具體討論可能如下：

• Scope - 只有確定項目大致范圍，才能做決策。比如V記的做法是，對于機會點設(shè)計幾個Gate，在到達每個Gate之前采用T-Shirt Size的方式+一定百分比的誤差。當(dāng)然這個過程中還需要考慮的因素很多，比如技術(shù)風(fēng)險，哪些地方需要第三方來做，哪些地方自己集成。在H記，面臨的挑戰(zhàn)是業(yè)務(wù)團隊每個人負責(zé)一堆項目，大家各自為戰(zhàn)，對接不同交付團隊，項目獨立又相互依賴，遲遲不能就Scope達成一致。
• Cost - 這是非常復(fù)雜的部分，因為成本涉及到好些因素，特別是項目大小，比如V記的做法是將項目估計出來的故事點對應(yīng)一定量的產(chǎn)品開發(fā)cost；然后來跟掌握投資的部門以及財務(wù)部門argue；比如一個story point交付成本是$6000 AUD，來初步估計cost。
• Time - 這是爭論無休止的地方，也是交付團隊跟業(yè)務(wù)之間的關(guān)鍵矛盾點，因為涉及到交付團隊對于時間的承諾。

根據(jù)Black Swan Farming的案例，在以上決策過程中，一個Feature從有想法到最終交付上線的平均時間是46周，而其中的等待時間是38周。
誠然，在產(chǎn)品機會點管理與決策過程中要考慮的因素還遠遠不止于此，但結(jié)果是文章一開頭出現(xiàn)的兩個典型場景。除此之外，在日常工作中，產(chǎn)品負責(zé)人需要不斷回答類似如下的問題：

1. 是否應(yīng)該花額外的錢來加速某個項目？
2. 是否應(yīng)該增加新的功能來推遲項目上線？
3. 是否應(yīng)該在這個項目上增加人手？
4. 是否應(yīng)該將項目X的優(yōu)先級提升到項目Y之上？

三、常見的業(yè)務(wù)決策工具

所謂的業(yè)務(wù)決策，落實到最后是在不同機會點之間（或者呈現(xiàn)為項目）對比然后做出選擇。常見的業(yè)務(wù)決策人員決策雷達上的工具有：

1. MoSCoW（Must, Should, Could, Won't）
2. HiPPO（Highest Paid Person’s Opinion）
3. ROI（投資回報率）
4. Benefit-Cost Ratio（收益成本率）
5. Kanban Class of Service（看板方法的服務(wù)等級）

大家可以嘗試對如下場景做出選擇，有如下兩個供應(yīng)商可以完成一個項目：
供應(yīng)商A：Cost - 100K，Time - 10W
供應(yīng)商B：Cost - 50K, Time - 20W

• 場景1. 項目功能都是“Must Haves“，選擇A或者B？
• 場景2. 項目的ROI是300%，選擇A還是B？
• 場景3. 項目的Benefit of Cost Ratio是4.6，選擇A還是B？
• 場景4. 項目的Class of Service是Expedite，選擇A還是B？

你會發(fā)現(xiàn)，基于以上的示例決策過程中有兩個問題：

1. 難以做出選擇。比如場景1，都是Must Have則選誰都可以？到底是選總成本少的呢？還是選時間短的？場景2，投資回報率高，那是不是應(yīng)該選B？因為B的成本低，可以通過低成本獲得高回報，但問題在于沒有考慮時間成本，也就是機會成本。其本質(zhì)在于，沒有考慮緊迫性以及價值隨著時間的變化帶來的成本。
2. 有些模式太過于靠直覺。比如MoSCoW法則，在討論過程中很容易跟HiPPO結(jié)合到一起，無論之前的分析考慮了多少因素，最終很有可能落到公司內(nèi)部位高權(quán)重的人拍板，靠直覺和經(jīng)驗做了決定。

四、延遲成本（Cost of Delay）

延遲成本是如果一個產(chǎn)品（機會點、項目）因為延遲而給組織帶來的成本（金錢）。它是衡量的是推遲做一件事情的損失隨著時間的變化，從而可以衡量這件事情的緊迫性，它是一個可以量化的經(jīng)濟學(xué)概念。

圖1. CoD兼顧了價值和緊迫性的度量（圖片來自于網(wǎng)絡(luò)）

例1：一個項目在時間點X發(fā)布，或者推遲到時間點Y發(fā)布，因為這個推遲的時間段而帶來的利益損失就是延遲成本。最終的表示方式會基于一定的時間單位，比如月，周，天。比如CoD是$1000/Day，其中金錢描述價值損失，時間單位用于描述緊迫性。
例2：一個相對具體的例子（如下圖2，圖3所示），模擬的是一個完整的產(chǎn)品生命周期中的成本與收益。

圖2展示的是一款產(chǎn)品的完整生命周期，紅色部分代表成本，綠色部分代表的是利潤。產(chǎn)品在Q2（Product to Luanch）結(jié)束上線，Q3結(jié)束開始帶來利潤，最終Cost是8M，Profit是35M。
圖3展示的是如果因為種種原因不得不延遲一個季度發(fā)布。成本是一樣的，只不多一個月來分攤，但是因為上線晚，導(dǎo)致銷售量受到而影響（錯失了銷售機會），最終Cost是8M，Profit是24M，所以CoD是35-24=11M。當(dāng)然這個11M可以分攤計算到某個時間單位上，比如季度、月或者天。

值得一提的是，CoD被“The Principles of Product Development Flow: Second Generation Lean Product”一書作者Donald Reinertsen認為它是產(chǎn)品決策的金鑰匙，如下所述：

Cost of Delay is a metric you must know to make decisions based on economic loss or gain.

五、延遲成本（Cost of Delay）與EDGE

EDGE（ThoughtWorks提出的“聚焦價值的投資組合管理”）里面提到了基于三條水平線的機會點管理方式，基于價值度量來做業(yè)務(wù)決策。在業(yè)務(wù)專題優(yōu)先級排定的時，通過延遲成本這樣一個可以量化的經(jīng)濟模型來幫助提升業(yè)務(wù)決策的效率，最終讓產(chǎn)品的交付聚焦在高價值機會點上，從而盡量避免以上兩種場景中的問題。或者換一個角度說，在聚焦價值的精益交付模式下，我們需要一個有效的業(yè)務(wù)決策模型，讓決策參與者能夠快速依據(jù)這個模型達成一致，快速試錯、及時反饋、不斷學(xué)習(xí)并調(diào)整方向，從而在這樣一個充滿不確定性的環(huán)境中保證產(chǎn)品能夠成功，CoD分析是值得嘗試的方式。

圖4. EDGE里面第3步，使用CoD來決定專題優(yōu)先級

量化延遲成本其價值在于：

1. 一個可以量化的經(jīng)濟學(xué)模型，本身是中立的，容易被多方接受
2. 聚焦到具體的經(jīng)濟損失或者收益上，考慮的是價值和緊迫性兩個維度
3. 用數(shù)據(jù)決策，而不是依靠直覺決策
4. 特別是對于傳統(tǒng)企業(yè)中的決策人員，他們對于一個具有經(jīng)濟意義的5. 數(shù)字更加敏感，更容易達成一致
5. 基于數(shù)學(xué)的計算，便于及時更新，可視化

后續(xù)話題

1. 如何估算一個項目的延遲成本
2. 延遲成本如何在決策中起作用
3. 產(chǎn)品研發(fā)過程中需要考慮的相關(guān)其他經(jīng)濟因素有哪些

參考文章：

1. Ten Tenets of Fast Projects - Tenet #5: Sharpen your prioritization:
2. Cost of Delay
3. An introduction to cost of delay
4. Lean Leadership Training: The True Cost of Delay