最近在讀一本名為《鳳凰專案：一個IT運維的傳奇故事》的書，讀後頗有感觸，從業這麼多年，的確碰到過書中的很多場景，書中描繪的故事其實就是現實工作中的各類縮影。

　　本書講述了一位IT經理臨危受命，在未來董事的幫助和自己經驗的支撐下，改變了公司混亂的局面，最終挽救了一傢俱有悠久歷史的汽車配件製造商的故事。

一、人物

　　書中出場的人物，囊括了公司中的各類崗位（有管理層，也有基層），並且性格雖然各異，但很具有代表性。下面只列出了書中的幾個人物。

　　比爾：本書主人公，由於他的兩個上司被趕走了，所以只能被CEO臨危受命，直升為IT運營部副總裁。

　　史蒂夫：公司CEO，剛辭去擔任8年之久的董事長職務，董事會給了他6個月時間，要求他對公司現狀作出顯著的改進。

　　莎拉：運營部高階副總裁，總是能讓別人替她背黑鍋，特別是讓IT部門的人背黑鍋。多年來，她一直能逃脫各種應負的責任。

　　韋斯：技術運營部總監，負責一千多臺Windows伺服器以及資料庫和網路團隊的技術問題。說話響亮、直率、信口開河。

　　布倫特：首席工程師，韋斯的下屬，一直參與IT部門開展的各大重要專案。每天在疲於奔命，處理突發、棘手或沒人知道的專案問題，常常因為各種原因而導致各類計劃延期。

　　帕蒂：IT服務支援部總監，管理所有的1級和2級客服技術人員，處理故障維修事件，併為業務部門提出的需求提供支援。還掌管一些維繫整個IT運維部的關鍵流程和工具，比如報修系統、監控系統，以及組織變更管理會議。

　　約翰：首席資訊保安官，曾讓公司很多人厭惡的人，因為大家覺得他在阻礙自己的工作，不過最終他做出了改變，適應了公司環境，和同事一起改變了公司。

　　克里斯：應用程式開發部副總裁，開發業務所需的應用程式和程式碼，現在生活完全以鳳凰專案為主導。

　　埃瑞克：候選董事，公司主席和史蒂夫都特別關注的人，想盡辦法邀請他加入董事會，經常為比爾指點迷津。

二、過程

1）工資核算故障

　　比爾剛任命就遇到了麻煩的工資核算故障，這個故障會影響員工的工資，這樣就觸犯了無數條州立勞動法，而且毫無疑問，工會馬上就要大吵大鬧了。

　　韋斯：“聯絡SAN供應商，因為在嘗試恢復SAN之後，資料服務就完全停止了，但SAN現場工程師至少還要4個小時才能過來。”

　　比爾判斷當前的方向是錯誤的，於是去找布倫特瞭解情況。期間查檢查了昨天從工資核算資料庫裡匯出的資料，發現所有工廠小時工的社保卡號全亂了。

　　這是一條非常重要的線索。資料庫裡只有一個欄位損壞了，聽起來絕對不像是個SAN故障。

　　再次詢問布倫特，他說：“昨天開發計時應用程式的人，反饋了一個數據庫表結構的奇怪問題。”

　　馬上聯絡那名開發人員，但他在休假中。事情有些眉目了，也許是一個開發人員為了能去度假，塞進了一個緊急的變更。可能是約翰推進的某個緊急專案的一部分。

　　約翰的人從不按照我們的流程來，所以總是惹出麻煩。於是馬上聯絡了他，他那邊有一個關於PII儲存的緊急審計問題，PII就是個人驗證資訊的簡稱，歐盟法律禁止儲存這類資料。

　　約翰：“根據原定計劃，差不多一年之前就該完成部署，但儘管我不斷催促，它一直都沒能完成。現在沒時間了。支付卡行業審計師，本月晚些時候要來，所以就加快了計時應用團隊的工作進度。”

　　帕蒂聽後強調：“對產品進行任何變更，都有一套規定的程式和流程。如果繞過它們，惹出大麻煩，自己的人還得幫忙修補。 為什麼不按照流程去做？”

