書摘 - 鳳凰計畫 (The phoenix Project )

圖片來源：itrevolution.com

任何理論和方法論都是為了解決某些情境下產生的問題，但對於大多數執行者或是遵行者來說這些方法論都只是優化後的結果，並沒有像Design pattern 一樣說明這些方法是為了解決什麼問題，如果不用會產生什麼問題....不過透過小說描述慘況讓讀者感同身受(這些都是我們會遇到的)，再搭配解決的方法 (或是解決方法的演進)，的確會是比較容易吸收，於是乎就有了這本書：

The Phoenix Project - A Novel About IT, DevOps, and Helping Your Business Win.

故事的背景：

• 為了投資人與市場，所訂出不合理的時程
• 研發與維運單位的對立
• IT 主管人士人士大變動
• IT 維運部門在各個項目疲於奔命，卻缺少以下資訊：
• 需求變更紀錄與流程
• 部署變更紀錄與流程
• 部門工作執掌項目列表與狀態追蹤 
• 過多的工作的關鍵都在少數人身上

一場從大公司IT 部門所產生的的完美風暴......

從我的觀點來看這本書的脈絡是，第一部分從IT部門出發：

1. 從渾沌混亂中理出頭緒(視覺化並修正專案管理的方法)
2. 找出瓶頸，找出約束點，如何定義優先順序 (參考關鍵鍊，目標)
3. 定義工作的類型：

• 業務專案
• 內部專案
• 變更工作 (Security Patch, System Upgrade....等)
• 非預期工作 (A.K.A 救火工作)

第二部分回到整個公司的Scope，不以IT層面思考：

1. 如何有效跨部門合作與解決業務需求的痛點
2. 從最源頭找出對公司最有價值的工作，和真正要關注的問題
• 我們有競爭力嗎？
• 瞭解客戶的需求和期待：我們知道要創建什麼嗎？
• 產品：我們有正確的產品嗎？
• 研發效能：我們能有效的創建產品嗎？
• 上架時間：能盡快的把產品推向市場並且佔有一席之地嗎？
• 銷售管道：產品能吸引來有興趣的潛在客戶嗎？效率高嗎?
• 按時交貨：我們能遵守對客戶的承諾嗎？
• 客戶保留：我們是在獲得客戶還是再流失客戶？
• 銷售預測準確率：我ˇ可能可以把銷售預測準確率納入銷售計畫嗎？
3. 如何針對上面的目標訂立正確的KPI，與預防監控機制(比如說什麼數字沒做到會影響上面的KPI?)

光是以上的部分已經佔了本書的4/5 ，看到這邊會一直問阿DevOps勒？一直到這本書最後1/5 章節才回到IT部門，開始提到DevOps 相關的內容，如何透過快速且小量的發佈來快速得到回饋。

我覺得這樣的架構恰好也是許多公司再推行敏捷轉換該有的順序和比重。

第一部分專案管理的改善(Agile Scrum Kanban)
第二部分談到的就比較像是Lean Startup 談到的東西(MVP lean canvas)
第三部分才是DevOps


此外在這本書裡面也有向另一系列大作致敬 - 高德拉特四書(仍然不足夠+目標+絕不是靠運氣+關鍵鏈)，這一系列的重點就是約束理論:在瓶頸以外的地方做改善都是假象，任何局部最佳化也都是假象，所以大家要專注在找到瓶頸與解決瓶頸。