《鳳凰專案》一書通過 IT DevOps開發管理的案例，展示如何將工廠管理的最佳實務運用到現代IT開發上，並提升運用在開發人力上的投資效益，搭配Lean StartUp 與敏捷開發精神，一舉讓IT團隊為公司起死回生。 書中操作方式與心法包含了：看板工作流、約束點、等待時間的管理或降低、衝刺團隊、三步工作法。 非 IT 人員也可學習如何讓需求到開發的環節更順暢美好。
前言
你是否有類似體驗：有個簡單的想法需要 IT 同仁完成，但不知道為什麼外面廠商說起來很簡單的小小應用，公司 IT 團隊會說需要長達好幾個月的訪談、再加上為了資安或是合規的系統設計與調整，等到東西可以測試已經是 15 個月後，都還沒到能上線應用。
而 IT 團隊也苦不堪言：總是有應付不完的使用者需求、還不完的技術債、覺得自己系統東倒西歪，要改善不知道哪年哪月，希望爭取到幾個月時間或是更多人員處理，但總被公司高層當作成本單位而被要脅著要外包出去。最慘的是，不知為何而戰，沒有辦法實際感覺自己開發與部署的功能到底怎樣才能真的幫公司賺錢？
大家不禁會懷疑：無效率就是人類日常，公司只有打掉重練，搭配天縱英才懂技術又懂市場的天才，才有機會稍見曙光吧。
《鳳凰專案》簡介
《鳳凰專案》（買書由此去）的主角是在汽車零件公司，原本是最邊緣的 IT 維運中心主管比爾。
這是比爾的部門從公司的最邊緣出發，差點整個部門被踢出去當外包人員、歷經造成公司公關危機、被開發與稽核兩邊追殺，最後反轉成為公司業務振興的英雄人物的傳奇故事（我都想要把書名改成鳳凰傳說了）。
比爾透過DevOps讓本來超過 3 年還無法上線鳳凰專案，從上線了又造成全公司門市結帳系統死當一週的死亡專案，翻身變成跑得動、可以百倍快速部署，甚至搭載推薦引擎，讓塵封資料庫中的顧客購買與產品庫存資料，變成在黑色星期五即時推薦購買的金礦；最後還克服短期過高運量造成的網站與門市系統的過載危機。
現代公司的日常
書中案例幾乎都是我們每天會遇到的，像是：
- 超過 3 年還無法上線的專案，還能夠回應市場需求嗎？
- 天才工程師是每個團隊的救星嗎，還是其實是問題製造者？
- 流程單位是一切的阻礙，如何把繁複的提交上線表格變成有用的看板系統？
- CISO 只會誇大隱私風險，對實際業務目標沒有幫助？如何改變 CISO 團隊？
- 行銷單位找實習生寫個工具就能快速上線，為什麼 IT 要搞好幾個月還不能用？
- 一個月上版一次合理嗎？怎樣才能做到一天上版十次嗎？
- 需求單位永遠講不清楚？還是市場就是這麼不清楚？
- 虛擬機與雲端運算是噱頭嗎？怎樣讓雲端運算在用量暴增時幫上忙？
- 從 PlanB 到錯誤演練，如何在緊急時刻保留生產力？
- 外包管理，當非核心系統變回核心系統，如何確保組織的承接能力？
轉變日常成經典
本書的核心精神是 IT 開發管理其實不像想像中的神秘不可解，
應該將工廠管理上的最佳實務（約束理論、看板精神等）運用到 IT 開發與管理上，打造 DevOps 作業讓開發與上版融為一體。
光是這樣還不夠，更進而引進精實創業 (Lean) 與敏捷開發的作法，小步快跑得讓產品業務需求單位與 IT 開發及管理單位組成共同體，弭平市場、需求與生產之間的巨大時間鴻溝，才能提升運用在開發人力上的投資效益。
書中提到的操作方式與心法，摘要如下：
- 看板工作流，讓一切可視化
- 約束點，避免有用的資源成為瓶頸
- 等待時間的管理或降低，資源滿載會造成無效率
- 衝刺團隊，從需求到開發到運維還有 CISO 同心協力
- 三步工作法，從工作中心主任到工廠廠長
非 IT 人員的學習
《鳳凰專案》一書的副標「看 IT 部門如何讓公司谷底翻身的傳奇故事」，很精準的說明作者的經歷與心態，還有推廣 DevOps 的苦心，畢竟 IT 已經走過聽起來神奇的科技斗篷，而是現代生產力的一部分，那把工廠管理的最佳實務拿來應用，而且應用的好的人的確才會是現代公司的核心人才。那麼非 IT 人員在這種公司中就要淪為配角嗎？
有趣的是，當我跟 IT 業界朋友分享本書時，他們的反應是：
IT 還有其他主管心態怎樣開始轉變的？
主角比爾與他的 CEO 克服了被外包、被稽核無止盡要求、被拆分、CEO 只能外包策略給行銷單位的傾斜後才完成轉變。公司的高層如果沒意識到上列危機，是沒辦法讓 IT 主管成為公司候選 COO 的。
任何行銷、業務、產品人員，更懂需求是怎樣開發的，甚至理解 DevOps 過程與關鍵環節，而不是抱持著提出需求後，就可以一切交給 IT 人員的心態，是不是也有機會讓需求到開發的環節更順暢美好？