　　約翰不以為然：“如果按照流程來，那麼下一個可能的部署視窗期要等4個月。但審計師們可是下週就要來了！”

　　當比爾問約翰有沒有進行過測試時，他回答沒有測試環境。雖然之前已經提出過預算申請，但還是不了了之。

　　帕蒂抱怨道，她一直試圖讓大家使用變更管理流 程和工具，但就像約翰那樣，沒人用它。報修系統也一樣，都是有一搭沒一搭的。

　　帕蒂繼續說：“變更諮詢委員會，也就是CAB，會碰一兩次頭。用不了幾個星期，大家就會說自己太忙，不再參加會議了。或者由於時間緊迫，他們不等得到授權就進行變更。不論是哪一種情況，變更諮詢委員會都會在一個月內變得形同虛設。”

　　計時應用直到晚上7點才得以恢復。半夜11點，SAN終於恢復執行。比爾作為IT運維部副總裁的第一天表現並不太好。

2）鳳凰專案批鬥會

　　會議室裡大約有25個人。很多業務領域負責人都到場了，其中有些是莎拉的下屬，克里斯也在。

　　為了支援鳳凰專案，最近兩年他的團隊人數增加了50人，其中很多來自外包公司。克里斯經常被要求用更短的時間、更少的經費去完成並交付更多的產品。

　　史蒂夫坐在會議桌邊唯一一張空椅子的右側。

　　上週鳳凰專案第1階段 的關鍵路徑上有12項任務，目前只完成了其中的3項。會議室裡響起一片嘆息聲，好幾個人開始竊竊私語。

　　莎拉認為是比爾的團隊一直在拖後腿。分不清輕重緩急，不適應去支援這樣舉足輕重的專案。

　　莎拉繼續強調，已經為鳳凰專案投入了超過兩千萬美元，而且已經延遲了將近兩年。現在必須把鳳凰專案推向市場。

　　克里斯信口開河地確定了一個投產日期，全然不理會在部署之前比爾團隊需要做多少工作。

　　韋斯認為克里斯團隊的程式碼效能太差，部署的技術引數也不提供，測試環境無法搭建，並且必需的伺服器和網路裝置的交貨時間需要三週。

　　比爾見過類似場景，劇本很簡單，首先，接到一項緊急的日期驅動專案，對外承諾釋出日期不能延遲；然後，增添一大幫開發人員，用完了所有的進度時間，沒時間進行測試或運營部署；隨後，由於沒人願意錯過部署日期，開發部門之後接手的人只得不計後果地猛抄近路。

　　結果從來不理想。通常情況下，軟體產品實在太不穩定、太不可用，連那些曾經強烈要求這些產品的人最終也會說它不值得上市。到最後，總是IT運維部在通宵達旦地為那些糟糕的程式碼埋單，每隔一小時重啟一次伺服器。

　　莎拉指責比爾缺乏對於緊迫性的必要認知。追求完美是成事的大敵。當前需要建立正向現金流，如果不奪回市場份額，就無法做到這一點。而要奪回市場份額，就必須部署鳳凰。

　　在大家爭論不休時，史蒂夫最終說道，“我們已經向投資方和分析師們許諾過，會在本季度釋出鳳凰專案。”

　　莎拉駁斥了比爾的所有觀點，把史蒂夫引上了一條不計後果的毀滅之路。

　　史蒂夫最終敲定下週六為上線時間，鳳凰將在前一天下午5點部署。

3）人力資源問題

　　IT運維部有150名員工，平均每1.5人就有一個專案。大部分人力資源都流向了鳳凰項 目。審計合規修復是第二大專案。

　　第三大專案是事故及故障修復工作。目前為止，它佔用了員工大約75%的工作時間。由於這些工作常常涉及關鍵業務系統，所以事故處理的優先順序比包括鳳凰和審計發現修復在內的其他所有工作都要高。

　　幾乎每個人都難以完成他們的專案工作。即使有時間，他們也得盡力優先處理所有的工作任務。業務部門的人不斷要求我們的員工為他們辦事，尤其是市場部的人。

