The Phoenix Project（中譯本《鳳凰專案》）作者如是說：
Dr. Eliyahu Goldratt wrote his seminal book, The Goal: A Process of Ongoing Improvement, in 1984. […] My coauthors and I studied this book for nearly a decade, getting ready to write The Phoenix Project. In many ways, I view our book as an homage to The Goal.
我和共同作者研究高德拉特博士的《目標》將近十年了，為撰寫《鳳凰專案》做準備。我認為，從很多方面來看，我們這本書都是在向《目標》致敬。
如果一本書蘊釀了十年，那麼，這本書就值得我們細細咀嚼。
值得多讀幾次的書
我很早就有《鳳凰專案》這本書的 Kindle 英文版及 Audible 語音版了。
第一次讀完的時間已不可考。第二次是在撰寫〈DevOps 核心元素的考古溯源〉文章時，特地選讀相關的部分。第三次是在準備〈有了 Agile，為什麼還要有 DevOps？〉演講時，對書中所倡議的「三步工作法」做更仔細的檢視。
因此，屈指算來，我在〈轉大人，Part 2〉文中提到的頓悟經歷，已經是第四次讀這本書了：
對於這陣子已經把《目標》、《絕不是靠運氣》、《關鍵鏈》重看一次的我，再回頭重看《鳳凰專案》，開始萌生另一種閱讀角度。
人性的角度。
為什麼要讀這麼多次呢？因為以前不懂得用更寬廣的視野來讀這本書。
這本書每一章，其實都很值得我們設身處地思考：換成是我們，面對那樣的狀況，會採取什麼技術及非技術的手法，去分析局面，找對策。
這也是身為職場大人的自我練習。
這類小說，就像推理小說一樣，本來就不應該直接翻到兇手揭曉的那一頁呀。
核心衝突
這陣子雖然把《目標》、《絕不是靠運氣》、《關鍵鏈》重看一次，對高德拉特在《絕不是靠運氣》的論點，心嚮往之，但又不禁懷疑。高德拉特是這麼說的：
我們不應假設經理人疏忽或無能，我們應該假設他們陷入一個衝突之中，以至於他們無法正確地經營公司。
真的是這樣嗎？
索性拿 DevOps 當實驗品吧！我很好奇：DevOps 的「核心衝突」究竟是什麼？
我想效法《絕不是靠運氣》的主角 Rogo、《鳳凰專案》的主角 Bill，嘗試獨立思考。
當然啦，高德拉特藉著主角 Rogo 之口，事先提出警告：
全套的思維方法
你需要的是：對主題的直覺，及有毅力去執行這套思維方法中的細緻步驟。
— 《絕不是靠運氣》p.125
所以，我對過程中的燒腦程度，已經先有了心理準備。
我興致勃勃的照著高德拉特 Thinking Processes 的步驟，針對 DevOps 常見的問題／痛點／抱怨，老老實實地從 UDE → CRT → clouds → injection → FRT 一路推導 DevOps 議題。
赫然發現：超誇張的，光是用 CRT，就能初步推導出 DevOps 的 CALMS 及所謂的「三步工作法」。而且，DevOps 的核心衝突，果然就出現在 CRT 的下方：
整個推導過程的確燒腦，也橫跨了好幾天，但值得。
《鳳凰專案》最大的貢獻
DevOps 的 CRT 及核心衝突一旦現形，再回頭看《鳳凰專案》，許多推理過程就清晰許多。
你也可以當自己的鐘納。
突然有個很離經叛道的想法：《鳳凰專案》這本書最大的貢獻，恐怕不是所謂的「三步工作法」，而是「四種類型工作」的界定。
畢竟，「四種類型工作」是因，「三步工作法」只是 TOC 及 Lean 的應用之果。
這方面的想法，先賣個關子，留待 DevOps Summit 2016 的演講〈從限制理論看 DevOps〉再發表吧。
經過這些探索歷程，對《鳳凰專案》這本書，心生更多敬意。
作者說他們為了這本書「蘊釀了十年」，誠然不虛。
私房標題
我在〈轉大人，Part 2〉文中曾預告過：
現在重讀《鳳凰專案》時，私底下也在替每一章取個私房標題。接下來，會再加把勁兒，自我要求：練習用 Bryan 課堂上教的分析手法，重新分析箇中情節。
漸漸發現，我想做的，不僅是「導讀」，甚至是「註釋」或「延伸學習單」了。不過我設想的進行方式是，一次只導讀某幾章，不要偷看後面的章節。就像面對推理小說一樣，偷看後面的解密，就不好玩了。
整個活動，需要分好幾次才能完成。也就是說，是個有連載性質的導讀活動。
在哪裡舉辦呢？
辦在公司裡面，優點是風險較低，缺點是參與者同質性過高，激盪火花的力道較弱，我能學到的新東西也較少。或許應該先在有興趣的社群先小規模玩過一次？
事情總是要一步一步來。我先將私房標題的初稿列在下面：
- 沒有蜜月期
- 為什麼是你而不是我？
- 走捷徑
- 交相指責
- 管理人員的角度
- 檢討變更流程
- Erik 登場
- 分類變更要求
- 第三種工作類型
- Brent 的一天
- 半成品堆積
- 上線災難
- 救火
- IT 外包危機
- 第四種工作類型
- 辭職
- 我是十足的混蛋
- 混蛋的告白
- 凍結新工作
- 監控資源
- 怎麼逃過審計的？
- 如何決定優先序？
- 多重工作交接
- John 的用處？
- 對系統的鑑賞
- 魔杖
- IT 風險不是 IT 風險
- 又是 Sarah！
- 特別行動隊
- 持續交付
- Value stream
- “獨角獸”
- 自動化的小勝利
- 收回外包
- 快車道
仍然強烈建議：請將這本書當成推理小說，不要驟然翻到後面。
畢竟：
— Quote: 2016-06-16 Tweet #1
