距離那個神聖的上線死線，只剩下最後三週，你正意氣風發地向老闆和各部門主管，展示你們團隊辛苦了一個月的開發成果：系統穩定，介面精美，一切都按照計畫進行，會議室裡所有人都面帶微笑，頻頻點頭，讚許這次專案進行得非常順利。

就在你準備宣布散會，去享受一杯應得的咖啡時，老闆突然開口了：「嗯，做得很好。對了，我剛剛想到一個小東西，應該很簡單，你們順便加一下。」

「你看，」他指著螢幕上的報表頁面，「現在這個報表只能在線上看很不方便。能不能在旁邊加一個按鈕，按下去就可以『一鍵匯出成 PPT』？這樣我以後開會就方便多了。」

他轉頭看向你，臉上帶著「我這個點子是不是很棒快誇我」的期待表情，此時業務主管立刻附和：「對啊！這個好！這樣我們給客戶看報告也方便！」

你看著他們興奮的臉，再看看行事曆上那個只剩下三週的倒數計時，一邊是老闆滿滿的期待，一邊是已經緊繃到極限的開發時程，你感覺自己就像被架在火上的烤肉，可能只差撒個胡椒粉就可以上桌了。

症狀診斷

遇到這種狀況請小心！你遇到的病症是「範圍無性增生症」！！

在繼續往下看之前，先釐清一下今天這個病症與 病症01：「欸，我有一個很棒的點子，一定很賺」 的差異：

• 病症01 發生在專案「前」
  像是一場「相親」，你要評估這個對象（點子）值不值得交往，這樣的狀況下，你的核心任務是「可行性評估」。
• 病症15 則發生在專案「中」
  像是一場「婚禮」，你們已經交換了戒指、講好了蜜月地點（承諾了範疇），現在卻有人想臨時增加大聘小聘，面對這樣的狀況，你主要的核心任務就會是「變更管理」的應對。

病根在於我們的利害關係人們（尤其是老闆或客戶）往往不了解一個看似簡單的功能背後，其實隱藏著多麽巨大的開發成本與連鎖效應。他們提出的每一個「順便加一下」，根本都像一個癌細胞，雖然微小，但如果不加以控制，它就會無性增生、快速擴散，最終吞噬掉你健康的專案時程與預算。

每當收到增生的需求，幾乎很難在不增加任何資源的情況下，把它們全部塞進原本已經滿載的貨船裡，如果硬塞的話，最終將會導致沉船。

我們應該要知道，每艘貨船的載重是有限的，任何一件新的貨物想要上船，都必須經過嚴格的「影響力評估」，並且，必須有另一件等重的貨物被移下船，以維持平衡。

你的工作可不是讓船載好載滿甚至超載，而是讓提出要求的人，親自決定，這次要丟掉哪一件行李（ 或是就直接把他丟掉 ）。

處方籤

這份處方，是你在面對任何「順便加一下」的突襲時，就可以拿出來使用！

第一劑：肯定與同理心

這是最關鍵的第一步，絕對不要在第一時間就說不行！來個熟悉的標準開場白：

「老闆，這真是個很棒的想法！我完全理解，如果能一鍵匯出成 PPT，您未來在準備會議時會省下非常多時間。這絕對是一個非常有價值的需求。」

• 潛台詞： 我懂你，我跟你站在同一陣線，我不是你的敵人。

第二劑：拖延戰術，進入後續影響評分析環節

爭取時間回去跟技術團隊討論，不要在當下給予任何承諾。

「為了讓我們能精準地完成這個功能，我想在會議後，花半天的時間，和技術團隊快速評估一下，這個『一鍵匯出 PPT』的功能，需要投入多少開發時間？以及，它是否會影響到我們原訂下週要完成的『A功能』和『B功能』的時程？我會在明天早上，帶著一份清晰的評估報告來跟您同步。」

第三劑：準備套餐

在跟技術團隊進行討論評估的時候，建議你至少可以從以下三種核心面向來全面分析、深入討論，並進行詳盡的影響力評估：

