文章目錄
對於很多技術人員來說，鳳凰專案是一本講 Agile 的書，或是一個講 DevOps的書，但對我來說他闡述了甲方IT部門的所有血淚。
書中的所有系統，看起來幾乎都是由 IT 部門自行開發，或是採購交付原始碼的量身訂做系統進行再開發的，只有少數如 CTI 是由供應商維運，部門R&R分配極為細緻，有資安部門、MIS部門、寫程式的部門以及負責部署的部門，看似還有一個專做系統Helpdesk的部門。而他們面對的問題是，在一個製造銷售汽車零件的公司，當工廠管理、B2B銷售、B2C銷售、門市與EC銷售等等的系統都由IT自行維運。
在業務與行銷部門強勢的狀況下，IT部門不停地被要求進行多種系統開發與變更。在所有的壓力下，IT 所欠下的技術債過於龐大，導致更多的維運跟故障修復需要由IT人員手動進行。各種疊床架屋後，衍發出來的就是MRP不準確(物料管理)、訂單不準確、財務不準確，更別提銷售預估、客戶分析等等需要準確數據才能進行的事情了。
而書名的上的鳳凰專案，到底此專案本身要幹嘛，要解決甚麼問題，其實從頭到尾都沒有說明，只知道這個專案就是只許成功不許失敗! 看起來完成鳳凰專案就可以讓這家公司起死回生，一切順風順水，但其實該專案從設計到上線歷經三年，並且在部署時遇到一百萬個困難，而主人公 Bill 被臨危授命，要拯救鳳凰專案，否則董事會就要把公司拆分、將 IT 外包讓 IT 都捲舖蓋走路。
這本書其實就是一個衰爆了的PM接了一個燙手山芋後怎麼從這裏面學習拯救一間業務最大的公司的紀錄
可以成功的因素
我永遠記得我念書時，教科書上面寫的：
ERP導入成功的關鍵就是高層的支持。
當然所有的高層都必須表面支持像ERP導入這樣的大型專案，但是他必須是一個由最高層支持，並且從一開始就要高度承諾的事情。因為在IT進行這些任務的同時，維運的需求也會無法停止，這個不是人力的問題，因為各種需求都會高度干擾專案進行。
在本書中有一個神奇人物Eric，他是潛在投資者，董事會的高度來強迫跟說服 CEO 進行對 IT 有利的決策，並且屏蔽稽核相關的干擾，讓 IT 可以專心進行專案。這是一般時候 IT 部門並沒有的優勢
當然一度 Bill 也被惹火，因為 CEO 拒絕 Bill 的要求，所以提出辭呈。當然在 CEO 認知到自己錯誤之前的這段時間，所有的營運上連環爆的雷就接二連三的襲擊財務、門市、銷售等等部門，實際上的營業損失跟商譽損失，讓CEO 必須要聽進 Eric 的話，並且反省自己、痛定思痛，開始重視 IT 並且不再介入與質疑 IT 部門的決策。
除了下列提出的各種方法論以外，我認為高層才是這種跨部門大型專案是否成功唯一的因素。
為何會造成這麼嚴重的局面?
書中的 Sara 也就是業務部門的主管，他會不停的指控 IT 是公司成功的絆腳石，因為系統的不準確或是無法趕上競爭對手，他不僅對 IT 部門頤指氣使，不停的要求 IT 快速開發他想要的程式、生產架構。當 IT 說 NO 的時候，就是他再一次指責 IT 部門的機會。
然而就是因為業務部門的各種強迫，導致 IT 殺雞取卵的隕石式開發，將整個系統沒有章法的亂做一通，雖然能夠暫時交差，但同時也毀滅了系統的可靠性。莎拉並沒有做錯，替自己部門爭取權益是每一個主管的職責，而錯是錯在 CEO 本身，並沒有辦法平衡各部門勢力，理解整個公司的運作並不是只靠銷售業績。不管這間公司有或沒有 IT 部門的配置，更多時候偏頗業務單位的行為，會對公司體質跟文化造成毀滅性的後果。
在我看這本書之前，我看到大家的心得多半著重於變更管理，以及整個鳳凰專案或整個零極限公司的最重要 IT 生產力-布倫特
不只是零極限公司，相信很多公司或組織都有一個布倫特，一個知道所有系統互相怎麼作動、當事情發生時怎麼處置、問題怎麼排除等等的工程師(或是PM)，這樣的人經常是因為除了本身聰明以外，待在公司時間也夠長，知道事情怎麼發生。
然而當他要一面救火的時候，該怎麼一面支持鳳凰專案的開展? 尤其他也有可能時不時會被莎拉拉到其他地方、手機被打爆、整個人都要被四分五裂了!(這就是我的人生)
當然前人也曾經找過聰明的工程師，希望他們可以去分擔布倫特的工作，但結果就是，布倫特為了要帶新人，更沒有時間處理事情，而且更多時候，這些新人也都無法吸收布倫特的工作，後來就不了了之。
後來的處理方法其實很理所當然，就是凍結大部分的專案，並且過濾布倫特的任務，如果必須要他處理的任務，那他就也要帶一個工程師過去，在他處理的同時將處理的方法記錄下來成為標準作業程序文件，只要是同樣的事情再度發生，就不需要布倫特處理。
這個方法跟上面講的前人的方法，難道不一樣嗎? 當然不一樣!
我已經快忙死了，然後我還要【負責】這個新人能不能吸收我剛剛講的話? 我還要【叮囑】他記下重點並且當他下次需要執行類似任務時，我還需要在旁邊【觀察並指導】確認他知道他在幹嘛。
VS
這個新人可以自我管理或他有相對應的上司主管，我反正就是一樣的方式處理面前的問題，並且一邊解說，你能不能吸收聽懂或做到，跟我沒有關係，因為你下次能不能執行類似任務，不是我的責任，而是你必須向你的上司報告的。
這個差別很明確了吧? 關鍵的資源需要被保護，才能確保他能夠發揮最大的效用，而保護他的方式並不是扔給他新人，這樣一點也沒有起到保護的作用，反而是將他推向深淵。
稽核&資安部門的攪局
當然很多人一聽到稽核部門就是反感，感到他們就是一群吹毛求疵的傢伙，天天拿著放大鏡寫下缺失，每次開會就是限期改善。資安部門也是一天到晚弱掃，總有解決不完的弱掃報告!
書中的John就是這麼一討人厭的腳色，拿著黑色的大活頁簿，試圖闖進每一個會議，並且要求每一個部門進行他所要的系統變更。
前面提到的神奇Eric 除了用財務的人力去解決了根本可以人工核算的某個稽核項目，而不需要在N個系統中進行N個變更。其實更多時侯，稽核需求大部分都有轉圜跟非IT手段的作法，完全不需要大興土木的作法。
而在本書的後段，John會大變身歐! 我覺得這一段還滿令人開心的!
如何起死回生
很多做開發的軟體工作者，都不覺得製造業有啥了不起，而且常常覺得自己的工作比較聰明，不能跟製造業混為一談，也不能以管理製造業的方式管理軟體專案。我只能說真的天真了。生產製造產業的管理理論至少百年以上，並且還在不斷進化中。
差別只在於他有原料需要採購、供應鏈需要管理，但在產線上、產能促進以及QC的理論，很多都是經過千錘百鍊，而且管理效率都比八成以上的軟體專案效率高得多。我在製造業的企管顧問經驗告訴我，你可別小看製造業的生管單位，書中後面都有舉例例如豐田的精實製造理論等等。要成為力挽狂瀾的 IT 管理者，如果對於百年以上的管理實務跟供應鏈理論基礎感到輕蔑，那我只希望你不需要面對像零極限公司那樣的工作環境!!
DevOps
有一陣子DevOps成了顯學，一個DevOps的薪資從一百變兩百到更上去的都有，而在今時今日的環境中，DevOps的重要性可能不需要我贅述，而建製 CI/CD也都應該是標準動作，如果有不清楚怎麼進行，請找專業的顧問公司協助!
版本變更管理
版本變更管理讓整個專案起始回升扮演著舉足輕重的角色，就像是每次程式上板都要有Release note一樣的意思，每次上板要納入哪些變更，哪些變更會影響到其他的系統，都需要有清楚的歸納，而如何去紀錄各個系統界接的歸納就仰賴SA的功力，可惜的是現在自稱 SA 的人相當多，能夠清楚記錄系統變更、系統與系統間間串接關係職能，已經從所謂的 SA 跨足到 TPM 的這一個腳色，然而好的 TPM (要能嫻熟的做到Technical&Project Management)的人非常稀少，人才的取得是這個關鍵職位的困難。
敏捷開發
敏捷開發也是其中很關鍵環節，甚至延續到續集: 獨角獸專案。
敏捷開發讓在製品很快可以變成成品，快速反應市場機制並且縮短投資到收益的這一個期間，可以快速的回收並檢視市場對產品的反應。敏捷開發在台灣已經流行並行之有年，但敏捷開發始終是一個做法，到底大家怎麼做才可以達到最好的效果，還是事在人為。
我認為敏捷開發的內容已經太廣泛，我就不在這裡贅述。
了解公司目標、部門目標、收斂需求
上述講的都是書中可以看到條列式的方法，而不管是哪種方法都是事在人為，且台灣的企業環境要做到很精實的敏捷開發與變更管理，真的很困難，因為總是會有天外飛來一筆的需求，會有很多莎拉一直打電話、傳LINE、打給你老闆要求你現在馬上處理他的問題。
所以我不想花太多時間說明這些大家都知道的「方法」，就像我不想從頭開始講 PMP 會教的那一套理論，因為理論是一回事，怎麼應用在台灣的企業是完全另外一回事。
我覺得比較有用的方法是，PM必須要了解公司的目標跟各部門的目標，台灣的公司，尤其是兩百人以下的中小企業，我目前沒聽過有進行真正的KPI 績效考核，就算有，也只是財報上的業務目標，並沒有真正的去評估間接KPI的重要性。例如書中提到的，必須要有好的客戶偏好預測，才能抓準預計的生產量，那誰去做客戶偏好預測?他預測得準嗎? IT通常都是成本部門，而所有的成本部門要花錢時，都是被打上一個大叉叉，所以我們如果沒有夠的機器，怎麼去跑多出來的分析報表呢? 又或者，我們沒有預算買好的always on設備，怎麼做到風險管理呢?
扯遠了，我要說的是，各個部門無論是業務行銷還是生產製造，每天都會因為他們部門目標對 IT 提出千千萬萬的需求，如果是利潤中心制的公司可能還好，就內部計價。如果不是，IT部門要如何才能在有限的人力物力預算中，排出合理的生產流程? 通常是看誰嗓門大，誰會賺錢，就先做他的對吧!? 但其實不可以這樣做啊! IT 部門才最應該要了解公司【今天】遇到甚麼困境、【未來】想去哪裡? 並且對於各個部門的計畫與挑戰規劃未來願景與藍圖，確保公司競爭力的部門! 所以我特別推薦最後Bill帶著John去了解各部門職能與目標的那一段，後來他產生了像這樣的表
IT部門要有能力建立一個基礎建設，才能在這個基礎建設上，讓公司各個職能發揮長才，然後進行更進一步的:【獨角獸專案】，將競爭對手甩開越拉越遠的。
