作為CIO，你所做的很多事情都是設(shè)計東西，這個時候你就不會去監(jiān)督其他設(shè)計東西的人，或者，這個時候你就不會去確定每個人設(shè)計的東西是否按照應(yīng)有的方式組合在一起。

無論設(shè)計什么，都有一些通用的規(guī)則來管理好的設(shè)計。最著名的可能就是一句來自偉大建筑師路易斯·沙利文的格言，即形式服從功能，而鮮為人知但同樣重要的一句話來自愛德華茲·戴明：要優(yōu)化整體，我們就必須對部分進行次優(yōu)化。

無論設(shè)計什么，是小工具、軟件、組織還是流程，這都很重要，而且這也就可以理解為什么這么多CIO在優(yōu)化上犯了錯。

從隊列到隊列：隱藏的進程瓶頸

如果CIO可以靠一技之長謀生的話，那也許就是流程優(yōu)化了。這對IT發(fā)揮自己的作用來說至關(guān)重要，而且IT所做的很多工作也都是為了幫助業(yè)務(wù)經(jīng)理優(yōu)化他們的流程。

IT內(nèi)部和外部的流程優(yōu)化人員擁有豐富的框架和方法可以使用，其中精益（Lean）方法是最受歡迎的，所以讓我們用這個方法來舉例。

精益思想對于流程優(yōu)化做出的最重要、但最不被認可的貢獻，可能就是認為：流程不是從一個盒子流到下一個盒子、再到下一個盒子的任務(wù)集合。

相反，流程是從隊列到隊列、再到隊列的任務(wù)，這其中的差別看起來可能是很細微的，但卻是優(yōu)化整體與優(yōu)化整體部分導(dǎo)致不同的結(jié)果的原因之一。這聽起來似乎很學(xué)術(shù)，或者是某種IT禪理，但了解這其中的差異就是掌握流程優(yōu)化的一個關(guān)鍵。

想象一下，你正在管理一個項目，這個項目需要新的服務(wù)器才能繼續(xù)進行下去，假設(shè)目前IT還沒有完全云化并且仍然有服務(wù)器和數(shù)據(jù)中，你按照程序發(fā)送請求到IT請求隊列。

稍微簡化一下如下圖所示：

這是一個簡單的流程。負責(zé)每個步驟的團隊很久以前就優(yōu)化了處理其職責(zé)的程序，總工作量和流程周期時間是相同的——對于這個假設(shè)的例子來說，大約需要8小時，或者項目計劃表上的一天時間。

但是用上面這種盒型圖展現(xiàn)這個流程是錯誤的，實際流程看起來更像下面這個：

流程中的每個步驟都作為先進先出(FIFO)隊列進行管理，只有當請求流經(jīng)隊列并彈出以進行處理時，團隊才會處理請求?？偣ぷ髁颗c盒型圖中預(yù)估是是相同的，但是周期時間包括了工作時間和排隊時間——對于這個模型化的流程來說，大約需要5天。

實際分析要比這個更復(fù)雜。通常，某一個步驟最終會變成瓶頸。隊列中的工作量堆積起來，而其他隊列卻閑置著，被接收了來自多個來源請求的所有隊列抵消。但原理是不變的，改變的只是模型的復(fù)雜性。

這是真實的，而不僅僅是理論。就在幾年前，一個客戶的隊列大小比上面描述的還要長得多，因為他們的團隊等待著上級批準他們安裝所需的服務(wù)器，因此遭遇了長達數(shù)月的項目延遲，即便是一臺普通的服務(wù)器，需要花費在采購、配置和安裝上的精力也并不比上圖描述的少。

根本原因是什么呢？負責(zé)采購、網(wǎng)絡(luò)管理、軟件安裝、質(zhì)量保證和部署的經(jīng)理們都把他們部門工作進行了梳理，以最大限度地提高員工利用率和吞吐量。

他們優(yōu)化了自己這部分，但卻是以犧牲每個項目的整體為代價的。

消除外部因素