• 如果以犧牲時程的方式執行：這個新增功能會延後整體專案上線日期多久？是否會影響到其他已排定的里程碑？團隊成員的工作分配需要如何調整？後續連鎖反應會波及到哪些項目？
• 如果以犧牲範疇的方式處理：在原定交付時間內，我們可以捨棄或延後哪些原本規劃的功能？這些被犧牲的功能對整體產品體驗影響程度如何？使用者是否會因此受到顯著影響？未來補回這些功能需要額外投入多少資源？
• 如果以犧牲成本的方式解決：需要增加多少額外預算才能在不影響時程和範疇的情況下完成？是否需要臨時增聘人力或外包？這些額外資源的引入會不會帶來其他的管理成本或風險？整體專案的投資報酬率是否仍然合理？

在完成上述三方面的全面評估並整理後，你就可以準備好充分的資訊去打 Boss！

第四劑：讓他選！讓他選！讓他選！

你不要替老闆做決定，你需要提供選項讓他做決定，讓他感受到等價交換！

記住，你的目標不是拒絕需求，而是讓決策者能夠基於完整資訊，做出最適合專案整體利益的選擇。

「老闆，經過評估，這個『匯出 PPT』的功能，大約需要額外 5 天的開發時間。目前我們距離上線只剩下三週，如果要做這個功能，我們有以下三個方案可以選擇：」

A套餐： 我們維持原有的功能不變，不過評估預計需要將上線時程延後一週。
B套餐： 我們維持原訂時程上線，但需要將原計畫中的『後台數據篩選功能』，延後到下個版本再做，把人力優先安排做匯出 PPT 的功能。
C套餐： 如果時程和功能都不能犧牲，我們可能需要申請一筆緊急預算，找外部的合作夥伴來支援這個功能的開發。

「您覺得，哪個方案對我們目前的戰略最有利？」

臨床實戰

好，讓我們回到開頭那個讓你胃痛的場景。

當老闆提出「一鍵匯出 PPT」的需求時，你該如何應用你的處方籤？

1. 啟動「肯定與同理心」模式
   • 你會微笑著說：「老闆，這真是個很棒的想法！我完全理解，如果能一鍵匯出成 PPT，您未來在準備會議時會省下非常多時間。這絕對是一個非常有價值的需求。」
2. 申請「影響力分析」評估
   • 接著說：「為了讓我們能精準地完成這個功能，我想在會議後，花半天的時間，和技術團隊快速評估一下，這個功能需要投入多少開發時間？以及，它是否會影響到我們原訂的上線時程？我會在明天早上，帶著一份清晰的評估報告來跟您同步。」
3. 第二天早上，你帶著選項赴約：
   • 「老闆，經過評估，這個『匯出 PPT』的功能，大約需要額外 5 天的開發時間。目前我們距離上線只剩下三週，如果要做這個功能，我們有以下三個方案可以選擇…」
   • 你將 A、B、C 三個套餐清晰地呈現在他面前。

基本上老闆看著你提供的「選擇題」，通常大部分會意識到，他以為的「小小的要求」背後，需要付出哪些真實的「代價」。他可能會選擇其中一個方案，也可能在思考後，說：「嗯…既然這樣，那這個功能我們先不做了，還是以上線為優先。」

無論他選擇哪一個，你都成功了！

B 計畫：當老闆說「我不管，我全都要」時

老闆已經是大人了，怎麼可能跟小孩一樣做選擇呢？你說是吧！（苦笑）

所以假如在你拿出了相關取捨的選項給老闆，老闆就眉頭一皺，說出那句經典的名言：「小孩子才做選擇，我全都要！時程不能延、功能不能少，這個新功能也必須做！」的時候，我會建議你可以採取以下措施：

第一步：接受指令，並「鎖定」範疇

「好的，老闆，收到您的指示。為了確保團隊能全力衝刺，我會立刻將這份『最終版』的需求清單鎖定，並告知所有相關人員，在這三週的衝刺期間，我們將不再接受任何新的變更，以確保能達成您『全都要』的目標。」

• 潛台詞： 我接受了你的無理要求，但我也利用你的權威，為自己建立了一道「防火牆」，防止後續更多的「順便加一下」。

第二步：成為團隊的「心理防護罩」

在發出任何公開信件之前，務必先找你的團隊開一個小會。這一步絕對不能省！
在會議中，你可以這樣說：

