《鳳凰專案》讀後感

圖片來源：https://www.cpht.pro/project/m_simulation-tpp/

這本書很多人推薦，但遲遲沒有入手，某天經過天瓏書局看到中文版，就順手連其他書一起買回家，結果一看，非常有即視感，好像看到過去兩年自己的一些生活點滴，欲罷不能，一個周末就看完了。

快速回顧

故事從災難開始，某個公司的 IT 系統出大包，無法計算員工的薪資，可能在發薪日無法給付正確的薪資，主角則是接手 IT 部門的副總，除了要立即處理無法計算薪資的問題，接著要確保拯救公司業務的大計畫：鳳凰專案能順利在預定的時程順利上線，但開發部什麼時候開發完成還是未知數。

首先著手的是變更管理，變更管理只是建構管理的一環，但卻常常被忽略，就像書中的變更諮詢委員會 (Change Advisory Board) 沒有人要參加一樣，IT 部門的人隨自己需要或開發部的需要，任意變更線上的軟體版本、防火牆設定、資料庫設定、硬體配置等等，沒有人知道會造成什麼影響，當發生問題時，也沒人知道過去做過哪些變更。

為了讓大家開始願意做變更管理，主角捨棄過去不敷使用的變更管理軟體，改以實體的視覺看板，確認那些變更將在甚麼時候要實施，並對變更進行分級，像是例行性的變更、影響層面大的變更，讓團隊在有一定自主性及立即性的處理外，能做到進一步的控管。透過看板，發現到很多變更因為一些瓶頸被卡住，沒在預定的時間實施變更。

但在顧問的提醒下，發現僅僅變更管理只是局部優化，找出整體工作流程的瓶頸才能做出整體優化。好不容易團隊慢慢開始出現正向的改變，不顧主角的提醒，搞不清楚問題嚴重性，硬要發佈趕工出來、尚未完整測試、有問題的鳳凰專案的經營團隊讓稍微有起色的 IT 系統瞬間又因為出現一堆問題陷入地獄中，也讓公司失去眾多客戶的信心，更多的狀況，讓 IT 團隊奔波於計畫外的工作，沒法專注在計劃內的工作，最後，在電話中，主角與 CEO 激烈爭執，以辭職結束第一部。

有幾段話特別有感觸：

身為 IT 營運部副總，你的工作是確保形成一條迅速、可預測、流暢的計劃工作流，為公司創造價值，同時盡量降低非計劃工作的衝擊與干擾，這樣的話，你才能夠提供穩定、安全、可預測的 IT 服務。

記住，重點不單是減少在製品，相較於把更多工作投入系統，將不需要的工作從系統中剔除甚至更重要。

我們必須把這些知識全部傳承給實際從事這項工作的人，如果他們對此無法心領神會，那樣的話，恐怕就是那些團隊的技術能力有問題。

第二部以 CEO 強行介入，直接指揮 IT 團隊的大小事，反而讓整個 IT 系統更加崩潰，只好再把主角找回來的情節展開。在一場真心話大冒險 (？) 的會議後，大家放開彼此的心防，也體會到「已完成」的定義需要重新調整，找到整個 IT 維運部的瓶頸 (一個什麼都處理也只有他知道怎麼處理的人)，理解四種工作類型：業務專案、IT 維護專案、變更及計畫外的工作，而計畫外的工作會讓團隊疲於奔命，真正計畫內的工作處理時間變短，品質下降然後陷入死亡螺旋。最後做出暫時凍結鳳凰專案以外所有專案的決定。

同時在關鍵人員的四周放上看板，讓關鍵人員專注在鳳凰專案上，並試著讓很多工作標準化，讓其他人可以處理，而非只有這位關鍵人員能處理。在慢慢上軌道後，開始解除非需要關鍵人員的專案。開始大量在各式工作使用看板，讓工作流開始變順暢。也注意到，要讓工作流變順暢，工作流中的每個人都需要閒置時間或稱作鬆弛時間，如果大家都沒有鬆弛時間，工作就會卡住，只能乾等。

一次偶然的機會，主角與 CFO 碰面，並理解 CFO 對公司所設下的目標與評估指標，也和銷售部副總見面，在多與其他部門面談後，主角不再只是從 IT 營運部的視角看到工作流的價值鏈，而是更高的層次，以整個公司運作的角度看 IT 營運部在整個系統中的價值，以及判斷哪些專案是真的對公司有價值，哪些不是。

IT 營運部的團隊開始與開發部的團隊一起合作，在開發之初便把如何部署加入設計中。整個營運開始步向正軌，除了一個人私下胡搞瞎搞，偷偷繞過監控對營運中的系統做變更，讓鳳凰專案的一次部署又出問題，結束第二部。

我們的目標是提高整個系統的生產力，而不只是提高任務的完成數量，要是你們連一個可靠的工作系統都沒有，憑什麼要我信任你們的安全控制系統？

告知真相是愛的行動，隱瞞真相則是恨的表現，甚至更糟，是一種徹底的冷漠。

在任何工作系統裡，理論上的理想狀態都是單件工作流 (single-piece flow)，這樣能夠讓生產裡最大化，同時讓變異性最小化，透過持續不斷地降低批次規模 (batch size)，就能達到這種狀態。

工作流只朝一個方向移動：向前，請在 IT 部門中創造一個只向前移動的工作系統。切記，目標是單件工作流。

第三部從與顧問的對話開始，顧問建議將部署的週期加快，並提到 Flickr 一日十部署的經驗，調整建置與部署的流程，讓部署自動化，為了達成這目標，成立了一個特別行動小組，以敏捷開發的方式，開始清除障礙，克服困難，開始進入三步工作法的第三步，創造公司文化，形成兩種風氣：持續不斷地實驗，這需要承擔風險並且從成功和失敗中汲取經驗和教訓；體認反覆和練習是達成精通的基本前提。最後以主角成為下任 COO 的候選人，並開始養成計畫結束整個故事。

讓程式碼與基礎架構更能因應故障與失敗。最後，我們真的擁有回復能力超強、堅固耐用的 IT 服務。

我們必須建立一種文化，尊崇勇與冒險以及從失敗中學習的價值觀，並且透過反覆時間精益求精的必要性。

我不想在辦公室裡張貼強調品質與安全的宣傳海報，但我希望日常工作的改善能夠落實集體現在需要的地方：在每日的工作成果上。

讀後感

我還記得念博班時帶學弟妹做計畫時，自己常是那個瓶頸，很多事只有我自己做才放心，自己做才能達到自己認為的品質，但那時我的指導教授就提醒過我，應該要讓自己能離開目前的崗位為目標，不能讓事情只有你才能做，所以，後來開始工作後，就養成習慣，所有的事情只要做過一兩次，便會留下文件，並開始讓其他人去做，即便做過很多事情，改善過很多工作上的流程，這些知識都不只有在我的腦中，所以每次的離職交接總是很快，因為我手上的工作其他人也都會做，只是熟練或不熟練的差別，品質好或沒那麼好的差別。

這本書以小說形式，把建構管理 (configuration management)、看板方法 (kanban method)、限制理論 (Theory of Constraints)、三步工作法 (The three ways) 及 DevOps 以活靈活現的例子串在一起，十分有趣。很推薦給所有從事 IT 相關產業的工程師。