ClearForge
重點：工程師架構提案推不動，多半不是技術錯，而是沒把「請主管決定」改成「幫決策者降低做決定的門檻」。
你有沒有遇過這種情況：
你很確定 A 比 B 好，但提案就是推不動。
一次一對一的架構決策拆解
前 2 天晚上，跟一位網友進行了一次線上一對一的架構設計決策拆解。
其實我已經很少跟人一起拆解架構設計決策了。一方面是近年來 AI 崛起，許多人習慣直接問 AI；另一方面是因為當了主管，甚至還是一二線主管的主管，因此大多數的時候是直接看著方案下結論，多半是要求調整後重新審查。
應該沒有太多人知道，我其實很不喜歡「架構審查」，我近幾年的心態更偏向拆解、討論與找到彼此有共識的方案。可是由於身份的錨定效應，並不是每個人都勇於挑戰自己主管的觀點，特別是對方還握有績效考核權的時候（笑）。
題外話：現在回頭看自己年輕時，真的是很莽撞，很少在管對方是誰，覺得設計方案不好就直接開槍。在此感謝以前主管對我的容忍 XD
工程師提案常見的盲點：以技術最優解為主
這位朋友準備其實已經相當充份了：業務需求的評估、不同方案的技術優缺點、未來的擴展性等等。許多工程師看到他準備的文件，相信也會覺得已經很不錯了。
但對談過程中，他表示他想推的提案，是比較乾淨且未來可持續依業務成長的更優方案，但他認為被主管接受的機率並不高。
我覺得這的確是工程師在提案時很容易有的盲點：
以技術最優解為主，卻忽略了一旦架構決策被攤開來檢視，主管、老闆最在意的，前三名通常都不會是技術，而是——
業務影響、風險控管、成本限制。
你提供的是選擇題，但主管看到的是黑洞
那天晚上我主要就是幫他換一個角度看自己的提案。
他原本的提案邏輯是：「這是方案 A，這是方案 B，各有什麼優缺點，請主管決定。」
我跟他說，這個做法的問題是——
你只是提供了技術方案的決策選擇給主管，卻沒有提供不同方案延伸帶來的問題解方。
對主管來說，這些都是黑洞，都是風險。
他不一定有能力判斷技術細節，但他非常清楚一件事：選錯了是他要對客戶、公司及團隊成員負責。 他只會選最保守的那個，或者要你再想想。
技術方案再漂亮，如果主管看完之後的感覺是「風險我看不清楚」，他就不會買單。
另一個完全沒意識到的盲區：維運
他做了很扎實的技術比較，但這些全部不在他的文件裡：
- Redis Cluster 的 reshard 再平衡怎麼處理
- 節點部分故障的 SOP 該怎麼做
- 雲端環境有沒有平台限制
這不意外。
因為這些東西你單純看技術文章加上問 AI，不一定問得出來，因為根本就沒想到要問這些問題。
那是曾經從坑中爬出來的人才知道。
那天花最多時間的，是重新組織提案結構
把「品質屬性需求」拉出來——Write Performance、Memory Efficiency、Read Latency、Availability——逐條攤開。
這樣做的目的是讓架構設計有一個客觀的衡量標準，幫助每個人看到盲點。
更實際的效果是：主管不見得需要完全理解技術細節，我們透過決策矩陣，讓每個取捨都有明確的依據。
他要做的不是「判斷哪個技術比較好」，而是「在這些業務取捨裡面挑他能接受的」。
對我來說，這才是提案的本質——幫決策者降低做決定的門檻。
為什麼我不喜歡架構審查
聊完之後我自己也在想，其實我不喜歡架構審查，可能不只是性格問題。
- 架構審查的預設姿態是「我來看你的方案有什麼問題」
- 拆解討論的姿態是「我們一起把這個問題想清楚」
產出可能一樣，但過程中，人的狀態是不同的。
審查容易有防衛心態，討論和拆解反而讓雙方都有機會重新理解問題。
一個問題留給你
你上一次提方案，覺得明明 A 比較好、但就是推不動的時候——覺得是卡在哪裡？