用決策樹看懂趕工、調整範圍與談延期的代價
學生時期，考試快到了，讀書進度卻還差一大截。這時候，腦子裡很容易冒出一個念頭：今晚先熬夜，把後面幾個章節補完再說。
聽起來很積極。可是等到真的熬夜補進度，才會發現自己只是把頁數看完，內容並沒有真正吸收。
後面幾章看得很快，卻沒有真的讀懂。
公式背了，題目一換就不會用。
隔天精神很差，原本會的題目也開始出錯。
最後才發現，自己表面上是在追進度，實際上可能把新的風險也一起帶進來。
專案也是一樣。當專案快到期限，進度卻還落後，會議室裡最常出現的反應通常很直接：加人、加班、先趕出來、先交再說。
這些反應都很真實，因為專案到了尾端，大家最在意的就是怎麼把事情往前推。真正要小心的是，很多專案在壓力最大的時候，只看到「快一點」，卻沒有看見「快一點之後會發生什麼」。
這時候，與其急著催大家再快一點，不如先把幾條路畫出來，看清楚每個選擇後面會接著什麼結果。這就是決策樹適合登場的時候。
它可以幫我們把幾條可能的路攤開來看：加人之後會怎樣？調整範圍之後會怎樣？主動談延期之後，又會面對什麼結果？
專案快到期時，真正要釐清的，不只是要不要追進度，而是追進度之後，我們可能會承擔哪些後果。
別急著問要不要加人，先問現在真正卡在哪裡
很多專案一落後，第一個被提出來的方案就是加人。
因為加人看起來最像解法。
人不夠，就想補人；時間不夠，就想加班；進度不夠，就想多塞資源。這些反應很自然，很多專案現場也確實都是這樣開始救火。
可是專案管理裡有一個提醒很重要：進度落後的成因不同，補人未必能補到真正的缺口。
如果工作本身可以被切分，加人可能有效。
例如資料整理、測試驗證、文件補齊、現場支援，這些工作只要分工清楚，增加人力通常能帶來幫助。
可是如果卡住的是關鍵技術判斷、客戶需求反覆變動、設計尚未確認、決策權責不清，加人很可能只會讓問題變得更複雜。
就像廚房裡只剩一道菜還沒炒好。
如果缺的是洗菜、切菜、備料，多幾個人可能會快一點。
但如果真正卡住的是主廚還沒決定要做哪一道菜，這時候再多三個人在旁邊等，也不會讓菜更快上桌。
回到專案現場，進度落後的原因通常不只一種。
有時候，是真的人手不夠，事情切得開，也有人能接手，這時候加人可能有效。但更多時候，專案卡住的地方不在人數，而在前面沒有說清楚。例如客戶需求還在變、設計還沒確認、主管遲遲沒有拍板，或是前面趕太快，品質沒守住，後面一直補洞、一直返工。
如果沒有先分清楚，所謂的加人，很可能只是一個看起來很努力，卻沒有真正碰到問題核心的動作。
決策樹的價值，是把選擇後面的結果攤開來
決策樹很適合放在結果不確定的時候使用。專案快到期，正好就是這樣的情境。
表面上，大家都在討論怎麼救進度。可是每一個做法後面，其實都接著一串可能的結果。
加人之後，進度也許真的追回來了，也可能讓核心成員花更多時間說明、分派與檢查。趕工看起來可以把交付日往前拉，但品質如果沒有守住，後面很可能變成修補、客訴與返工。主動談延期，可能換到比較穩的完成時間，也可能讓客戶重新懷疑團隊的掌握度。至於調整範圍，如果溝通得好，可以先守住核心成果；如果說不清楚，客戶可能會覺得原本答應的內容被打折了。
這也是為什麼，專案尾端的討論常常很難收斂。
有人擔心現在不補人，期限一定守不住。
有人看過太多後期加人的混亂，知道人一多，溝通成本也會跟著上來。
也有人主張先交出去再修，至少先守住原本承諾的交付時間。
另一邊，負責品質或客戶關係的人，可能會提醒大家：如果交出去的東西不能用，後面要補的洞會更大。
每一種看法，其實都來自不同角色對專案風險的觀察。
真正的問題是，如果缺少一個共同的分析架構，大家很容易只是在表達自己的擔心，卻很難一起判斷哪一條路比較可行。
決策樹的作用，就是把這些不同立場，整理成可以討論的結構。
它會幫我們把一個決策分成三個層次來看：
| 決策層次 | 要回答的問題 | 以專案快到期為例 |
| 第一層：有哪些選擇 | 現在可以走哪幾條路？ | 加人追進度、調整範圍、主動談延期、維持原計畫 |
| 第二層：可能出現什麼結果 | 每個選擇後面，可能發生什麼事？ | 加人可能追回，也可能讓溝通更亂；調整範圍可能被接受，也可能需要再協商 |
| 第三層：要承擔哪些代價 | 如果結果發生，會帶來什麼影響？ | 成本增加、品質下降、客戶信任受損、團隊疲乏、後續返工 |
這樣一來，團隊討論的焦點就會從：
「我覺得應該加人。」
慢慢轉成：
「如果加人，有多大機會真的追回進度？如果追回不了，我們會多付出哪些成本？」
討論一旦走到這裡，就不再只是各自表達壓力。
大家開始用同一張圖，看見同一組選擇，也看見每個選擇後面可能帶來的結果。
這就是決策樹在專案管理中的價值。
專案快到期時，至少要展開四條路
假設一個專案距離交期只剩五天，但團隊重新盤點後發現，手上的工作量至少還需要八天才做得完。
換句話說，現在大約落後了三天。
這種時候，現場最需要小心的是，大家一急，就只剩下「加人、加班、趕快做完」這一條路。但如果只盯著眼前進度，後面可能會冒出更多新的問題。
比較穩的做法，是先把眼前幾條可能的路攤開來看。
常見的方案，大致可以整理成下面四種：
| 方案 | 做法 | 表面好處 | 潛在代價 |
| 加人力追進度 | 增加人手、加班趕工 | 看起來最積極，短期內可能拉高產出 | 溝通成本上升、品質下降、返工增加 |
| 調整範圍 | 先交付核心項目，非必要項目延後 | 先守住主要成果，降低全面失控風險 | 需要客戶接受分階段交付 |
| 主動談延期 | 重新協商交期 | 品質較穩，團隊有較完整的完成空間 | 可能影響客戶信任，甚至產生罰則 |
| 維持原計畫 | 不改變做法，繼續趕 | 短期內不用重新協調，表面上最省事 | 最後可能交期、品質與團隊狀態一起失守 |
這四條路各有適用條件，關鍵在於判斷哪一條最符合當下的專案狀況。
真正要怎麼選，還是要回到專案此刻最需要守住的是什麼。
如果合約罰則很重，準時交付可能就是第一優先。
如果品質一旦出錯，後面會造成很大的損失，那麼硬趕反而危險。
如果客戶最在意的是核心功能能不能先到位，那麼分階段交付，未必比完整但延遲差。
如果團隊已經連續高壓運作，繼續加班雖然看起來撐得住，卻可能連帶壓縮下一個專案的準備與執行空間。
這也是決策樹值得拿出來用的原因。
因為它可以幫我們把每一條路後面可能接續的結果攤開來看。不是只看哪個方法最積極，而是看哪一種代價，現在的專案比較承受得起。
用決策樹把四個方案攤開來看
如果把剛剛那四條路往下展開，決策樹可以先簡化成下面這樣：
這張圖一畫出來，團隊看事情的角度通常就會開始改變。
原本大家討論的，常常只有一句話：
要不要加人？
但把四個方案都攤開之後，問題會變得更完整。
例如，大家會開始問：
加人之後，真的能追回多少進度？
如果人變多了，溝通和品質會不會反而更不穩？
如果先交核心項目，客戶能不能接受？
主動談延期，和硬撐到最後才失守，兩者的代價哪一個比較大？
如果什麼都不調整，最壞的情況會走到哪裡？
這時候，團隊討論的重點就不再只是「做哪個動作」，而是開始看見「每個動作後面會帶來什麼結果」。
這正是決策樹最有價值的地方。它不是替團隊做決定，而是幫團隊把原本混在一起的焦慮、直覺和立場，整理成可以比較、可以判斷、也可以對話的結構。
加人力之前，先判斷三件事
專案快到期時，加人確實可能帶來幫助，尤其在工作可以切分、標準清楚、有人能快速接手的情況下。只是在決定補人之前，專案經理要先看清楚：現在缺的是人手，還是缺少判斷、流程或品質控管？
我通常會建議專案經理先看三件事：工作能不能切分、人能不能快速上手、品質風險能不能控制。
| 判斷項目 | 要問的問題 | 適合加人的情況 | 不適合直接加人的情況 |
| 工作能不能切分 | 剩下的工作可以平行處理嗎？ | 測試、資料整理、文件校對、現場支援 | 架構設計、關鍵技術修正、客戶需求確認 |
| 新人能不能快速上手 | 新加入的人是否能馬上產出？ | 工作規則清楚、交付標準明確、有人可快速交接 | 需要大量背景說明，核心成員還要花時間帶人 |
| 品質風險能不能控制 | 趕工之後，錯誤是否還補得回來？ | 錯誤容易檢查、修正成本可控 | 客戶資料、系統安全、法規文件、重要規格判斷 |
如果剩下的工作可以被切成幾段，責任也能分清楚，加人就有機會發揮效果。像是測試驗證、資料整理、文件補齊、現場支援，這些工作只要標準清楚，增加人力通常能幫上忙。
但如果卡住的是少數人的判斷，情況就不同了。
例如架構設計還沒有定案、關鍵技術問題還沒解開、客戶需求還在確認，這時候多找幾個人進來，未必能讓速度變快。原本的核心成員可能還要花更多時間說明背景、分派任務、檢查結果，最後看起來人變多了，真正能往前推的時間反而被壓縮。
品質風險也要一起看。
有些工作慢一點、趕一點，後面還有機會修正；但有些工作一旦出錯，後面付出的成本會很高。像是客戶資料錯誤、系統安全漏洞、法規文件疏漏、重要規格判斷錯誤，這些都不適合用「先趕再說」處理。
所以，加人之前要先確認一件事：
這個專案現在缺的，真的是人手，還是缺少清楚的判斷、穩定的流程，或已經失控的品質？
這個問題問清楚，加人力才比較不會變成另一種形式的忙亂。
決策樹也要看團隊承受能力
很多人在使用決策樹時，會想把每個方案都算出期望值。
例如加人追進度，可以先假設幾種可能結果：
| 方案 | 可能結果 | 機率 | 成本 |
| 加人追進度 | 成功追回 | 60% | 15萬 |
| 加人追進度 | 品質下降需返工 | 25% | 30萬 |
| 加人追進度 | 仍然延期 | 15% | 50萬 |
這樣做有幫助，因為它能讓團隊看見一個大概的期望成本。
可是專案決策不能只停在數字。有些代價，很難完整放進表格裡。例如，客戶開始懷疑團隊的掌握度；成員連續加班後，士氣和專注力都下降；關鍵人才被過度消耗，下一個專案一開始就沒有餘裕；系統雖然交出去，後續維護卻變得更重。這些影響不一定會立刻出現在成本表上，但它們會慢慢回到專案現場。
所以，使用決策樹時，除了問「哪一個方案成本比較低」，還要多問幾個問題：
| 要追問的問題 | 背後要判斷的事 |
| 這個代價，我們承受得起嗎？ | 團隊、客戶與公司是否有能力吸收後果 |
| 這個風險如果發生，誰要處理？ | 責任與補救資源是否清楚 |
| 這個選擇會不會把問題推到下一階段？ | 是否只是把眼前壓力延後 |
| 這次趕過去了，下一個專案會不會被影響？ | 是否消耗了後續戰力 |
專案管理裡，很多決策真正麻煩的地方，是當下看起來有動作，問題卻只是被往後推。
進度暫時往前了，壓力暫時降下來了，但沒有被處理好的風險，常常會在下一個階段，用更高的成本回到現場。
這就是決策樹值得使用的地方。
它提醒團隊：做選擇時，不只看眼前能不能趕上，也要看這個選擇後面，還會牽動哪些人、哪些成本、哪些風險，以及哪些未來要補的洞。
成熟的專案判斷，是把「趕」拆成不同做法
專案快到期時，很多人會說：「那我們趕一下。」
這句話聽起來很合理，但「趕」其實不是單一動作。
專案經理可以先把關鍵路徑上的工作拉出來，集中資源處理；也可以把非必要項目延後，先守住主要交付成果。
如果品質風險太高，與其一路硬撐到最後，也可以提早和客戶協商，爭取比較穩定的完成時間。
最需要小心的是，團隊沒有先分清輕重，只是一起加班，把所有事情都往前推。這種趕法看起來很投入，卻容易把人力、品質和溝通一起推到更緊繃的位置。
前面幾種趕，背後都有判斷。
最後一種趕，通常只是壓力下的直覺反應。
所以當團隊說「我們要趕進度」時，專案經理可以多問一句：
我們現在要趕的是全部，還是最重要的那一段？
這句話很關鍵。很多專案後來出問題，團隊真的很努力，只是力氣分散在太多地方，沒有人先把真正該守住的方向整理出來。
現場的人都很忙，訊息一直進來，任務一直被插單，大家一邊補資料、一邊回客戶、一邊修前面留下來的問題。看起來每個人都在往前衝，可是專案真正需要守住的那件事，反而沒有人停下來重新確認。
這時候，決策樹可以幫團隊把局面看清楚。
它會提醒大家：現在眼前不只一條路。加人是一條路，調整範圍是一條路，主動談延期也是一條路，維持原計畫繼續趕也是一條路。
差別在於，每一條路後面接著的結果不同，會付出的代價也不同。
壓力越大，越需要讓討論回到結構
很多人以為，工具是平常時間比較充裕時才拿來用的。
但在專案管理裡，壓力越大的時候，越需要一個清楚的工具幫團隊穩住判斷。
因為壓力會讓人急著下結論，讓人只盯著眼前缺口，也會讓團隊習慣用過去最熟悉的方法處理問題。
可是專案尾端的每一個決定，都可能牽動後面的交付品質、客戶關係與團隊狀態。
這時候，決策樹可以讓團隊先慢下一拍，把幾個重要問題講清楚：
| 步驟 | 團隊要做的事 | 要避免的狀況 |
| 先列方案 | 把可能的路列出來 | 只剩下加人、加班一種想法 |
| 再看結果 | 推演每個方案後面可能發生什麼 | 只看眼前進度，忽略後續風險 |
| 接著估代價 | 看成本、品質、客戶信任與團隊負荷 | 只算時間，不算返工與修補 |
| 最後做選擇 | 選出當下最能承受的做法 | 被壓力推著做決定 |
這樣做，是為了讓團隊在出手前先對準方向，避免後面變成一場忙亂的補救。
很多時候，團隊知道該往前走，只是心裡都卡著一層擔心：這樣做會不會出事？會不會讓後面付出更大的代價？
決策樹的好處，就是把這些說不清楚的擔心，整理成可以一起討論的風險。
可以這樣帶團隊討論
下次專案快到期時，專案經理可以開一場短會，不需要把會議開得很長，只要先把幾個關鍵問題問清楚。
| 問題 | 目的 |
| 目前真正落後的是哪一段？ | 避免整個專案都被說成有問題 |
| 這一段是否在關鍵路徑上？ | 判斷它是否真的影響交付 |
| 現在有哪些可行方案？ | 讓團隊看見加人、調整範圍、談延期以外的可能 |
| 每個方案最可能發生什麼結果？ | 先看後果，再決定動作 |
| 哪一個方案的代價最可承受？ | 做出比較穩的選擇 |
這幾個問題問完，團隊通常會從焦慮慢慢回到判斷。
大家會開始知道，現在不是整個專案都來不及，而是哪一段真的卡住；不是所有工作都要一起趕，而是哪一段會影響交付；也不是所有代價都一樣重，而是哪一種代價是現在的專案比較承受得起的。
這就是工具真正的價值。
它讓團隊在壓力中，還能保有共同語言。
把後果看清楚，決策才會穩
專案快到期時，最需要的是清楚的判斷。
加人、加班、調整範圍、談延期，這些都是方法。真正重要的是，團隊有沒有看見每一個方法後面會接著什麼結果。
決策樹不會直接替專案經理做決定。它的價值，是讓大家在壓力裡，還能把選擇看清楚，把風險說明白，把代價攤開來。
好的專案管理，不只是把事情趕完。更重要的是知道：什麼該先趕，什麼要守住，什麼需要提前談，什麼問題不能再往後推。
專案越接近期限，越不能只靠一句「大家再努力一下」。這句話可以鼓舞士氣，卻還需要搭配清楚的判斷，才有機會真正解決問題。
真正能帶團隊往前走的，是把混亂拆開，把選項攤開，把後果看懂。
當大家看懂後果，專案決策才會開始變得成熟。
