冤大頭工作的五個死因：為什麼努力半天還是被取消？

重點速覽 10 分鐘閱讀

冤大頭工作可拆成技術、市場、管理、需求、政治五個原因，解法各不相同
多數白工死在管理、需求、政治這後三項，而它們都能靠專案管理能力解決
直覺不是天賦，是大量經驗的內化；能掃描越多維度，盲點越少、老闆越信任

一位聽眾 Han Yi 寫信到大人的Small Talk。他是一位有五年資歷的軟體工程師，即將調任美國，想趁離開前總結這幾年犯過的錯。他發現最影響工作效率的，是他稱為「冤大頭工作」的東西——那些投入大量時間與精力，最終卻不被承認、甚至被取消的工作。有些是他自己主動想做的，有些是主管指派、卻被更上層否決。例如開發一個新功能，結果客戶不買單；或提出後台架構調整，結果效能提升不如預期。

他真正困擾的，是「風險不低、但潛在價值很高」的那一塊事情。他公司有一套保護機制：新嘗試要先提案、審批、拆解任務才能執行，目的是讓失敗的責任不會全壓在個人身上。但這套流程的副作用是，很多有機會的事情更慢才知道行不行得通。他舉了一個例子：一位同事提出的效能改善計畫，原本預期能提升 50%，但在一年多的審查與挑戰過程中，很多小優化陸續上線，等計畫真正落地時只剩 20%。計畫沒有失敗，價值卻被時間稀釋掉了。

Han Yi 的問題其實是一串：直覺判斷能力如何養成？怎麼在風險還沒被完全量化前做出大致正確的決策？又該如何建立那種「老闆不需要我鉅細靡遺解釋，就願意信任我」的能力？他甚至預感，在 AI 普及、風險可以被大量自動化消除的時代，人類真正的價值可能就在於這種提前判斷方向是否正確的能力。

Joe 的回答，從一個提醒開始：不要把白工籠統地歸納成「我運氣不好」或「老闆反覆無常」。如果你想在職涯上更進一步，就要學會把失敗拆得更細。

先把「冤大頭」拆成五個原因

依 Joe 多年的觀察，一個任務會變成冤大頭工作——努力半天卻被取消或失敗——通常不外乎五個原因，而這五個原因的解法完全不一樣。

graph TD
    T[任務變成冤大頭] --> A[技術問題<br/>能力不到位]
    T --> B[市場問題<br/>做出來沒人要]
    T --> C[管理問題<br/>專案執行混亂]
    T --> D[需求問題<br/>沒搞懂老闆要什麼]
    T --> E[政治問題<br/>部門角力夾殺]

一、技術問題

簡單說就是技術不到位。你以為某個功能能輕鬆做出來，搞了一個月卻發現跟想像差很多，做不出來、或做出來效能很差。Han Yi 提到的後台架構改造、效能提升不如預期，很可能就屬於這一類。

這沒有捷徑，就是回歸基本面提升技術能力。更重要的方向是不要貪心：如果你判斷自己現在只有 50 分的能力，硬接一個 90 分難度的任務，變成冤大頭的機率自然很高。稍微跳高一點點——50 分的能力去挑 60 分的任務——這是進步的動力；但落差太大時，關鍵是對自己坦誠，承認實力不夠、然後積極補強。

二、市場問題

技術上你做得出來，而且做得很棒，但推出去後沒人要用；或你以為大家會搶著買單，結果發現是超級小眾的需求。這就是 Han Yi 信裡寫的「客戶不買單」。

Han Yi 提到一個困擾：為了評估風險，老闆期待先做一個 MVP，而這個 MVP 可能就花掉 70% 的時間。Joe 的建議是：如果 MVP 真要花掉 70% 的時間，那它可能根本還不夠「最小」——很可能不自覺地又把它做得離完美更近了一點。如果真的無法簡化、非投入這麼多成本不可，那就反過來確認：這個專案的預期價值夠不夠高？如果潛在回報巨大，那 70% 的成本就是一個合理的賭注，輸了也不算冤大頭，因為贏了能大贏。

關鍵還是退一步想：怎麼用最低的成本去測試市場。商業測試不一定要在技術上做到某個程度。Joe 舉 Dropbox 為例：它不是先把產品開發出來才賣，而是在有點子的當下就做了一個網站、開始招募 waiting list，確認真有需求後才開始開發。

三、管理問題

技術到位、市場也有，但專案執行一塌糊塗：進度延遲、團隊吵架、資源沒到位、外包跑掉……整個專案被拖垮，最後靠一兩個大神勉強上線。

四、需求問題