　　公司的所有管理人員幾乎都是直接去找他們喜歡的IT人員辦事，不是請人幫個忙，就是強迫他們做事。 

　　根據粗略估算，團隊可能需要多招7個人：3 個數據庫管理員、2個伺服器工程師、1個網路工程師，還有1個虛擬技術工程師。當然啦，找到這些人需要一定時間，上崗之後他們還要經過6~12個月的時間才能完全勝任工作。

　　在向史蒂夫提出招人時，他回答：“鳳凰專案已經超支一千萬美元，我們必須馬上得到正向現金流。你擁有全公司最昂貴的一些人力資源。只能好好使用現有的人手。”

　　他繼續說道：“我給你的建議是，去找你的同事提出充分的理由。如果理由確實合情合理，他們應該會願意轉讓一部分預算給你。不過我要說清楚：增加任何預算都是不可能的。如果說會有什麼調整的話，可能還得在你的部門裡減掉幾個人。”

4）布倫特

　　布倫特實際上並不像我們認為的那樣聰明絕頂。也可能他是個技術界的愛因斯坦，別指望能找得到和他同等水平的員工。還可能他是故意讓自己顯得無可或缺，以免其他人搶了他的工作。

　　布倫特看起來確實是在真心誠意地幫助所有依靠IT系統的人解決問題。但讓我失望的是，大家似乎都把他當作免費的私人極客電腦特工。這是以損害鳳凰專案為代價的。

　　比爾把專案管理會議上提到的五項任務拿給他看。他迅速地說：“這些我都已經完成一半了。只是需要有幾個小時不受打擾，安安靜靜地完成它們。假如可以的話，我會在家裡把這些做完的，但是網路連線太慢了。”

　　隨後比爾讓布倫特把每個向他求助的人都轉給韋斯，確保人力資源完成鳳凰專案的關鍵工作。

　　每一次讓布倫特處理某個別人誰都無法處理的修復工作，他就變得更加 聰明，而整個系統則變得更加蠢笨。現在得終止這種狀態。

　　可以建立一個3級工程師的人力資源庫，由他們處理流轉過來的工作，但是得把布倫特遮蔽在資源庫之外。這些3級工程師要負責完成所有故障的處理，而且他們應該是唯一能夠接近布倫特的人——在規定條件下。

　　如果想和布倫特討論，他們必須先得到韋斯或比爾的批准。他們要負責記錄學到的東西，永遠不準布倫特反覆解決同一個問 題。比爾每週都會逐項檢查這些問題，如果發現布倫特就同一個問題出手了兩次，3級工程師和布倫特都要受罰。

　　每解決一個問題，知識庫裡就會多一篇關於如何解決某個疑難雜症的文章，而且能夠實施修復的人會越來越多。

　　帕蒂說，“我會定義布倫特的新流程。很樂意通過你和韋斯去找布倫特解決問題。但我們怎麼才能勸阻物流部副總裁之類的人不再直接去找布倫特呢？”

　　比爾立刻回答：“誰要那麼做了，就把他們的名單收集起來，我還會給他們的上司打電話，讓他們不準再犯。然後我會讓史蒂夫知道，這些人都是怎麼幹擾鳳凰專案的。”

5）鳳凰上線

　　週五晚上7點30分，鳳凰部署工作如期啟動後的兩小時，進展並不順利。

　　IT運維團隊下午4點就在這裡全體集合，嚴陣以待。但無事可做， 因為克里斯的團隊沒有發出任何指令；他們一直除錯到最後一刻。

　　下午4點30分，威廉一陣風似地衝進了鳳凰作戰室，他暴跳如雷，因為沒人能在測試環境下執行所有的鳳凰程式碼。更糟糕的是，鳳凰為數不多正在執行的部分也沒能通過各項關鍵檢測。

　　幾分鐘前，有個開發人員居然走進來說：“看，在我的膝上型電腦上，它已經在運行了。這能有多難？”

　　韋斯開始罵髒話，兩個我們的工程師和三個威廉的工程師則開始仔細研究那個開發人員的膝上型電腦，設法弄明白它和測試環境有什麼不一樣。

