《鳳凰專案》用小說的形式描述一間公司如何從谷底翻身，讓讀者更能體會「管理」對一間公司有多重要。我能從故事裡直接理解書中所闡述的管理方式在實際情況下如何運用——而且運用時不會一帆風順，而是有重重考驗，並且需要高層的全力支持與理解。我認為這是管理相關書籍中相當值得一看的書。
因為故事情節被簡述後就沒辦法讓讀者感受書中情境，因此這篇文章主要是我自己讀後的筆記，記錄我認為書中最重要的管理方法和管理思維。有關故事內容，想了解的話建議自己買書來看。
為什麼 IT 專案要在製品（WIP）越少越好？
書中用工廠管理來比喻我們開發專案的狀況。對工廠管理而言，生產線會盡量避免讓工廠內同時有過多的在製品，也就是所謂庫存。對開發專案來說，在製品指的是「開發中但尚未完成」的功能——它們還無法帶給公司收益，也要極力去減少。
在生產線上，一定會有處理效率最差的點，我們稱為瓶頸點（或稱約束點）。創造約束理論的艾利高德拉特告訴我們：在瓶頸以外任何地方做的改進都是假象。
的確：
| 改進位置 | 結果 |
|---|---|
| 瓶頸點之後 | 徒勞無功，只能乾等瓶頸把工作送過來 |
| 瓶頸點之前 | 只會導致瓶頸處堆積更多庫存 |
| 瓶頸點本身 | 唯一真正有效的改進位置 |
因此，開發專案時要了解公司的瓶頸點在哪，是什麼地方讓最多的專案在等待這個資源、讓需求被卡住無法繼續進行。以鳳凰專案而言，過多的核心資訊被掌握在一個天才員工布倫特手中，只有他知道怎麼處理，導致這個員工每天必須處理非常多的事，也有非常多的事在等待這一個資源。越忙碌的資源，其他資源等待它的時間就會越來越高：
改善這個狀況，第一步就是釐清約束點所在，第二步就是充分利用約束點。以此書案例來說，約束點是天才員工布倫特，他們的做法是：
- 保護約束點：不讓大家直接指使約束點去做他們認為重要的事，安排專門人員來安排布倫特的工作內容，避免大家私自使喚他。
- 不浪費約束點的時間：確認約束點永遠不會因為要遷就其他資源而枯等。
- 將約束點的工作標準化：讓更多其他的人可以接手布倫特正在做的事，提升約束點的產出。
總之，我們要記得任何對非約束點的改善都只是鏡花水月。
什麼是 DevOps 三步工作法？
第一步工作法：建立快速的工作流
幫助我們理解如何建立快速的工作流，讓工作順暢地從開發部移動到 IT 運維部，因為那正是公司與客戶之間的銜接。
這邊需要去了解公司的價值點。相較於把更多的工作投入系統，將不需要的工作從系統中剃除甚至更為重要，讓資訊部門能夠很快速地產出最精簡可用的有價值系統，並獲得反饋。為此，我們需要知道與達成企業目標息息相關的東西是什麼——不論是專案、運營、戰略、合規、安全性等，通通有可能（請見下方的訂定組織目標）。
第二步工作法：縮短並增強回饋循環
告訴我們如何縮短及增強回饋循環，因而能夠從源頭開始解決品質問題，並避免重工。我們也必須設法根除計劃外工作的最大來源。
所有計劃中的工作，在執行前必須分門別類地列出完成工作所需的一切先決條件：例如筆電型號、使用者資訊的規格、軟體及需要的授權，以及它們的組態、版本資訊、資安要求、處理能力和連續性需求等。也就是建構資源清單，亦是物料清單，以及需要的工作中心與生產途程——一旦備妥，加上工單和資源，就可以釐清產能及需求，弄清楚可否接受新工作，並實際為它進行排程。
第二步工作法的關鍵部份是以視覺化的方式呈現等待時間，那樣就能知道你的工作正在某人的佇列中排隊好幾天，或者工作必須往後退，因為未備妥完整的零件。藉由需求清單被列出，接受需求的人在接受訂單時可以先確認每一個必須參與的資源都有需要的投入，讓需求、銷售、開發能一起擬定生產計劃。
第三步工作法：建立持續改善的文化
告訴我們如何建立一種文化，既能鼓勵大家探索、從失敗中汲取教訓，又能理解反覆與練習是精通工作的先決條件。
提升預防性工作是全面生產維護（TPM）這類計劃的核心，精實社群主張我們應不惜一切代價提升維護水準。「改善日常工作甚至比進行日常工作更重要」——持續給系統施加壓力，從而不斷強化習慣並改善某件事情。
也就是所謂「改善型（Improvement Kata）」：書中使用為期兩週的改善循環，每個改善循環都實施一個小型的「計畫 → 執行 → 查核 → 行動」專案，持續朝目標邁進。必要的實務作為包括：
- 建立創新、勇於冒險及高度信任的團隊文化。
- 把至少 20% 的開發和 IT 運維週期分配給非功能性需求，並持續強化及鼓勵大家進行改善活動。
IT 部門的工作可以分成哪四種類型？
這本書將工作分成四種類型：
| 類型 | 說明 |
|---|---|
| 業務專案 | 公司所有的正式專案 |
| 內部 IT 專案 | 由業務專案衍生出來的基礎架構或 IT 運維專案，以及內部生成的改善專案（如建立新環境和部署自動化）。這些專案經常未被集中管理，而是隸屬於預算所有者。 |
| 變更 | 包括需求變更或 BUG 等 |
| 計劃外工作或救火工作 | 包括 production issue，通常由上面三類工作導致，而且往往以犧牲其他計畫內工作為代價 |
書中說第四類工作最具破壞性：它並非實質的工作，其他三種工作都是基於需求而事先計劃好的。計劃外的工作會阻止我們進行其他三類工作——就像物質和反物質，在計畫外的工作面前，所有計劃內的工作都會被延後。
另外一點是未被償還的技術債，源自於走捷徑。短時間內那樣或許行得通，但就像金融債一樣，久而久之利息越滾越多。如果一個組織沒有還清它的技術債，就必須一點一滴耗費心力，以計劃外工作的形式來償還那些技術債的衍生利息。
IT 部門該如何訂定組織目標？
書中列出了 CFO 的營收目標：
- 公司體質健全
- 營收
- 市占率
- 平均訂單規模
- 盈利能力
- 資產收益率
- 財務狀況
- 訂單轉化成現金的周期
- 應收帳款
- 準確且及時的財務報告
- 借貸成本
書中針對每一個營收目標，列出「倚賴 IT 的區域」、「IT 導致的業務風險」以及「倚賴的 IT 控制」，來界定 IT 在這些目標項目中的角色。倚賴的 IT 控制指的是防範這些錯誤發生的反制措施，或者至少能偵測到問題並做出回應。
書中很戲劇化的是 SOX-404 的稽核專案：資安部門原本一直要求開發部門開發一個安全控制的系統，來應付發生錯誤時的資安問題，最後才發現檢測重大錯誤所倚靠的控制手段是人工對帳步驟，而不是上游的 IT 系統——其實財務部門早已用人工的方式達到這個資安要求，不需額外再開發相關系統。因此，不同部門間的資訊透明度真的是一件很重要的事。
遠程目標則包括：
- 我們具競爭力嗎？
- 了解客戶的需求和期望：我們知道要創造什麼嗎？
- 產品組合：我們有正確的產品嗎？
- 研發效能：我們能夠有效地建立產品嗎？
- 產品上市時間：我們能夠盡快把產品推向市場，並搶占一席之地嗎？
- 銷售管道：我們的產品能夠觸及感興趣的潛在客戶嗎？
- 我們的作法有效嗎？
- 按時交貨：我們有遵守對客戶的承諾嗎？
- 顧客維繫：我們正在增加客戶還是流失客戶？
- 銷售預測準確率：我們可以把銷售預測準確率納入銷售計畫流程嗎？
延伸閱讀
- 鳳凰專案導讀：用 DevOps 三步工作法讓 IT 部門從谷底翻身：同樣聚焦 DevOps、約束理論，可接著比較不同情境的做法。
- 鳳凰專案讀後筆記：看IT部門如何讓公司從谷底翻身的傳奇故事：同樣聚焦 DevOps、約束理論，可接著比較不同情境的做法。
- IT 人的學習生存術：Study4 與大師對談精華筆記：同樣聚焦 DevOps，可接著比較不同情境的做法。
常見問題
《鳳凰專案》在講什麼？
它是一本以小說形式包裝的 IT 管理書，描述一位 IT 副總裁如何在 90 天內拯救瀕臨崩潰的部門。書中透過故事闡述約束理論、精實管理和 DevOps 三步工作法等管理思維在實際情境中的運用。
什麼是瓶頸點（約束點）？為什麼它這麼重要？
瓶頸點是整個系統中處理效率最差、決定整體產出的資源。根據約束理論，在瓶頸以外任何地方做的改進都是假象：瓶頸之後的改進只能乾等，瓶頸之前的改進只會堆積更多庫存，唯有改善瓶頸本身才能真正提升產出。
DevOps 三步工作法是哪三步？
第一步建立快速的工作流，讓工作從開發順暢流向運維；第二步縮短並增強回饋循環，從源頭解決品質問題並避免重工；第三步建立持續改善的文化，透過改善型循環（計畫、執行、查核、行動）不斷強化日常工作。
為什麼計劃外工作被認為最具破壞性？
計劃外工作（如救火、production issue）通常由其他三類工作導致，且以犧牲計畫內工作為代價。它會阻止我們進行所有計劃內的工作，就像物質與反物質相遇，讓一切排程被延後；技術債的利息也常以計劃外工作的形式償還。
WIP（在製品）過多對開發團隊有什麼影響？
開發中但未完成的功能無法帶給公司收益，卻占用了團隊產能。WIP 越多，各項工作的等待時間越長、交付週期越慢，問題也更難及早發現，因此要極力減少在製品數量。
參考資料
最後更新
2026-08-28（原文發布於 2018-02-28，本文保留原始筆記內容並補上 GEO 結構。）
關於作者 {#author}
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2018-02-28