前言：為什麼工程師討厭政治？
大部工程師最討厭的詞，除了「改需求」，大概就是「辦公室政治」。
在我們熟悉的程式世界裡，$1 + 1$ 永遠等於 $2$，邏輯是確定的。但在職場裡，你可能明明做對了所有事，最後卻莫名其妙變成「背鍋位」；或者某個需求明明技術上不可行，卻因為「老闆說要」而強行推進。這種「不確定性」讓我們感到焦慮、甚至憤怒。我們常說：「我只想好好寫 Code，為什麼要搞這些有的沒的？」
但今天我想換個角度告訴你：辦公室政治，其實只是一套邏輯不同、變量較多、且文檔缺失的「複雜系統」。
如果你能把職場中的每個人看作一個「狀態機（State Machine）」，你會發現那些看似混亂的行為，其實都有跡可循。
核心理論：職場中的「政治狀態機」
在數位電路或軟體開發中，狀態機（FSM）根據目前的「狀態」和「輸入信號」，決定下一個「狀態」和「輸出結果」。
職場中的每個人（你的主管、PM、隔壁組的技術 Lead）也都在跑自己的狀態機。之所以覺得他們「不合理」，是因為你只看到了他們的「輸出（行為）」，卻沒看清楚他們的「當前狀態」和「輸入信號（KPI/壓力源）」。
1. 識別對方的「輸入信號」：KPI 是最強大的驅動指令
在程式碼裡，輸入決定輸出。在職場，KPI 就是那個最強大的 Input。
- PM 的輸入： 上線時間、轉化率、用戶增長。
- 技術主管的輸入： 系統穩定性、團隊產出、部門預算。
- 業務方的輸入： 簽單金額、客戶滿意度。
當 PM 提出一個無理的時程時，他不是針對你，而是他的「狀態機」接收到了來自老闆的強烈輸入信號。如果你只跟他爭論「技術難度（輸出受阻）」，那是無效的溝通。
2. 狀態轉換的觸發條件 (Transitions)
一個冷靜的主管，為什麼突然在會議上發火（狀態轉換）？
通常是因為系統偵測到了「例外（Exception）」：
- 安全感失控： 進度不在他的掌握中。
- 利益受損： 這個決策會讓他在大老闆面前顯得無能。
- 資源爭奪： 另一個組搶走了他原本預定的預算。
實戰操作：如何「預判」不合理的人為例外？
要看透政治，你不需要學會勾心鬥角，你只需要建立一個簡單的**「利益矩陣（Interest Map）」**，這就是你的職場 Debug 工具。
第一步：建立 Stakeholder 的狀態清單
列出跟你工作最相關的 3-5 個人。問自己：
- 他現在的「核心任務」是什麼？（他在跑什麼 Process？）
- 他最近最怕發生什麼事？（他的 Error Handler 關注什麼？）
第二步：分析「側效應（Side Effects）」
當你提出一個技術提案時（例如：重構舊系統），不要只看技術好處。思考這個提案會對其他人的狀態機產生什麼 Side Effect？
- 對 PM： 會不會導致他這週的 Feature 延期？（如果是，他必會觸發「攔截」行為）。
- 對主管： 這能幫他在季末報告增加亮點嗎？（如果是，他會觸發「加速」行為）。
第三步：主動提供「預期內的回調（Callback）」
如果你預見到某個決策會讓 PM 很難做，不要等他來找你吵架。在你的「指令」發出前，先給他一個 Callback：
「我知道重構會占用三天時間，可能會影響到 A 功能的測試。我已經想好了，我們可以先把 B 功能的資源調過來，確保你的上線時程不受影響。」
當你主動處理了對方的「例外情況」，你就掌握了這場政治賽局的主動權。
結語：別關掉政治，要「優化」它
辦公室政治是職場中無法移除的「背景程式（Background Process）」。它佔用內存，有時還會造成系統卡頓。
但一個成熟的工程師，不會試圖 kill 掉這個 Process（你殺不掉的），而是學會如何與它共存。透過理解他人的狀態機，你可以減少被「突發例外」閃退的機率，把精力留給真正有價值的開發工作。
記住：職場沒有絕對的瘋子，只有你還沒看懂的邏輯。