　　威廉繼續說道：“我真的毫無頭緒。程式碼改得太快了，我們跟不上，鳳凰將在投產中炸燬。我和克里斯談過好幾次停止釋出的事，但他和莎拉完全壓我一頭。”

　　每次發現問題，重發一個新版本，要把所有東西都設定好並執行起來，大約需要半小時，然後執行冒煙測試又需要三小時。在那段時間裡，QA可能會從開發部那邊收到另外三個版本。

　　威廉相信每個人都得通宵加班了。並且真正的風險是，明天上午8點門店開始營業時，恐怕無法讓鳳凰運轉起來。那是個大問題。

　　比爾給史蒂夫、克里斯和莎拉發一封電子郵件，看看能否推 遲部署時間。

　　史蒂夫說：“要是你能說服莎拉推遲試執行，那我們就談談。否則的話，繼續努力吧。”

　　莎拉說：“每個人都做好了準備，唯獨你沒有。市場營銷、開發、專案管理等部門都全力以赴地撲在這個專案上。現在輪到你了。 我們必須繼續！”

　　與此同時，韋斯還帶來另一個壞訊息，鳳凰資料庫轉換要比原先設想慢上幾千倍。 幾小時前就應該完成轉換，但現在只完成了10%。也就是說，全部資料要到週二才能轉換好。

　　這會導致明天所有店內POS系統都會宕機，那就意味著門店的收銀機將無法工作。也就是說，得手動收銀，手動刷卡。

　　他繼續說：“我們找到了十五臺伺服器，但資料中心的機架上沒有足夠空間安置這些伺服器了。只得花大力氣重新佈線、搭架子，把各種垃圾移來移去。我們對虛擬化投入巨資，這本該避免此類麻煩。但是，開發部解決不了效能問題，卻歸咎於虛擬化。所以，只能把所有東西都挪回實體伺服器！”

　　到了週六下午2點，事態愈發不可收拾，糟糕程度不斷突破比爾原本以為的底線。

　　使用鳳凰網站的客戶抱怨，網站不是宕機就是慢到無法使用。在看過電視和報紙廣告後，所有原本興致勃勃嘗試新服務的客戶都開始抱怨IT大敗筆。

　　而那些成功線上訂購的客戶則在去門店提貨時才如夢初醒。那時大家才發現，鳳凰似乎會隨機丟失交易，其他情況下，它又會從客戶信用卡上划走兩倍乃至三倍的費用。

　　因為可能已無法保證銷售訂單資料的完整性，財務部的安憤怒地駕車趕了過來。現在她的團隊已經在走廊對面建立了另一間作戰室，接聽門店的來電，處理問題訂單。中午時分，數百名憤怒客戶的傳真從各門店發來，已經堆成了小山。

　　下午4點30分，比爾又收到一個壞訊息，推特上瘋傳鳳凰網站正在洩露客戶的信用卡號。他們甚至貼出了截圖。當你清空購物車時，會話崩潰，並顯示出上一個成功訂單的信用卡號。

　　到了週一，鳳凰危機已經演變成了一場公關醜聞。它上了所有技術網站的頭條新聞。

6）救火

　　那些救火的事情（計劃外的工作）代替了計劃內的工作，不論是專案工作還是變更工作。

　　埃瑞克說它是最具破壞性的一類工作。它不像其他型別的工作那樣，是真正意義上的“工作”。其他三類工作（業務專案，內部專案以及變更）都是出於需要而計劃去做的。

　　比爾想到了與埃瑞克的對話，立刻向他打電話取經。

　　埃瑞克說：“計劃外工作是恢復性工作，幾乎總是讓你遠離目標。因此，知道你的計劃外工作從何而來就顯得尤為重要。”

　　他認為比爾已經開始著手穩定工作環境了，已經開始視覺化管理IT運維部裡的半成品了，而且已經開始保護自己的約束點——布倫特了，還強化了一種嚴明紀律的工作氛圍。

　　在大多數工廠裡，總有那麼一小部分資源，不論是人、機器還是原材料，決定了整個系統的產出。將其稱之為約束點——或者瓶頸。