老闆一開始的需求講得很含糊，例如「我要一個風格大氣的頁面」。PM 或工程師其實沒聽懂，又不敢問、不知道怎麼問，或以為自己聽懂了，就悶著頭做。搞了一兩個月東西拿出來，老闆臉色一沉說「這不是我要的」，整組打掉重來。

五、政治問題

A 部門想做、B 部門極力反對、C 部門有成本考量、D 部門希望趕快上線。你夾在中間，每個都做一半，最後因為部門高層的角力，專案走到一個奇怪的樣貌，甚至直接被犧牲掉。

重點在後面三個

Joe 強調：依他的觀察，職場中搞不好 80% 的冤大頭工作不是死在技術，也不是死在市場，而是死在管理、需求、政治這後三項。

很多工程師因為職能的關係，會非常專注解決技術問題——這是好事，但也導致他們碰到管理、需求、政治問題時，覺得「那超出我的控制範圍」，於是歸咎於運氣、歸咎於老闆。可是這三項其實都能被解決、也該被解決，因為公司一旦變大，它們一定會出現。

解決的核心能力，廣義來說就是專案管理。這也是為什麼大人學一直鼓勵技術人員、不論最後會不會掛 PM 的頭銜，都要去點專案管理這個技能樹——它是避免自己變成冤大頭最強的盾牌。

一個懂專案管理的人，在老闆提出模糊需求時，不會急著動手寫 code，而是先進行需求訪談；訪談也不是直接問「你要什麼」，而是用特定的溝通方法去確認老闆真正的意圖。懂利害關係人管理的人，在專案啟動前會先看看這案子可能踩到誰的線、誰會反對、誰會支持，先去疏通、合縱連橫。

當這五個潛在失敗原因，你能主動控制其中四個——技術 OK、管理擅長、需求談清楚、政治先擺平——只剩市場比較難控制，成功率自然就高了。

直覺，是大量經驗的內化

回到 Han Yi 問的「直覺如何培養」。Joe 的答案是：你能解決的問題種類越多、碰過的越多，直覺就越準。

他舉了一個投手的報導：當投球次數超過某個很大的量之後，球一出手、還沒進手套，投手在那一瞬間就知道會不會進好球帶、會不會被打出去。這就是直覺——但直覺不是魔法，從理性角度看，它就是大量經驗的內化。就像談戀愛，第一次交往看對方傳個貼圖會猜半天；交往經驗多了，光是回訊息的速度快慢，你馬上就能捕捉到訊號。

那些資深前輩看起來「不用做實驗就知道方向對不對」，是因為他們已經看過 10 個、100 個類似專案死掉的樣子。所以方法沒有捷徑：把工作當成練功。踩了坑是經驗，避開坑也是經驗；無論成功的專案還是失敗的冤大頭，都是很好的教材。

具體做法是：下一個任務來的時候，強迫自己跳出工程師視角，去掃描那五個維度——技術上有沒有坑？做出來誰會買單？這任務誰負責、資源夠嗎、時程合理嗎？老闆到底要什麼、背後想解決的目的是什麼？誰會不高興、誰是潛在阻力、我怎麼合縱連橫？你能想得越周全，就越能看見漏洞在哪。「大致正確」不是靠猜，而是靠全面的掃描、靠經驗與知識。

信任，來自「你能搞定意外」

Han Yi 還問：怎麼建立讓老闆不必鉅細靡遺聽你解釋、就願意信任你的能力？

很多專業人士有個誤區，以為要「證明自己很厲害」老闆才會信任——於是簡報塞滿數據、架構圖、程式碼，想展現自己多辛苦多嚴謹。但 Joe 點破：老闆很可能看不懂，也不想看那麼細。老闆之所以要你做繁瑣報告、設下一堆審查流程，只有一個原因——他不安心。他不確定把事情交給你會不會搞砸、會不會讓他賠錢、會不會讓他無法對上面交代，只能用控制手段來減緩焦慮。

所以獲取信任的關鍵，不是展現技術多高超，而是讓老闆覺得「你不但能搞定技術，還能搞定意外」。意外正是來自市場、管理、政治、需求那幾個面向。當老闆發現你拿到需求不是埋頭就做、而是會反問問題（他從你的提問就能判斷你的程度、確認彼此有沒有對焦），會主動控制進度、預先想到別的部門會不會吵架，他就不用盯著你——因為你跟他在同一條路線上，他有了可控感，自然會放手，把最大的信任交給你。

說穿了，專案管理就是建立一套可預期性的技術。這東西有了，判斷會更精準、專案推進會更順、人和會提升，連老闆的安心感都會增加。