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.

如果一本書蘊釀了十年,那麼,這本書就值得我們細細咀嚼。

--- Quote: 2016-06-16 Tweet #1


我很早就有 The Phoenix Project 這本書的 Kindle 英文版及 Audible 語音版了,第一次讀完的時間已不可考。第二次是在撰寫〈DevOps 核心元素的考古溯源〉文章時,特地選讀相關的部分。第三次是在準備〈有了 Agile,為什麼還要有 DevOps?〉演講時,對書中所倡議的 "The Three Ways"(「三步工作法」)做更仔細的檢視;也就是在這場演講中得知,最近天瓏書局又進口一批簡中譯本《鳳凰項目》了,於是,趕緊下單(否則就缺貨了),以求對箇中情節轉折有更精準的掌握。

因此,算起來,我在〈轉大人,Part 2〉文中提到的經歷,已經是第四次讀這本書了:

對於這陣子已經把《目標》、《絕不是靠運氣》、《關鍵鏈》重看一次的我,再回頭重看《鳳凰項目》,開始萌生另一種閱讀角度。

人性的角度。



為什麼要讀這麼多次呢?

因為以前不懂得用更寬廣的視野來讀這本書。

這本書每一章,其實都很值得我們設身處地思考:換成是我們,面對那樣的狀況,會採取什麼技術及非技術的手法,去分析局面,找對策。

這也是身為職場大人的自我練習。

這類小說,就像推理小說一樣,本來就不應該直接翻到兇手揭曉的那一頁呀。



這陣子雖然把《目標》、《絕不是靠運氣》、《關鍵鏈》重看一次,對高德拉特在《絕不是靠運氣》的論點,心嚮往之,但又不禁懷疑:

我們不應假設經理人疏忽或無能,我們應該假設他們陷入一個衝突之中,以至於他們無法正確地經營公司。

真的是這樣嗎?

索性拿 DevOps 當實驗品吧!我很好奇:DevOps 的「核心衝突」究竟是什麼?

我想效法《絕不是靠運氣》的主角 Rogo、《鳳凰項目》的主角 Bill,嘗試獨立思考。

當然啦,高德拉特藉著主角 Rogo 之口,事先提出警告:

全套的思維方法
你需要的是:對主題的直覺,及有毅力去執行這套思維方法中的細緻步驟。
《絕不是靠運氣》p.125

所以,我對過程中的燒腦程度,已經先有了心理準備。

興致勃勃的照著高德拉特 Thinking Processes 的步驟,針對 DevOps 常見的問題/痛點/抱怨,老老實實地從 UDE → CRT → Clouds → injection → FRT 一路推導 DevOps 議題。

赫然發現:超誇張的,光是用 CRT,就能初步推導出 DevOps 的 CALMS 及所謂的 "The Three Ways"...

而且,DevOps 的核心衝突,果然就出現在 CRT 的下方:


整個推導過程的確燒腦,也橫跨了好幾天,但值得。

DevOps 的 CRT 及核心衝突一旦現形,再回頭看《鳳凰項目》,許多推理過程就清晰許多。

突然有個很離經叛道的想法:這本書最大的貢獻,恐怕不是所謂的「三步工作法」,而是「四種類型工作」的界定。

「四種類型工作」是因,「三步工作法」只是 TOC 及 Lean 的應用之果。

這方面的想法,先賣個關子,留待 DevOps Summit 2016 的演講〈從限制理論看 DevOps〉再發表吧。



經過這些探索歷程,對《鳳凰項目》這本書,心生更多敬意。

作者說他們為了這本書「蘊釀了十年」,誠然不虛。

我在〈轉大人,Part 2〉文中曾預告過:

現在重讀《鳳凰項目》時,私底下也在替每一章取個私房標題。接下來,會再加把勁兒,自我要求:練習用 Bryan 課堂上教的分析手法,重新分析箇中情節。

漸漸發現,我想做的,不僅是導讀,甚至是註釋或延伸學習單了。

不過我設想的進行方式是,一次只導讀某幾章,不要偷看後面的章節。就像面對推理小說一樣,偷看後面的解密,就不好玩了。

所以,整個活動,需要分好幾次才能完成。也就是說,是個有連載性質的導讀活動。

辦在公司裡面,優點是風險較低,缺點是參與者同質性過高,激盪火花的力道較弱,我能學到的新東西也較少。或許應該先在有興趣的社群先小規模玩過一次?

事情總是要一步一步來。我先將私房標題的初稿列在下面:

  1. 沒有蜜月期
  2. 為什麼是你而不是我?
  3. 走捷徑
  4. 交相指責
  5. 管理人員的角度
  6. 檢討變更流程
  7. Erik 登場
  8. 分類變更要求
  9. 第三種工作類型
  10. Brent 的一天
  11. 半成品堆積
  12. 上線災難
  13. 救火
  14. IT 外包危機
  15. 第四種工作類型
  16. 辭職
  17. 我是十足的混蛋
  18. 混蛋的告白
  19. 凍結新工作
  20. 監控資源
  21. 怎麼逃過審計的?
  22. 如何決定優先序?
  23. 多重工作交接
  24. John 的用處?
  25. 對系統的鑑賞
  26. 魔杖
  27. IT 風險不是 IT 風險
  28. 又是 Sarah!
  29. 特別行動隊
  30. 持續交付
  31. Value stream
  32. “獨角獸”
  33. 自動化的小勝利
  34. 收回外包
  35. 快車道


仍然強烈建議:請將這本書當成推理小說,不要驟然翻到後面。


〔2016/07/19 補充〕 我決定開一門線上課程:《除了 DevOps 之外,鳳凰項目還說了什麼?》,歡迎對這本書有興趣的,共襄盛舉。