　　在建立起一個可信賴的系統用以管理通向約束點的工作流之前，約束點經常是被閒置的，也就是說，約束點可能在很大程度上未被充分利用。

　　那就意味著，沒有向業務部門交付全部的可用資源。也可能沒有還清技術債務，因此隨著時間的推移，遇到的問題和計劃外工作量會不斷增加。

　　高德拉特在《目標》裡描述了五個聚焦步驟，第一步是確認約束點。

　　第二步是利用約束點，確保不讓約束點浪費任何時間。永遠不要讓約束點遷就別的資源而乾等著，而是應該專注於 IT運維部對當前所需完成工作中優先順序最高的那一項。

　　第三步就是把約束點置於次要地位。

7）封版兩週

　　比爾提出IT運維部和開發部在兩週內不再接受新專案，並且除了與鳳凰相關的工作之外，停止IT運維部的其他所有工作。

　　兩週後一切照常，此舉的目標是提高整個系統的生產能力，不只是提高任務的完成數量。

　　韋斯說：“難道那不會讓我們中的大部分人閒得無聊、無事可幹嗎？那就是130個IT運維部的人乾坐著。那聽起來不是有點兒……浪費嗎？” 

　　埃瑞克嘲諷地笑了笑，說：“我來告訴你什麼是浪費。超過一千個變更卡在系統裡，看不到完成它們的方法，這聽起來怎麼樣？”

　　卡片數量一直在增加。如果那就是半成品，顯然增加的速度已經失控了。恐怕用不了幾周，那些卡片會堆到天花板上。

　　接下來一小時中大家達成的一致意見令人驚訝。IT運維部將會凍結所有和鳳凰無關的工作。開發部不能讓他們的二十多個與鳳凰無關的專案空轉，但他們會凍結所有部署工作。

　　換句話說，接下來兩週內，不會有工作從開發部流向IT運維部了。

　　此外，大家將確認最主要的技術債務，開發部會對其進行處理，以減少問題應用程式所產生的計劃外工作量。這些都會讓我團隊的工作負荷變得截然不同。

8）跨團隊協交接 

　　埃瑞克說過，等待時間取決於資源使用率。“等待時間是‘忙碌時間百分比’除以‘空閒時間百分比’。也就是說，如果一個資源的忙碌時間是50%，那麼它的空閒時間也是50%。等待時間就是50%除以50%，也就是一個時間單位，一個任務在處理前的排隊等待時間為一個小時。”

　　對這個鳳凰任務來說，假設有7個交接步驟，而且每一個資源都有90%的時間是忙碌的，那麼任務排隊等待的總時間就是9小時乘以7個步驟。

　　在一個部門內建立工作並確定其優先順序就很難，而管理多個部門之間的工作則是難上加難。

　　板上的每一張紙都像是這個鳳凰‘任務’。看起來似乎是一個單獨人員的任務，但實際上，它是需要在多個人員之間進行多次交接的多個步驟。難怪柯爾斯頓的專案時間預排都沒能兌現。

　　比爾補充道：“如果能夠把所有的經常性部署工作標準化，最終就能達到產品配置的一致性。現在的基礎架構過於多樣化，就像雪花一樣——沒有兩片重樣的。布倫特之所以會成為布倫特，是因為允許他建立起只有他能理解的基礎架構。”

　　部署就像是製造工廠裡的總裝配。每一條工作流都要經過它，而且缺了它你就不能發出產品。

　　帕蒂提出了一個新角色，兼有專案經理和稽查員的職能。讓所有已完成的工作都快速有效地交接到下一個工作中心。必要時，這個人要在工作中心等待，直到工作完成並運往下一個工作中心。

9）與業務人員的訪談

　　帕蒂和比爾將對業務流程負責人進行訪談，主題是“理解客戶的需求 與期望”、“產品系列”、“上市時間”以及“銷售渠道”。

　　今天是星期五，計劃訪談製造銷售部副總裁羅恩·約翰遜。

