Being busy isn’t always the problem. Sometimes it’s the way we work.
工程師的經驗，為何總與專案現實脫節？
PM帶著一個緊急需求去找工程師，對方回你：「最近沒空。」或「目前排程很滿。」PM 可能會很焦慮(焦慮又擔心…欸人緣不夠好…多想的)。因為你看到的是客戶正在流失、市場窗口快關了，或業務已經承諾交付；工程師看到的，卻是手上還沒完成的技術債、既定版本、測試問題與主管排進來的工作。
於是雙方都覺得對方不理解現實… 單思維就會這樣….
但很多時候，問題不在工程師不關心市場，也不在 PM 不理解技術，而是公司沒有把「市場壓力」轉成明確、可執行的優先順序。
工程師說「沒空」，不一定是在拒絕需求。
有時候，他是真的不知道這件事的商業影響，而且有時候也不是他一人可決定的，答不答應或許還有其他人為因素。PM 需要說清楚：這是誰的需求、影響多少客戶、為什麼現在要做、不做會有什麼後果，以及這是一個短期救火需求，還是值得長期投資的產品能力。
但也有另一種情況：工程師不是不願意做，而是真的沒有容量。他的主管已經排了版本功能、平台維護、技術債、客戶問題、測試修正與其他專案。這時候，就算 PM 講清楚市場壓力，也不代表工程師可以憑空生出時間。
因為資源不足不是溝通問題，而是管理問題。
真正的問題應該回到研發主管與管理層?如果這個需求真的優先，那要延後…
- 哪一件事？
- 停掉哪一個功能？
- 接受哪一項技術風險？
- 還是增加人力？
- 延後誰負責?
PM 的工作不是要求工程師「以市場為重」，工程師的工作也不是替 PM 扛商業壓力，PM 要把需求的價值、時效與代價講清楚，還要讓團隊知道他負責；工程師要把技術成本、風險與可行時程講清楚；而研發主管，必須對團隊的容量與優先順序負責。
工程師不是 PM 的代工廠，PM 也不是工程師的發包者，但更重要的是，工程師也不是公司的最後決策者，也不是客人端或消費者全球代表。團隊內也同樣不是。
當需求衝突、資源不足時，不能靠一句「這很急」壓過技術現實，也不能靠一句「沒空」就讓商業問題消失。真正成熟的團隊，會把衝突攤開來：
- 如果要做 A，就要延後 B。
- 如果 B 不能延後，就必須降低 A 的範圍。
- 如果 A、B 都不能動，就需要管理層決定是否投入更多資源，或承擔其中一邊的損失。
這應該不是團隊內的對立，而是公司有沒有能力，把市場上的優先順序，真正落到團隊每天的工作裡。
摩擦點一：PM 只給「答案」，不給「問題情境」；沒有擔當的統籌，只會讓專案變得隨便
這是最浪費工程師精力的問題：PM 直接在規格書裡寫「請實作一個按鈕，按下去做 X 動作」。
工程師需要「情境（Context）」來判斷技術價值
當你只給工程師「答案」（例如：實作某個功能），他們就只能當一個執行者。他們會基於程式碼的複雜度來估算時程，而不是基於商業目標來判算技術投入的價值。
你應該提供「情境（Context）」而非「解決方案（Solution）」。因為當他們知道「Why」（例如：這個功能能幫公司多賺 100 萬），他們就有權利和動力去挑戰你提供的「What」，並提出更高效、更有成本效益的技術解。
實戰建議：在規格書開頭寫下「這個功能存在的商業目標是什麼？」和「希望解決使用者的什麼痛點？」。讓工程師從「執行者」升級為「共同解決問題的夥伴」。
摩擦點二：估算時程中的「理想主義陷阱」
當工程師說「這需要一週」時，通常是基於自己「最順利」的經驗。但現實的專案，總是被技術債、突發狀況和模糊的規格所拖累。
PM 的模糊，是工程師的規格地獄
PM 必須理解，工程師估算時程，裡面通常包含了測試、例外處理和潛在的重構。如果 PM 在驗收標準（Definition of Done, DOD）上模糊不清，工程師就會傾向於選擇「最快完成」的邏輯，而不是「最符合商業目標」的邏輯。
一個模糊的「完成」，會讓工程師在開發過程中不斷猜測，最終導致來回修改和時程超支。
實戰建議：估算時程要轉為「雙向討論」。PM 提出商業目標的輕重緩急，工程師提出三種方案（快、中、慢）的風險和代價，由 PM 和團隊共同決定要承擔哪種風險。這才是真正的專案管理。
摩擦點三：工程師說「沒空」 PM 卻無力反駁
PM 帶著業務的壓力，要求工程師在不理解技術複雜度的情況下「硬擠」時程。
PM 在「分配資源」上失職，導致工程師只能「自保」
當工程師說「沒空」時，他們是在對你進行「防禦性估算」，因為他們知道 PM 可能會隨意插單。這代表 PM 在資源管理和專案優次上失職。
PM 不該獨自分配資源，工程師也不該獨自承擔商業判斷
當工程師說「沒空」，很多時候不是防禦性估算,而是誠實描述現況:手上工作已經排滿,而他沒有許可權自行停止既有任務、延後版本,或放棄技術債處理。
這個問題的根源,常常不在工程師,而在於「誰有權決定優先順序」這件事被模糊掉了。
PM 能做的,是把取捨攤開,而不是自己做決定
PM 可以說明需求情境、客戶影響、交付期限,以及「不做」的代價。但真正能決定插入新需求、延後哪個項目、承擔什麼技術風險的人,通常是研發主管或管理層——因為只有他們同時握有團隊容量的全貌與優先順序的調度權。
所以比起對工程師說「這個需求下個月能帶來多少萬營收,你願意換掉技術債嗎」,更合理的做法,是把問題帶到真正該決策的人面前:
- 目前團隊正在處理 X 技術債與既定版本。
- 新需求 Y 可能影響客戶續約／下個月交付／特定商機。
- 若要納入 Y,預估會延後 X,或需要縮小 Y 的範圍。
- 請確認目前的優先順序,以及可承擔的風險
這不是 PM 把問題往上推卸責任,而是把真正的取捨攤開,交給有許可權的人做決定。
但這裡有個現實問題:研發主管真的會在意營收嗎?
不一定。很多研發主管的思維仍然是「研發為重」,對商業數字的敏感度有限——他們不一定看財報,「成本」對他們來說,往往只是幫忙比價、傳報價單的動作,而不是真正的商業判斷。願意認真權衡營收與技術債的,通常是少數想往上走、主動補商業知識的人。
這恰恰說明了一件事:期待「機會成本對話」能自然發生,是一種理想化的想像。它需要的不只是把資訊講清楚,更需要組織本身把「商業判斷」明確劃為某個角色的職責——不管是研發主管、技術總監,還是產品負責人——而不是假設它會在 PM 和工程師的對話中自動浮現。
責任分工,可以…是這樣的…
- 工程師負責說明技術成本、風險、依賴關係與可能的替代方案。
- PM 負責把需求情境、商業影響與時效帶進來。
- 研發主管(或更高層)負責對團隊容量與工作優先順序拍板。
不必期待誰懂財報、成本結構與市場策略。但可以期待一個成熟的組織,不會讓工程師在沒有決策權的情況下替公司做商業選擇,也不會讓 PM 在沒有資源調度權的情況下,獨自扛住客戶與市場壓力。
從「流程」到「信任」的溝通升級
高效的 PM-工程師合作，是建立在對產品目標的共同承諾之上，而不是一份完美的規格書。你必須從工程師的經驗裡學到極限，並從專案的現實裡學到取捨。
下次開會，先不要說「你要做什麼」，而是問「我們要解決什麼問題？」，團隊除了資訊一致，分你.我.他與說「我們」的感覺就是不一樣了…..
YinOnMars 
發表留言