◆ 專案為什麼一延再延，其實你心裡都知道
很多專案的故事都是這樣開始的。
一開始大家抓了一個「看起來合理」的工期：
「這個版本一個月，應該可以。」
過沒幾天，老闆補一句：
「這裡再加一個小功能，應該不會很花時間吧？」
客戶再補一句：
「我們之前提過那個欄位也一起做進來好了。」
行銷想起來：
「既然這次要改頁面，那順便把這個漏斗也串一下好嗎？」
你心裡其實有一點緊張，
但嘴巴還是很誠實地說出那句最習慣的：
「好，我先幫你們記起來。」
一個月變成兩個月，
兩個月變成三個月。
等到有人開始問：
「為什麼做不完？」
你才終於說出口：
「因為需求一直變更，所以時程一直往後…」
但如果把時間拉回去看，
專案真正失控的時間點，
往往就是那一個個被你輕描淡寫說「好啦」的當下。
◆ 課本裡有變更流程，真實世界只有「順便一下」
在專案管理的教科書裡，
需求變更看起來很有秩序：
提出變更 → 評估影響 → 調整範疇、時程、成本 → 雙方同意後執行。
實務上比較像這樣：
一個 Line 訊息：
「這個客戶很在意，幫忙加一下。」
一個走廊上的對話：
「這很小啦，順便一起做。」
一封會後信件：
「剛剛有幾點補充，我整理在這裡。」
沒有人真的停下來問：
這一刀加下去，要多幾人天？
需不需要改架構？
會不會影響已經排好的排程？
表面上你還在「管時程」，
實際上範疇早就默默膨脹，
最後只剩一句：
「我們先安排看看。」
◆ 不敢砍，是因為你心裡沒有「版本邏輯」
很多 PM 不敢拒絕功能，
不是因為不知道該說什麼，
而是心裡只有一個模糊的「這版要上線」。
當腦中只有一個版本，
所有東西都只能塞在同一坨裡。
每一個新需求聽起來都很重要：
這個對轉換有幫助、
那個對留存有幫助、
那個是重要客戶提的、
這個是老闆點名要的。
於是你只剩下兩種選擇：
要嘛全部答應，
要嘛把自己逼到崩潰。
如果你開始習慣這樣想：
這個是 MVP 非做不可
這個可以放到 1.1 再上
這個等數據有證據再排進 2.0
你就多了一句很實際的話可以說：
「不是不做，而是先幫它排到下一個版本。」
版本不是甘特圖上的標籤，
版本是你幫產品、幫團隊、也幫自己
設下的一條「活得下去」的分界線。
◆ 功能不是願望清單，是一場有代價的交換
要學會「砍功能」，
第一件事不是逢來就說不，
而是把「代價」說清楚。
不是回：
「這個不行。」
而是改成：
「這個可以做，但會有三個影響，我們一起選：
1. 工期從一個月變成一個半月；
2. 工期不動，就要拿掉原本排好的 X、Y；
3. 我們先做縮水版，只做最核心那一段。」你把選項攤在桌上，
讓大家看到的是一個具體的交換：
每一個『多加一下』，
背後都是時間、風險、品質的重新排列。
當你只是說「好，我們試試看」，
在別人眼裡，你就是一個
永遠塞得下更多東西的黑洞。
當你開始習慣說：
「可以，但會有這幾個影響，你要選哪一個？」
對方也會開始意識到，
每一個願望，都要付出代價。
◆ 生功能很容易，難的是砍掉功能
說實話，多數 PM 都很會「生功能」。
你可以做完一輪訪談，
整理出滿滿的需求：
這個也要、那個也重要、
這個對用戶有幫助、
那個是競品有我們沒有。
做著做著，
產品就長成了一個什麼都有、
但沒有哪一塊特別好用的大怪獸。
真正困難的是另外一種能力：
看著一個需求，平心靜氣地說：
「這個我們先不做。」
「這個可以改成內部流程處理。」
「這個等數據證明有效再排進來。」砍功能，不是砍掉對方的期待，
而是幫對方一起想清楚：
在現在這個時間點，
我們最需要被驗證的是什麼？
最怕失敗的是哪一塊？
有限的資源，要先押在哪一邊？你不只是幫產品「長東西」的人，
你也是幫產品「減肥」的人。
◆ 控制需求，不是硬碰硬，而是一起守住專案
很多人一聽到「控制需求」，
腦中浮現的畫面是吵架：
「不行，再加就會爆。」
「再改就來不及。」但現實裡，多數狀況不用吵，
需要的是一個能把全局攤開來看的人。
你拿著目前的時程、資源、版本規劃，
很坦白地跟老闆、客戶、團隊一起看：
「如果現在要加這個，我們有幾種選擇：
– 時間往後退兩週；
– 拿掉原本的 B 功能；
– 這版只做雛形，下版再完整。」控制需求，不是你一個人的責任，
而是你帶著大家一起對選擇負責。
當範疇被這樣反覆「講清楚、說明白」，
需求就不再是悄悄長胖，
而是一步一步被有意識地安排。
◆ 生得出來，也砍得下去，才是成熟的 PM
嗨，我是廣三。
在軟體開發打滾二十年，
經歷過大大小小數不清的專案。
回頭看，
那些最後能「準時、完整、還活得下去」的產品，
有一個共同特徵：
不是功能最多，
而是每一個留在那一版的功能，
都經過了「要不要現在做」的篩選。
生功能，是 PM 最基本的功課。
你要懂需求、懂系統、懂團隊的極限。
但真正拉開差距的，
往往是另一個比較少被講出來的能力：
在關鍵時刻，
你敢不敢幫產品做減法，
幫專案守住邊界，
幫團隊留下可以喘息的空間。
很多人以為 PM 的價值，
是在一張又一張的需求清單、
一頁又一頁的 Wireframe 裡。
但走久了你會發現：
真正決定專案生死的，
常常是那幾個你選擇「這版先不做」的瞬間。
當你既有能力把功能生出來，
也願意在必要時親手砍掉一些功能，
砍功能，不是砍掉對方的期待，
而是幫對方一起想清楚，
有限的資源(時間和預算)，要先放在哪一邊？
產品就像是一個皮箱，空間是有限的。
硬塞太多衣服進去，最後結果不是裝得多，
而是拉鍊會爆開，連最原本的那幾件都帶不走。
你就再也不只是專案的執行者，
而是這個產品真正的「生與死」決策者。
而這份勇氣，
會讓你在一次又一次的版本迭代裡，
慢慢養出一個：
跑得動、跑得久，
而且大家願意繼續投入的產品。
若你在PM這條路上感到迷茫，
或想更清楚了解自己的能力與定位，
歡迎試試這份《PM產品／專案雙軌分析報告》。
它不為了定義你，而是幫助你更看清自己。
歡迎關注：
官網：https://unityprosper.com/
部落格：https://hero-mi.com/
FB：https://www.facebook.com/DigiPRDCoachHeroMi
LINE OA：@hero-mi
《歡迎加我LINE，一起破局未來》
留言