　　他認為差勁的‘瞭解客戶的需求和期望’影響了‘銷售預測準確率’。他還詳細地告訴我們，他手下的經理們想從客戶關係管理系統 （CRM）中拿到他們需要的報告有多困難。

　　他繼續說道：“在季末最後幾天電話不能用了，客戶沒法下訂單，或者作出臨時變更！這件事延誤了150萬美元的訂單，十個客戶重新評估了他們的合同，又有500萬美元的訂單岌岌可危。”

　　下次的訪談物件是瑪姬·李，她發起了鳳凰專案。她是超過一半IT專案的業務發起人。此外，瑪姬還負責保證每一家門店的貨品都儘可能地豐富多樣，她還負責確定公司的售貨類別和定價方針。

　　她總結道：“歸根結底，我對‘瞭解客戶的需求和期望’的衡量標準是，客戶是否會向朋友推薦我們。”

　　她繼續說道，“大多數時候，我們都在盲目行動。理想情況下，銷售資料會告訴我們客戶想要什麼。也許你認為，有了訂單輸入系統和庫存管理系統中的資料，就能做到這一點。但這些資料幾乎總是錯的。”

　　資料質量太差，因此無法憑藉這些資料來進行各種預測。現有的最佳資料，來自於兩月一次的門店經理訪談，以及一年兩次的核心客戶群訪談。

　　她希望從門店和線上渠道得到準確及時的訂單資訊。不用像現在這樣雜亂無章地運用這些資料。運用那些資料來設計市場推廣活動，不斷推出“A或B”產品選擇測試，以發現客戶認可的報價。一旦發現哪些有效，就能在全部客戶中複製推廣。這樣做就能為羅恩建立一個巨大的、可預測的銷售漏斗。

　　運用那些資訊來推進生產計劃，那樣就能管理供求曲線。讓正確的產品出現在正確的貨架上，並一直備好庫存。平均每客戶銷售額將會一路衝高，平均訂單金額也會上升。

　　帕蒂插話說：“你們把產品推向市場的合理時間是多久？”

　　她立刻回答：“現在？產品需要在六個月內上市。最多九個月。否則， 一些其他的公司就會剽竊我們的想法，讓產品出現在競爭對手的貨架上，並搶走大部分市場份額。”

　　在競爭的時代，遊戲規則就是‘快速上市，快速淘汰’。不能為推出一個產品而制定為期幾年的工作計劃，一直等到最後才弄清手上拿的牌是贏家還是輸家。而是需要短而快的週期，不斷整合來自市場的反饋。

　　迪克希望研發投入可以平均回報超過十個百分點。那是內部最低預期資本收益率。

　　九個月內向公司返回現金，這是最長時間了？而鳳凰上花了將近三年時間，依然尚未創造出期望的商業價值。也許致力於鳳凰專案是完全走錯了路。

　　接著，瑪姬描述了圍繞IT專案資源的激烈競爭。“我們的計劃週期是6~12個月。誰能知道自己三年以後應該做什麼專案？”

　　她說了一些想法，包括招聘更多IT人員，把一些IT人員專門劃撥給她的團隊，更多關注那些妨礙IT專案佇列的專案，等等。

　　離開瑪姬的辦公室後，帕蒂歡呼道，“我無法相信瑪姬和羅恩居然這麼沮喪。你能相信嗎，訂單輸入和庫存管理系統中的不可靠資料又出現了？我也不能相信，按照當前的設計，鳳凰實際上不能解決資料質量問題！”

　　三年多來，已經為鳳凰投入了兩千多萬美元。這個專案鎖住了那麼多半成品和資金，恐怕再也不能達到10%的內部最低預期資本收益率。 換句話說，鳳凰原本就不該被批准。

10）訪談後的應對處理

　　比爾在白板上畫了一張表格，其中有一列是“由於IT導致的業務風險”。

　　約翰說，“通過描述IT可能會出現哪些阻礙業務成果實現的問題，就能幫助業務流程負責人拿到他們的獎金。這應該會非常有說服力。業務部門也許還會為我們所做的事而感謝我們呢，那可是讓人耳目一新的改變。”

