專案延期，怎麼變成工程師溝通問題？

那場檢討會議的場面至今還記得很清楚。螢幕上投影著紅色的甘特圖，顯示專案延期。會議室裡坐著老闆、CTO、PM還有幾個工程師。

會議一開始，老闆就開始針對產品的細節抱怨，這個不應該這樣，那個不應該這樣，這樣使用者怎麼用？PM開始描述自己的規格是有寫的，但是因為工程師說實作會有問題，所以先把功能切開，逐步更新。

「這對我來說就是沒做完阿，沒做完你要我看什麼？」老闆開始咆哮

PM開始檢討：「看起來主要問題是工程師在專案初期沒有充分表達技術難度，導致時程估算不準確。我們需要改善團隊的溝通能力。」

坐在角落的工程師忍不住了：「但我們在第一週的技術評估會議就提過規格不清，而且這個整合跟原本的需求不合，直接做會很複雜，還被批評設計沒有彈性。」

「那你為什麼不更堅持一點？為什麼不更明確地表達風險？」老闆反問。

會議室又安靜了。

最諷刺的是，三個月前的專案啟動會議紀錄還在，當時工程師確實提出過技術擔憂，但會議由CTO拍板要求「先按照原定時程進行，遇到問題再調整」。現在卻變成工程師「溝通不夠明確」的問題。

更離譜的是，時程是老闆訂的，需求是PM變更的，決定切割方案上線的是CTO。但在檢討會上，問題被定義為「工程師溝通能力不足」。

這種現象不是個案。因為「溝通」這個詞很方便，無法直接量化，可以解釋一切問題，也很難被反駁。你說工程師有表達意見？那是表達不夠清楚。 你說工程師提出過風險？那是「沒有充分強調嚴重性」。 你說工程師遵循主管指示？那是「不夠堅持」。

這個模式最巧妙的地方在於，它將系統性的決策失誤，轉換成個人的能力不足。專案延期不是因為時程估算不合理，而是因為工程師不好溝通；功能缺陷不是因為需求不明確，而是因為工程師缺乏產品觀念的理解。

久而久之，工程師開始相信真的是自己的問題，開始花更多時間學習「溝通技巧」，而不是質疑決策流程本身是否有問題。