「各位，我知道剛剛的結論很扯，這不是你們的問題，責任在我。現在，我們的目標就是在這個不合理的框架下，盡力做到最好。我會去處理所有的外部壓力，但我們需要一起評估，為了達成這個目標，我們必須犧牲什麼？是測試時間？還是程式碼品質？讓我們一起把『代價』寫下來。」

• 潛台詞： 你承認了現實的荒謬，將壓力自己扛下，並邀請團隊成為你制定「風險宣告」的盟友，而不是被你單方面出賣。

第三步：公開進行「風險宣告」

• 你該做： 根據和團隊的共識，立刻發出一封會議記錄郵件給所有與會者，主旨清晰，內容客觀。

• 郵件內容：

  「根據會議結論，我們將在維持原訂時程與範疇的前提下，新增『匯出 PPT』功能。為了達成這個目標，團隊將需要 [多少時間，例如：連續兩週的週末加班] 來趕工。

  同時，經過團隊的共同評估，為了在極度壓縮的時程下完成任務，我們必須做出取捨。因此，我們將會縮減原訂 50% 的整合測試時間。當然無可避免的產品上線初期的 Bug 風險會顯著提高。

  但團隊一定會盡全力達成目標，並已準備好應對上線後的緊急狀況。」

• 潛台詞： 我沒有抱怨，我只是在陳述一個客觀的「事實」與「後果」。我讓所有人都清楚地知道，這個決策的「代價」是什麼。如果未來產品出包，沒有人可以假裝不知情。

特別門診：當你還是成了代罪羔羊時

正常來說 B 計畫已經可以幫你增加很多防禦值，但是，我們必須面對最殘酷的現實：有時候，就算你做了所有對的事情，當專案真的出包時，老闆還是會把鍋甩到你頭上。

他可能會說：「我當初就只是提個想法而已，你是專業的 PM，這點小事你不是應該搞得定嗎？」

此刻，正是考驗你最終極專業素養的時刻，當你遇到這樣的狀況，建議服用以下幾帖藥：

1. 第一帖藥：絕對不要公開爭辯
   • 在會議上和老闆爭論誰對誰錯，這時候要做的，就是保持風度，承擔責任。
   • 不管如何，我會建議你可以這樣說： 「老闆，您說的對，這次的問題，最終的責任在我。我會立刻帶領團隊，處理善後。」
2. 第二帖藥：專注於「解決問題」，而非「追究責任」
   • 此刻，你唯一的目標，就是帶領團隊撲滅火災。展現你在壓力下的解決問題能力，遠比證明自己當初是對的，來得更重要。
3. 第三帖藥：在「事後」，用「證據」進行一次平靜的複盤
   • 當風波平息後，你可以找一個適當的時機，拿著你當初發出的那封「風險宣告」郵件，和老闆進行一次一對一的複盤。
   • 你可以這樣說： 「老闆，關於上次的事件，我想和您一起回顧一下，看看未來我們如何能避免同樣的狀況。根據我們當初的評估，確實有預見到測試時間不足的風險。未來在遇到類似的狀況時，您覺得我們該如何調整決策流程，才能更有效地平衡時程與風險？」
4. 最終帖：更新你的「公司去留」評估報告
   • 這帖藥，是開給你自己的。這次的事件，是你評估這間公司是否值得你長期投入的最好試金石。如果你的老闆，在看過所有證據後，依然習慣性地甩鍋，那麼，我想你心裡就該有數了。

最後的醫囑

所以，下次當你聽到那句「這個很簡單，順便加一下」時，請先別急著答應或拒絕。

一個沒有被評估過的需求，就像一個沒有標價的商品，你永遠不知道自己是否付得起。

你的工作不是當一個有求必應的許願池，也不是一個只會說不的討厭鬼，而應該是一個談判專家。你需要清晰地呈現每一個選項的代價（時間、人力、機會成本），來引導你的利害關係人做出最符合專案整體利益的明智決策。

當聽到過去總是
只佔便宜沒有同等回報的同事又說出
「欸你順手/順便/順路 幫我 做一下/加一下/看一下 吧！」
我的心裡 OS：