　　對於電話和MRP系統，很快確定，預測評估指標包括遵守變更管理流程、監督稽核生產變更、完成定期維護，以及排除所有已知單點故障。

　　但在處理“客戶的需求和期望”時遇到了困難。克里斯指出，“大部分問題是在上游產生的，因為市場營銷人員不斷輸入格式不正確的庫存量單位（Stock Keeping Unit，以下簡稱SKU）。市場營銷部也得解決他們的問題。”

　　對於“市場營銷的需求和期望”，我們提出的評估指標包括鳳凰支援每週報告並且最終支援每日報告的能力，市場營銷部生成的有效SKU比例，等等。

　　迪克在看好演示後說道：“比爾，你是說，公司裡每一個人都在做每一件正確的事，但因為這些IT問題，我們大家還是不能完成目標？”

　　“是的，先生。”比爾說，“和其他業務風險一樣，由IT引起的運營風險也應該得到管理。換句說話，由IT引起的運營風險不是IT風險，而是業務風險。”

　　然後他問：“好吧，你有什麼建議？我想你已經想好一個建議了吧？”

　　比爾開始推銷自己的想法，“我想用三個星期的時間，逐一會見那張電子表格上的每一位業務流程負責人。我們需要更好地定義由IT引發的業務風險，並且達成共識，然後向你提出把那些風險納入主要業績指標的辦法。我們的目標不只是提高經營業績，還要對能否達成目標提供前瞻性指標，那樣我們就能採取適當的行動了。”

　　比爾繼續說：“我們的進展太慢了，還有那麼多半成品和功能吊在半當中。我們應該把釋出變小變短，更快地回籠資金，那樣才能達到內部最低預期資本回收率。克里斯和我有一些想法，但是會和公司現行的既定計劃大不相同。”

　　他保持沉默。然後果斷地宣佈：“你的兩個提議我都同意。我會派安去幫助你。你需要公司裡最優秀的人才。”

　　星期五，約翰召集韋斯、帕蒂和比爾開了個會，為了將與安全性相關的工作量減少75%，他提出了五條建議。

　　第一條建議是大幅度縮減SOX-404合規專案的範圍。

　　第二條建議是要求技術部弄清楚生產薄弱點一開始是如何產生的，並要求調整部署流程，杜絕此類情況再次發生。

　　第三條建議是要求在帕蒂的變更管理流程中，標記出所有列入合規審計範圍的系統——那樣就能避免可能危及審計工作的變更—並要求建立持續記錄文件，今後審計師會要求提供這些文件。

　　第四條建議是通過清除所有儲存或處理持卡人資料的東西，來縮減PCI合規專案規模，從銷售系統裡那個該死的自助餐廳銷售點著手。

　　第五條建議是用前幾條建議所節省下來的時間，來償還鳳凰的所有技術債務。

11）又一次鳳凰部署

　　按時完成了所有的應交付成果，不過和往常一樣，依然有數不清的細節問題需要研究。

　　目前已經穩定了基礎架構。一旦真的發生難以避免的服務中斷和事故，大家就像一臺執行良好的機器一樣運作起來。大家已建立起部落文化般的工作共識，這幫助大家比以往任何時候都能夠更快地排除故障，而且，一旦真的需要把工作升級，也是可控而有序的。

　　由於不斷提高對基礎架構和應用程式的產品監控，大家常常在業務部門察覺之前就知道了事故的情況。

　　已經減少了專案積壓，一部分是通過剔除序列中的無用專案來實現的。約翰已經完成了這件事。大家已經從審計準備和整改工作中削減了很多不必要的安全專案，代之以團隊全員幫助實施的預防性安全專案。

　　通過調整開發和部署流程，以一種有意義的、系統化的方式，加固並保護了應用程式和生產基礎設施。而且，大家的信心不斷增加，這些缺陷今後再也不會發生了。

　　變更管理會議比以往更加順利，也更有規律。大家不僅能瞭解團隊正在做什麼，還能瞭解工作確實在不斷推進。

　　大家比以往更加明白，自己應該做哪些事。員工從故障修復中獲得了成就感。

