工程師的經驗，為何總與專案現實脫節？

你一定遇過這種狀況：你帶著緊急的業務需求去找工程師，他們卻回你一句：「最近沒空。」或「我們時程很滿了。」

這時候你心裡一定會想：「難道專案的現實，比如市場壓力、客戶流失，真的不關工程師的事嗎？」

我的看法是：當工程師習慣性地用「沒空」來阻擋需求時，問題通常不在於「有沒有時間」，而在於「你沒有讓他知道這個需求的商業價值與優先級」。

• 工程師的經驗（內向）： 他們基於對程式碼的理解，認為「沒空」是因為手上的技術任務更重要。
• 專案的現實（外向）： PM 必須讓工程師理解，他們的程式碼決策，直接影響市場的生存與否。

摩擦的根源是角色的誤解。你不是工程師的「發包者」，他們不是你的「代工廠」。你們是共同為產品負責的夥伴。PM 必須理解工程師思維，才能有效溝通。

---

一、摩擦點一： PM 只給「答案」，不給「問題情境」

這是最浪費工程師精力的問題：PM 直接在規格書裡寫「請實作一個按鈕，按下去做 X 動作」。

工程師需要「情境（Context）」來判斷技術價值

當你只給工程師「答案」（例如：實作某個功能），他們就只能當一個執行者。他們會基於程式碼的複雜度來估算時程，而不是基於商業目標來判算技術投入的價值。

你應該提供「情境（Context）」而非「解決方案（Solution）」。因為當他們知道「Why」（例如：這個功能能幫公司多賺 100 萬），他們就有權利和動力去挑戰你提供的「What」，並提出更高效、更有成本效益的技術解。

實戰建議：在規格書開頭寫下「這個功能存在的商業目標是什麼？」和「希望解決使用者的什麼痛點？」。讓工程師從「執行者」升級為「共同解決問題的夥伴」。

---

二、摩擦點二：估算時程中的「理想主義陷阱」

當工程師說「這需要一週」時，通常是基於自己「最順利」的經驗。但現實的專案，總是被技術債、突發狀況和模糊的規格所拖累。

PM 的模糊，是工程師的規格地獄

PM 必須理解，工程師估算時程，裡面通常包含了測試、例外處理和潛在的重構。如果 PM 在驗收標準（Definition of Done, DOD）上模糊不清，工程師就會傾向於選擇「最快完成」的邏輯，而不是「最符合商業目標」的邏輯。

一個模糊的「完成」，會讓工程師在開發過程中不斷猜測，最終導致來回修改和時程超支。

實戰建議：估算時程要轉為「雙向討論」。PM 提出商業目標的輕重緩急，工程師提出三種方案（快、中、慢）的風險和代價，由 PM 和團隊共同決定要承擔哪種風險。這才是真正的專案管理。

---

三、摩擦點三：工程師說「沒空」， PM 卻無力反駁

PM 帶著業務的壓力，要求工程師在不理解技術複雜度的情況下「硬擠」時程。

PM 在「分配資源」上失職，導致工程師只能「自保」

當工程師說「沒空」時，他們是在對你進行「防禦性估算」，因為他們知道 PM 可能會隨意插單。這代表 PM 在資源管理和專案優次上失職。

你不能只是要求他們「硬擠」。你必須學會帶著「機會成本」去談判：

• PM：「我知道你們在修復 X 技術債。但這個新需求 Y 能為公司在下個月帶來 50 萬營收，你願意把 X 換成 Y 嗎？」

這才是讓工程師將「專案的現實」納入考量的方式。當他們理解了「機會成本」，他們就能從技術職責跨越到商業責任。

---

結論：從「流程」到「信任」的溝通升級

高效的 PM-工程師合作，是建立在對產品目標的共同承諾之上，而不是一份完美的規格書。

你必須從工程師的經驗裡學到極限，並從專案的現實裡學到取捨。

下次開會，先不要說「你要做什麼」，而是問「我們要解決什麼問題？」