應用理論：BART (邊界、權威、角色、任務) - Authority (權威)
劃定了清晰的「邊界」之後，「創世紀」專案的巨輪開始轉動。然而，很快，新的問題就出現了。在一個具體的技術決策點上，兩個子團隊的負責人產生了嚴重分歧，爭執不下，導致相關工作停滯了兩天。
這個事件暴露了BART模型中的第二個關鍵維度 權威 (Authority) 的模糊性。
「權威」，在組織中常常是一個敏感詞，容易讓人聯想到命令與控制。但在BART模型中，它是一個中性的概念，指的是「做出決策並驅動他人行動的權力」。一個健康的系統，必須對各類決策的權威歸屬有著清晰的界定。誰有權決定技術方案？誰有權批准預算？誰有權發布上線？當權威模糊時，就會導致決策真空、無休止的爭論，或是錯誤的人做出了超出其能力的決定。
在過去的「星雲科技」，權威的分配是混亂且隱性的。大部分技術權威，都不成文地集中在像大衛和老趙這樣的資深專家身上。這帶來了兩個問題：第一，他們成了決策的瓶頸；第二，他們承擔了過度的壓力，一旦決策失誤，就會成為被指責的對象。而其他團隊成員，則因為缺乏權威，而變得被動和缺乏主人翁精神。
艾佛勒意識到，必須藉著「創世紀」專案這個機會，重塑團隊的權威體系，將權威從基於「個人」的隱性權威，轉向基於「流程」的顯性權威。
他召集了所有子團隊的負責人和核心成員，開了一場名為「誰來做決定？」的權威釐清工作坊。
「在一個複雜的專案中，會產生無數的決策。」艾佛勒開場道，「我們不可能，也不應該把所有決策都交給某一個人或某一個委員會。我們需要建立一個『權威地圖』，讓每個人都清楚，在遇到特定問題時，該由誰來拍板。」
他介紹了一種簡單而有效的工具 決策授權矩陣 (Delegation Matrix)，也被稱為「RACI模型的變種」。他們共同定義了幾種關鍵的權威級別：
D (Decide) - 決定者： 該事項的最終決策者，擁有拍板權和否決權。一個事項的D通常只能有一個。
C (Consult) - 被諮詢者： 在決策前，必須被諮詢意見的人。他們的意見需要被充分聽取，但不具有決定權。
I (Inform) - 被告知者： 在決策後，需要被告知結果的人。
A (Assist) - 協助者： 負責執行決策、提供支持的人。
接著，艾佛勒引導團隊，將「創世紀」專案中可能遇到的各類典型決策事項，一一列出，並共同填寫這份矩陣。
決策事項一：核心資料庫的表結構設計
這是一個全域性的、影響深遠的決策。經過討論，團隊一致認為：
D (決定者)： CTO穆拉提。因為這關乎整個技術資產的未來，必須由她來承擔最終責任。
C (被諮詢者)： 所有子團隊的負責人、資深架構師老趙、DBA（資料庫管理員）。
I (被告知者)： 所有專案成員。
決策事項二：某個微服務內部的接口設計
這是一個子團隊內部的事務。團隊認為，權威應該下放。
D (決定者)： 該子團隊的負責人 (Team Lead)。
C (被諮詢者)： 該服務的主要開發者、與之對接的QA。
I (被告知者)： 需要調用該服務的其他團隊。
決策事項三：將一個功能分支合併到主開發分支 (Merge Request)
這是最日常，但也最關鍵的質量控制環節。過去，這個權威是模糊的，有時是大衛一人說了算，有時是誰都可以點擊合併按鈕。團隊對此進行了熱烈的討論，最終達成了一個全新的共識：
D (決定者)： 流程本身。這是一個巨大的思維轉變。決策權不再屬於某個「人」，而是屬於一個共同制定的「流程」。
流程內容： 一個合併請求，必須同時滿足以下所有條件，才能被合併：
通過所有的自動化測試 (CI)。
獲得至少兩位其他工程師（其中至少一位來自不同子團隊）的批准 (Approve)。
代碼提交者本人，不能批准自己的合併請求。
C (被諮詢者)： 所有被邀請進行Code Review的工程師。
A (協助者)： 代碼提交者，負責根據反饋進行修改。
這個關於「合併權限」的新規定，意義非凡。它巧妙地將權威 (Authority) 和責任 (Responsibility) 進行了分離和分散。最終的「決定權」被交給了一個客觀、公正的流程，避免了個人獨斷。而「批准」的動作，則將質量把關的責任，從過去的某個英雄人物，分散給了團隊中的每一位普通成員。這極大地提升了團隊的集體主人翁感。
當這份清晰的「權威地圖」被制定出來並公示後，團隊的運作效率顯著提升。當再遇到分歧時，大家不再是無休止地爭吵，而是會習慣性地去查閱權威地圖：「這個事兒，歸誰拍板？」如果自己是決定者，就勇敢地承擔起責任；如果自己是被諮-詢者，就充分地表達觀點，然後尊重決定者的最終判斷。
過去那種因為權威不清而導致的內耗和焦慮，被清晰的規則和流程所取代。團隊成員們感覺到，他們腳下的土地，變得越來越堅實、越來越有秩序。
iThome鐵人賽
看影片追技術
看更多