　　改進的不只是布倫特的工作。通過減少懸而未定的專案數量，讓工作流轉的通路保持通暢，那樣，工作就能從一個工作中心快速移到另一個工作中心，並以打破紀錄的速度完成。

　　埃瑞克說，“我們正在制止工作缺 陷交接至下游工作中心，我們正在管理工作流，運用約束點來控制節奏，而且我們以審計部門和迪克那裡拿到的結果為依據，比以往更好地理解了哪些是重要的工作，哪些不是。”

　　最終，比爾主導發起了回顧小結環節，對我們自身的工作開展情況以及需要改進的方面進行自我評估。

　　訓練讓偉大的團隊達成最優表現。對任何流程或技能來說，訓練成習慣，習慣成精通。

　　約翰很快獲得了迪克和史蒂夫的批准，找一個外包商接管自助餐廳POS 系統，並將其替換成具有商業支撐的體系。

12）特戰隊

　　威廉走到白板前開始畫方框，一邊畫一邊講解那些步驟。接下來的十分鐘裡，他證明了一共有一百多個步驟，包括在開發環境下執行的自動測試、建立與開發相吻合的QA環境、朝其中部署程式碼、執行所有測試、部署並移至與QA相吻合的新模擬環境、負載測試，最後再把接力棒傳給IT運維部。

　　威廉弄完後，白板上有了三十個方框。

　　布倫特站起身來，開始畫方框，這些方框表示要部署的程式碼包，準備新的伺服器例項，載入並配置作業系統、資料庫及應用程式，對網路、防火牆及負載平衡器開展各種變更，隨後進行測試，確保部署大功告成。

　　有無數的配置需要正確地設定，系統要有足夠的記憶體，所有檔案都要安裝到正確的位置，所有程式碼和整個環境也需要正確地操作。

　　哪怕是一個小小的失誤就能讓一切崩塌。這顯然意味著，大家應該比生產製造領域更加嚴格，更守紀律，更有規劃性 。

　　帕蒂指出：“在現有流程下，有兩個問題不斷出現： 在部署流程的每個階段，在我們需要的時候，部署環境卻總是沒有就緒，即使已經準備就緒了，也需要大量返工才能讓它們彼此同步。”

　　她繼續說：“返工和準備時間過長問題的另一個顯著來源是程式碼打包流 程，在此階段，IT運維部對經過開發部檢查的內容進行版本控制，然後生成部署包。儘管克里斯和他的團隊儘可能地記錄程式碼和配置，總還有東西會遺漏，這些東西只有在部署之後，程式碼無法在環境中執行時才會被發現。”

　　比爾問道，“布倫特，我們要怎麼做才能建立一個通用環境建立流程，從而在同一時刻同時構建開發、QA和生產環境，並讓它們保持同步？”

　　他站起身來，畫了三個方框，分 別叫作“開發”、“QA”和“生產”。然後他在它們下方畫了另一個叫作“構建過程”的方框，這個方框有三個箭頭，分別指向上方的三個方框。

　　比爾對克里斯說：“這看起來很有希望。如果能把環境標準化，並把這些環境投入開發部、QA和IT運維部的日常使用，我們就能消除大部分在部署流程中因差異而導致的悲劇。” 

　　帕蒂看著畫滿方框的第一塊白板說：“如果我們重新設計流程，就需要讓正確的人員事先介入。這就像是製造工程組確保所有零部件都設計得有利於生產，而生產線也規劃得有利於零部件的流轉，理想狀態下達到單一工作流。”

　　威廉走到白板前，指著一個名叫“程式碼提交”的方框說：“我會改變這個步驟。不再通過原始碼控制從開發部獲得原始碼或編譯程式碼，而是希望拿到準備部署的打包好的程式碼。”

　　他繼續說，“我迫切地想要這樣的程式碼包，我很樂意主動接管建立包。我也完全知道應該派誰去做這件事。她將負責開發交接。 一旦程式碼被標記為‘準備測試’，我們就要生成並提交程式碼包，那會觸發一個QA環境的自動部署。今後，也許連生產環境也能自動部署。”

　　未完待續.......

&n