專責轉型團隊

🎯 什麼情境該想到我

當你「想推動改革，但所有人都還揹著原本的日常職責」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：把轉型工作從日常營運中隔離出來，交給一支只做這件事、並對可衡量的系統級成果負責的團隊。

為什麼需要隔離：

• 概念出自 Govindarajan 與 Trimble 的《The Other Side of Innovation》——組織要建立一支能在「負責日常營運的那一大塊」之外運作的團隊，他們把兩者分別稱為 dedicated team 與 performance engine。（L3106–3120）
• 成功久了的組織會用專業化、效率與可重複性、強制審批的官僚體系、防止變異的控制來保護現狀。書中形容官僚體系韌性驚人：移掉一半的官僚，流程照樣活下來。（L3093–3098）
• 顛覆與創新會直接對上負責日常營運的群體與內部官僚，而後者幾乎總是贏。（L3100–3104）

怎麼組：

• 先訂一個明確、可衡量的系統級成果，例如「把從 code committed into version control 到 successfully running in production 的部署前置時間降低 50%」。（L3122–3125）
• 四條規則（L3126–3138）：
  1. 100% 專職——書中明白反對「維持你所有現有職責，但花 20% 的時間搞這個新的 DevOps 東西」這種安排。
  2. 選通才（generalists），技能橫跨多個領域。
  3. 選和組織其他人有長期且互相尊重關係的人。
  4. 盡可能給獨立的實體空間，最大化團隊內的溝通流動，並與組織其他部分隔開。
• 盡可能把轉型團隊從限制其他人的規則與政策中鬆綁，如 National Instruments 的做法。理由是：既有流程是一種制度記憶，而我們需要專責團隊去創造新的流程與學習，形成新的制度記憶。（L3140–3145）

共同目標怎麼訂：

• 可衡量、有明確截止日，落在六個月到兩年之間；要花相當的力氣但仍可達成，且達成後對整個組織與客戶有明顯價值。（L3153–3158）
• 目標與時間框架要由高層共同認可、讓組織裡每個人都知道。目標範例（L3164–3176）：
  • 把花在產品支援與計畫外工作的預算比例降 50%。
  • 確保 95% 的變更從 code check-in 到上線的 lead time 在一週以內。
  • 確保發布永遠可以在正常上班時間、零停機執行。
  • 把所有必要的資安控制整合進部署管線，以通過所有合規要求。
• 節奏：像產品開發一樣迭代推進，一個迭代通常兩到四週。每個迭代訂一小組能產生價值、並朝長期目標推進的目標；迭代結束時檢視進度、重訂下一輪。（L3178–3184）

原文：「Assign members of the dedicated team to be solely allocated to the DevOps transformation efforts」（L3126–3127）

🧪 我實際套用的紀錄

• （待填）

⚠️ 注意 / 什麼時候不適用

• 同時進行的這類倡議要限制數量，否則會超出領導者與組織的變革管理承載力。（L3160–3164）
• 規劃視野要短，像新創做產品／客戶開發一樣：數週內（最差是數月）就要產出可衡量的改善或可行動的資料。好處包括更快重排優先序、縮短「投入」與「看見改善」之間的延遲、更快的學習迴圈，以及降低專案在做出可展示成果之前就被砍掉的風險。（L3187–3212）
• 專責團隊不只對團隊本身好，對 performance engine 也好——把實驗帶來的干擾與分心隔在外面。（L3147–3150）

🔗 相關工具

• 價值流圖（先用價值流圖決定這支團隊要攻哪一段）
• 保留 20% 產能給非功能需求（專責團隊之外，一般團隊也要有固定的改善產能）
• 兩個披薩團隊（專責團隊本身也該小到能維持共享理解）
• 工具-三步工作法（轉型團隊要推的就是這三步）
• DevOps手冊