專業軟體工程師最明顯的特徵，就是敢於對不合理的要求說「不」。這不是頑固或懶惰，而是負責。面對明知做不到的時程，說「好」是說謊，說「不」才是誠實。而說「不」的另一面是正確地說「是」——用明確的承諾語言，把「我盡量」換成「我將在星期二完成 X」。
🧠 Core Ideas
- 說「不」是為了找到最佳可能解。商業部門的目標是功能與時程，工程部門的目標是品質與可行性，兩者本質衝突。唯有雙方都堅守立場、認真協商，公司才能在兩難中找到最好的結果。
- 無條件點頭是剝奪決策權。如果你總是說好，你就剝奪了公司做出正確權衡的機會——它會以為那個做不到的日期是可行的。
- 時局越關鍵，「不」越珍貴。在最緊急、壓力最大的時刻說「不」最難，卻也最重要——因為此時錯誤決策的成本最高，你的誠實評估最有價值。
- 真正的團隊精神不是配合度高。當隊友或專案正駛向冰山，真正的團隊精神是大聲警告，而不是跟著沈默撞船。
- 承諾包含三個要素：口頭答應、認真看待、實際做到。真正的承諾用明確結構——「我將在【時間點】之前，完成【具體成果】」，核心在那個「我」。
- 警惕逃避責任的詞彙：「need / should」模糊了負責人、「hope / wish」把結果交給運氣、「let’s」用團結稀釋個人承擔。這些都是缺乏真正承諾的紅旗。
TIP
當你說「我會試試看」時，你其實是在承認：你平常有所保留，或你準備開始犧牲品質。專業人士不「試」——他們只承諾做得到的，並拒絕做不到的。「試試看」聽起來合作，實際上什麼都沒承諾，只是把責任模糊化、把災難往後推。
⚖️ 當你無法承諾時，該承諾什麼
不敢承諾，往往是因為存在不可控因素。專業人士不會因此陷入沈默或含糊，而是把不確定性轉化為「自己能控制的行動」。
三種無法承諾情境的轉化
-
依賴第三方：別承諾你控制不了的結果，改承諾你能控制的行動——「我無法承諾他們何時交付，但我承諾明天中午前聯繫他們，並每天追蹤直到取得回應」。
-
需求或細節不清楚：承諾先做一個「探勘（Spike）」或先釐清達標條件，把不確定性轉化為已知資訊，縮短你與目標之間的距離。
-
確定做不到：盡早通知相關人員。這是風險控管的一環——讓對方能及時調整計畫，而不是等到最後一刻才引爆。
🖼️ 堅守原則的協商，長什麼樣子
Uncle Bob 用一段對話示範「說是」的藝術。當 PM 逼問能否週五前完成一件其實要到下週二的工作，專業的回應不是屈服，也不是硬碰硬：
「這樣我得回答『不能』。為了要有十足把握完成，最快得等到下週二。」PM 追問有沒有加速的辦法，回應仍然堅定：「不，我沒法保證。我很抱歉讓你的進度被打亂，但我不能給出我做不到的承諾。」——重申立場，不因壓力妥協承諾的可靠性。若最後要交換，也是有條件的：「好吧，我會這週末加班完成，作為交換，我下週會休息到週三。」這不是無底線的退讓，而是等價交換，保護了自己的可持續性。這整段對話的底層邏輯是：對方問你，正是因為你是那個懂技術現實的人；順從地給出你知道做不到的承諾，才是真正的失職。而「盡量」之所以危險，是因為它給對方虛假的安全感（經理會當成「應該可以」上報）、讓你逃避真正的協商、並在一次次跳票後侵蝕你的專業信譽。
IMPORTANT
軟體領域最有價值的評價，是「這是位嚴謹負責（disciplined and responsible）的開發人員」。而這份評價的基礎，正是你只在真能做到時才說「是」，一旦說了就一定兌現——你的話之所以有分量，是因為它從不打折。
🔑 Takeaways
- 說「不」是為了讓公司找到最佳可能解；無條件點頭等於剝奪它做正確權衡的機會。
- 時局越關鍵，誠實的「不」越珍貴；真正的團隊精神是警告撞船，而非沈默。
- 承諾用「我將在某時完成某事」的明確語言；警惕 need/hope/let’s 這些卸責詞彙。
- 無法承諾時，改承諾你能控制的行動、先做 Spike、或盡早示警。
- 延伸：這套「說不、守紀律」的態度，正是敏捷專業主義的核心，見 敏捷的初衷：回到四個價值觀。
No notes yet — jot your takeaways or Q&A here.