對于DevOps擁護者來說，他們能夠立即認可并接受的解決方案，就是把IT基礎(chǔ)設(shè)施分析師納入核心項目團隊，更重要的是，把基礎(chǔ)設(shè)施任務(wù)（例如配置服務(wù)器）納入到每個項目的工作計劃表中，根據(jù)產(chǎn)品需要設(shè)定開始日期和截止日期。

這樣改變之后，服務(wù)器構(gòu)建就變成了項目計劃的一個組成部分，而不是項目經(jīng)理無法控制的外部因素。

作為交換，CIO必須接受，如果項目要在預(yù)算范圍內(nèi)按時交付的話，IT組織的其他成員在工作管理上可能會有所松懈。員工利用率目標不會也不應(yīng)該接近100%。（專業(yè)提示：花一些時間研究Eliyahu Goldratt的關(guān)鍵鏈項目管理方法，可更深入地了解這一點。）

MBO的崩潰

優(yōu)化/次優(yōu)化的問題不僅僅適用于流程設(shè)計，以管理層薪酬為例。

過去，目標管理(MBO)是一種主流的理論，即如何通過充分利用組織中的每一位經(jīng)理來充分利用整個組織，該理論的致命缺陷在于，未能認識到以犧牲整體為代價來優(yōu)化部分的會導(dǎo)致不可避免、但意想不到的后果。

MBO的工作原理（或者說失敗原理更準確）顧名思義，公司高管為每位經(jīng)理分配了一個或多個目標。因為任務(wù)更加清晰了，所以他們開始以偏執(zhí)的熱情去完成這些目標，而不理會組織內(nèi)部其他任何經(jīng)理需要完成哪些目標。

現(xiàn)代組織因為無法相互協(xié)作而遭受所謂“孤島思維”之苦，這就是MBO時代的余毒。

給服務(wù)臺提供無效幫助

正如有人曾經(jīng)說的（實際上每個經(jīng)理在談到這個話題時都會這么說），沒有完美的組織結(jié)構(gòu)圖。戴明提出的優(yōu)化/次優(yōu)化原則是導(dǎo)致組織結(jié)構(gòu)圖存在缺陷的一個關(guān)鍵因素。

以典型的服務(wù)臺和服務(wù)臺在IT組織設(shè)計中所處的位置為例。服務(wù)臺會針對第一次最終用戶聯(lián)系和服務(wù)臺第一次做出響應(yīng)之間的延遲設(shè)置服務(wù)級別目標，以及針對解決最終用戶問題所需時間設(shè)置目標，有時候還會針對每次事件最小化成本設(shè)置一個目標。

考慮到處理每個報告的事件包括記錄該事件所花費的時間，以及嘗試解決事件所花費的時間，或者將其交給不同IT團隊來處理事件所花費的時間。

服務(wù)臺達到初始響應(yīng)服務(wù)水平一個最簡單的方法，就在初始響應(yīng)期間盡可能少做，盡可能快地處理每個事件。這讓服務(wù)臺的分析員可以自由地接聽下一個電話，而不會纏身于試圖解決他們無法解決的問題中。或者，通過把問題導(dǎo)向給更專業(yè)的部門，相比服務(wù)臺分析員試圖自行解決來說，事件可以得到更快速的解決。

但是，這種方法卻讓服務(wù)臺分析員永遠無法學(xué)會下一次遇到類似問題該如何處理。雖然服務(wù)臺的成本降低了，但代價是分散了高價人才對當前優(yōu)先事項的注意力，從整體價值的角度來看，這些優(yōu)先事項可能更重要。

優(yōu)化服務(wù)臺最終導(dǎo)致成本不受約束和責(zé)任轉(zhuǎn)移。事件管理的總成本與服務(wù)臺自身成本的降低是成正比的。

要優(yōu)化整體，你就必須對部分進行次優(yōu)化。這聽起來可能并不具體也不務(wù)實，但你不要因此望而卻步。如果你想要得到最好的結(jié)果，就要確保參與交付的每個人都知道他們應(yīng)該扮演什么角色。

而且，沒有人會因為合作而受到懲罰的。