需求又改了，但沒人告訴我為什麼

週五下午四點半，PM丟了一個會議邀請過來「緊急會議：老闆新需求討論」

會議一開始，PM說：「跟老闆從客戶那邊回來，答應對方在下個月底前上線一個全新的數據分析模組。」全場安靜了三秒，然後主管問：「什麼樣的數據分析？」PM回答：「就是可以讓他們看到各種報表啊，應該不難做吧？」

接下來一個小時，大家拼命想理解「各種報表」到底是什麼意思。需要即時數據嗎？要支援多少使用者同時查詢？資料來源是哪些系統？每個問題都得到模糊的回答，就標準功能吧、看看類似服務有提供功能......

後端工程師試著解釋需求太模糊了，何況我們不知道使用者的問題是什麼。老闆的回應是：「你們工程師總是把事情想得太複雜，先做一版出來再改就好，我們不是傳統開發流程。」

最讓人無奈的是，當工程師提出技術問題和時程擔憂時，老闆卻會認為：「你們系統架構到底是怎麼做的，我怎麼知道什麼能做什麼不能做？平常不溝通，現在才來說這些問題？」

一個月後，專案延期的檢討會上，老闆檢討團隊「溝通不足」，沒有在初期就明確表達技術複雜度。

類似的情況並不少見。老闆跟PM在外面談合作時，經常會基於「估計」來承諾功能和時程，回來之後才發現技術實作比想像中複雜。然後當專案出現問題時，責任就轉到工程師的「溝通能力」上。

更矛盾的是，平常工程師主動提出技術建議或時程評估時，往往被認為是「過度設計」或「太過謹慎」。但當承諾跳票時，又會被說「為什麼不早點說？」

這種模式讓工程師處在一個尷尬的位置：既要為自己沒有參與的決策負責，又要在事後被檢討溝通不足。我們成了不知情的擔保人，要承擔決策失誤的後果。