理解價值流中的工作#

一旦確定了要應用 DevOps 原則的價值流，下一步是充分理解價值如何交付給客戶：什麼工作由誰執行，以及可以採取哪些步驟來改善流動。

Nordstrom 團隊多年來的經驗表明，改善任何價值流最有效的方式之一是：與所有主要利害關係人舉辦工作坊，執行 Value Stream Mapping（價值流圖）練習。

Nordstrom 化妝品業務辦公室案例#

Kissler 分享了一個關於 Cosmetics Business Office 應用的故事——一個 COBOL 主機應用，支援門店美容和化妝品部門的銷售人員註冊、佣金追蹤和供應商退款。

• 十年來每年規劃週期都在討論要把這個應用搬離主機，但從未真正執行
• 透過 Value Stream Mapping 工作坊，發現真正的問題不在 COBOL 應用本身
• 部門經理提交表單時被要求填寫他們沒有的員工編號，且需要離開賣場到後台使用 PC
• 工作坊中的實驗（如刪除員工編號欄位）減少了四天的處理時間
• 後來用 iPad 應用取代 PC 應用，處理時間進一步縮短到秒級

這個案例說明 Value Stream Mapping 最大的價值往往不在於確認已知問題，而是發現意想不到的洞察——真正的瓶頸可能與我們原先假設的完全不同。

識別支持價值流的團隊#

在任何具有一定複雜度的價值流中，沒有任何一個人知道為客戶創造價值所需的全部工作。工作通常分佈在許多不同的團隊中。選定候選應用或服務後，必須識別價值流中所有負責協作創造價值的成員，包括：

• Product Owner：定義服務下一組功能的業務內部代言人
• Development：負責開發應用功能的團隊
• QA：負責確保回饋循環和服務功能符合期望的團隊
• Operations：負責維護生產環境並確保服務水準的團隊
• Infosec：負責系統和資料安全的團隊
• Release Managers：負責管理和協調生產部署與發佈流程的人員
• Technology Executives / Value Stream Manager：負責確保價值流從頭到尾滿足或超越客戶和組織需求的人

建立價值流圖以看見工作#

識別價值流成員後，下一步是以 Value Stream Map 的形式，具體理解工作如何執行。

在技術價值流中，工作通常從 Product Owner 的客戶需求或商業假說開始，經過 Development 實作、版本控制、建構整合、類生產環境測試，最終部署到生產環境。

在許多傳統組織中，這個價值流可能包含數百甚至數千個步驟，需要數百人的參與。記錄如此複雜的價值流圖可能需要多天的工作坊。

價值流圖的重點關注區域#

• 需要工單（ticket）的地方：如工作在團隊間的交接
• 工作需要等待數週甚至數月的地方：如取得類生產環境、變更審批流程、安全審查流程
• 產生大量返工（rework）的地方

繪製價值流圖的實務#

• 初次繪製只需包含高層級的流程區塊
• 即使是複雜的價值流，團隊通常也能在幾小時內建立一張包含 5-15 個流程區塊的圖
• 每個流程區塊應包含：
  • Lead Time（前置時間）：工作項目等待被處理的時間
  • Process Time（處理時間）：實際處理工作項目的時間
  • %C/A（完整且準確百分比）：由下游消費者衡量的輸出品質

Damon Edwards（DevOps Cafe podcast 共同主持人）觀察到：「Value Stream Mapping 練習總是令人大開眼界。通常這是人們第一次看到為客戶交付價值需要多少工作和英雄式努力。」

利用指標引導改進#

從價值流圖中獲得的指標用於引導改進方向。例如：

• Nordstrom 案例中，他們聚焦於部門經理提交的請求表單的低 %C/A 率
• 其他情況可能是：交付正確配置的測試環境給開發團隊時的長前置時間或低 %C/A 率
• 或是每次軟體發佈前執行和通過迴歸測試所需的長前置時間

確定要改善的指標後，應進行更深入的觀察和測量，然後建構一個理想化的未來狀態價值流圖，作為三到十二個月內要達成的目標條件。

建立專責轉型團隊#

DevOps 轉型等計畫不可避免地會與日常營運產生衝突。成功的企業已建立了延續其成功實踐的機制，而官僚體制尤其具有韌性。

Dr. Vijay Govindarajan 和 Dr. Chris Trimble 在 The Other Side of Innovation 中主張：組織需要建立一個專責轉型團隊（dedicated team），能夠在負責日常營運的組織之外運作。

專責團隊的組建原則#

• 成員應全職投入 DevOps 轉型（而非「維持現有職責，另花 20% 時間」）
• 選擇具有跨領域技能的通才
• 選擇與組織其他部門有長期良好關係的成員
• 盡可能為團隊建立獨立的物理空間

盡可能讓轉型團隊免除許多限制組織其他部分的規則和政策。既有流程是一種組織記憶——專責團隊需要創造新的流程和學習，產生我們期望的成果，建立新的組織記憶。

達成共識的目標#

改進計畫中最重要的部分之一是定義一個可衡量的目標，設定六個月到兩年的明確期限。目標應需要相當的努力但仍可達成，且達成後能為組織和客戶創造明顯價值。

改進目標範例：

• 將產品支援和非計畫性工作的預算佔比減少 50%
• 確保從 code check-in 到生產發佈的前置時間在 95% 的變更中為一週或更短
• 確保發佈可以在正常營業時間內執行，零停機
• 將所有資安控制整合到部署管線中，通過所有合規要求

保持改進規劃的短週期#

在 DevOps 轉型專案中，需要保持短的規劃週期，就像新創公司做產品開發一樣。計畫應在數週內（最壞情況下數月）產生可衡量的改進或可行動的數據。

短週期規劃的好處：

• 靈活性：能快速重新排序和重新規劃
• 縮短回饋延遲：強化回饋循環，成功的改進激勵更多投資
• 更快的學習：第一次迭代的學習更快整合到下一次迭代
• 降低啟動門檻：減少推動改進所需的啟動能量
• 降低風險：減少專案在產生成果前被終止的可能性

保留 20% 的週期用於非功能需求和技術債#

如何優先排序流程改進是一個常見問題——最需要改進的組織往往最缺乏時間。這在技術組織中尤為嚴重，因為技術債的存在。

保留每個開發週期 20% 的容量用於償還技術債和處理非功能需求，是確保持續改進不被日常功能開發完全擠壓的關鍵策略。