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