「當系統開發變成『主管的感覺』對抗『開發者的眼淚』，你缺的不是技術，而是對權力的重新定義。」
現場感：那場永遠開不完的流程會議
「那個...王總，上週我們不是才對過流程，說採購單超過五萬才要簽核嗎？工程師已經把主幹寫好了。」會議室裡，冷氣吹得很強，但我看到 PM 的額頭在冒汗。
王總放下了原子筆，輕描淡寫地說：「我想了一下，這樣不保險。只要是特定供應商，不論金額我都要看。還有，那個『預計交期』欄位，能不能讓業務填完、採購改、最後會計再點一下確認？」
我看著旁邊工程師的表情，他雖然沒說話，但敲鍵盤的速度明顯變快了——那是在忍住不翻白眼的憤怒。
這場景你一定不陌生。數位轉型到一半，最卡腳的往往不是技術，而是主管或老闆對於流程的「翻盤」。這件事最奇怪的地方在於：為什麼明明說好的事，只要一變成系統，大家就突然都不敢決定了？ 這其實帶出了一個更大的問題：當流程從「人腦」搬到「電腦」時，主管交出的不只是作業，還有權力。
這是我在協助企業進行數位轉型時最常看到的場景。最奇怪的不是「需求變更」，而是當我們在討論「系統欄位」時，大家其實是在博弈「誰說了算」。這件事其實帶出了一個更大的問題：數位轉型失敗，往往不是因為技術跟不上，而是組織內部對於「權力與責任」的分配，從來沒有達成共識。
客製化的糖衣，往往是流程混亂的毒藥
在討論如何應對「喬不定」之前，我們要先看清一個本質問題：為什麼我們要選「全客製」或「半客製」？
許多主管喜歡「全客製」，因為那聽起來像量身打造的西裝。好處是系統完全貼合現有流程，缺點則是它會無限度地包容組織的「懶惰」——因為不願意優化爛流程，所以要求系統去適應爛流程。
而「半客製」（套用套裝軟體模組）雖然有框架限制，看起來不方便，但它其實是在強迫企業進行「體質檢查」。
破局三問：當主管事後翻盤，你該如何應對？
當你遇到主管對欄位定義猶豫不決，或是在系統開發中途翻盤時，身為專案負責人，不能只是「聽話」，你需要用「破局三問」重新掌握主動權：
- 看見問題：他翻盤的「恐懼」是什麼？ 主管為什麼翻盤？通常不是因為他愛找麻煩，而是因為「看不見」。看不見對系統完成後的想像，而多半這種狀態主管反而會使用自己習慣的思考方式來做溝通，譬如在紙上或白板上再重新畫出流程圖，試圖想像那系統上線後的操作步驟。另外，當系統流程數位化後，他失去了過去「口頭交代」的控制感。他翻盤，是因為他害怕一旦自動化了，他就沒辦法在細節裡「抓錯」。
- 切入角度：從「欄位」轉向「場景」 不要問主管「這個欄位要不要？」要問他「在什麼樣的特殊情況下，你會需要看這份報表？」，更多時候，是原本討論中沒有想到的觀點和工作模式，反而在事後系統開發到一定程度後，才又想起，這時候增加欄位，把技術討論拉回到商務場景，讓主管意識到：多改一個欄位，背後代價是系統穩定性的風險。
- 建立循環：小步快跑，不要一次到位 如果主幹喬不定，就先做「最小可行性產品（MVP）」。告訴主管：「我們先按 A 方案跑一個月，如果真的不行，我們有預留第二階段的修正空間。」這個步驟最保險，也是大多客製開發商都可以配合的狀態。
面對不斷變動的需求，你可以採取這三種具體策略：
- 策略一：視覺化「連鎖反應圖」 當主管說要改一個流程時，不要只說「這很難改」。你要當場畫出：改了這個 A 節點，會導致 B 報表出不來、C 關聯出錯。讓主管知道，他改的不是一個欄位，而是一串成本。
- 策略二：建立「決策凍結期」 在專案啟動時，就明確定義「需求凍結點」。一旦過了這個點，任何修改都必須進入「變更申請程序（CR）」，由更高層級的委員會（或是老闆本人）簽署。這能有效阻止主管因為「突然想到」而隨意修改。
- 策略三：引入「外部參考系」 當內部僵持不下時，引用同業或軟體原廠的最佳實踐（Best Practice）。告訴主管：「業界標準通常是這樣處理，我們可以先試行，如果有特殊需求再進行二期開發。」這能減輕主管「做錯決定」的心理壓力。
拆解：最有效的溝通模式——「講故事，不講道理」
如果你想推動主管做決定，不要跟他談 SQL、談 API。你要跟他談「效率」與「風險」。
比方說，與其說「全客製化會導致開發週期延長三個月」，不如說：「王總，如果我們現在為了這個特殊流程改主幹，就像是在蓋房子時，地基都打好了才說要多挖一個地下室。這不只費錢，還可能讓整個房子的結構變不穩。我們能不能先用現有的客廳，等裝潢完（系統上線）發現不夠大，我們再來擴建？」
結語與行動呼籲 (CTA)
數位轉型的主幹喬不定，本質上是一場「組織政治學」。系統只是鏡子，照出的是主管對權力的焦慮與對未來的不確定感。
身為專案負責人的你，目標不是開發出完美的系統，而是協助主管在「控制感」與「效率」之間找到平衡。
你現在負責的專案中，也有一個「改了又改」的欄位嗎？試著不要去解釋技術難度，而是用這篇文章提到的「連鎖反應圖」，去跟主管聊聊那個改動背後的真實商業代價。
如果你也遇到類似的轉型瓶頸，歡迎在評論區分享你的「奇葩改需求」經驗，我們一起拆解背後的真問題。
