現在是時候面對一個冷酷的事實：你的IT部門太慢了。這是好的意圖產生的不好的結果，但在業務中，意圖并不重要。
IT什么時候會變得很慢?每當業務的任何部分都要等待IT交付貨物時，那就是很慢的時候。如今的神奇行話可能是“創造價值的時間”，但真正的指導原則是“超越競爭對手”。如果IT沒有做到這個，你可以確信組織的業務主管已經失去了對你的耐心。
想加速你的IT部門嗎?首先要擺脫一些使其減速的東西——說白了就是瓶頸。以下十二個地方就是你的著眼點。忽略了你就要承擔風險。
IT瓶頸之一：治理
委員會是老式治理方法。由于治理對IT所做的一切起到帶頭作用，委員會減緩了他們所接觸的一切事宜，盡管你嘗盡了各種方法，但將委員會作為治理的核心將使IT蝸速前行。
就大小而論。每增加一個委員就會減緩決定;超過五個成員進展就會慢如爬行，因為達成共識的可能性蕩然無存了。
如果委員們認為自己不是信息技術領導者，而是選區的代表，不然就不會得到公平的份額，那么情況就會更糟。這種委員會將會一直爭論不休，而不是解決共同的問題。
然后還有會議日程安排。速度節拍器為委員會管理的每一個項目樹立了榜樣。如果一個委員會一個月才開一次會，那么等待決定的任何事情都等待一個月。你正在進行的項目有多少可能會遇到這樣的瓶頸?
如何解決這個問題?使文化成為新的治理。將其視為道路上的車道標志，將指導委員會降級為護欄的角色——當所有其它方面都失敗時，還有他們來使IT不會陷入深淵，而只有當所有其它方面都失敗時不得已而為之。
讓文化擔起重任。如果每個人都明白什么是最重要的并關注它，那么大多數治理是多余的。
IT瓶頸之二：多任務
員工的多任務處理有一個簡單的規則：別這么做!
對于軟件開發項目尤其如此，研究表明，每次中斷都會造成開發人員的生產力下降15分鐘。但是，對于應用程序開發來說為真的，對IT人員必須集中精力的其它所有情況也是如此。
挑戰并不在于知道你必須避免多任務;而是如何避免它。答案就在企業項目管理辦公室。它應該有一個不可侵犯的規則：所有項目都必須人手充足，否則不能啟動。
什么是人手充足的項目?一個從來不必等到某個團隊成員可用的項目。將并發項目的數量限制在可以完全配備的人數上，那么團隊成員就不必多任務。
結果：每個項目不僅完成得更快，而且整個項目組合將會更快完成。
IT瓶頸之三：項目
傳統上，組織通過項目實現新技術。設計越復雜，項目越大。但是隨著項目越來越大，當產生實質性延遲的可能性近乎必然時，故障的風險也呈幾何級數增加。
考慮將你的努力整理成發布版本。發布版本將離散的功能增強捆綁起來用于回歸、壓力測試和部署。依靠發布版本而不是項目，你可以利用IT管理的最可靠的啟發式方法之一：功能增強成功了，而項目失敗了。
順便說一下，如果你走這條路，你不必把它描述為任何激進的東西。你可以稱之為scrum，享受它的一路陪伴。
不要停在那里。將開發工作納入發布版本仍然會造成延誤。典型的scrum沖刺是一個月的時間，這為每個業務變化建立了一個每月速度，不包括必須等待變更咨詢委員會(CAB)的會議(另一個治理委員會)。
所以始終貫徹持續整合和部署——一言蔽之即devops。將測試自動化，將每個軟件變更進行持續整合，并立即將每一個微小的變更投入生產。有了如此微小的變更，CAB是多余的。
畢竟，一個錯置的逗號會導致某物爆炸的時代已經遠離我們而去。
IT瓶頸之四：手動配置
開發團隊可以在幾分鐘左右的時間在云中配置完整的環境，或者可以在幾個月左右的時間對IT操作進行相同的環境要求。
這不是內在的限制。這是一個選擇。分鐘比幾個月短，由于公共云提供商已經完善了該技術，更好的選擇昭然若揭。
啟用自動化，并授權開發人員自己處理配置。
IT瓶頸之五：偏愛借口勝過集成
新功能創造新價值。但是在大多數IT工場中，新功能在確保軟件更改不會破壞公司的自定義編程的點對點批量接口的蜘蛛網(或毛球)方面處于次要位置。
用精心設計的集成系統清理接口混亂，項目團隊加快速度，測試所需的時間更短，部署更加順利。
然后再進一步：將“信息技術”變成“集成系統”，其工作是通過標準API提供對公司核心應用程序組合的可靠訪問，這些API將數據和功能公開為安全，定義明確的服務。
IT瓶頸之六：抑制影子IT
陰影IT——即業務部門部署的系統——會導致問題。尤其是，有了影子IT，建立在破舊基礎上的局部自動化是規則，而不是例外。
但影子IT忠實地做著業務需要的事情。而且它不必等IT治理流程開綠燈，所以它可以提供業務現在的需求。
把它看作是外包應用程序團隊的一個免費資源，這些團隊擁有聰明的業務分析師，但他們是糟糕的架構師。
照亮陰影IT。給它一點支持，而不是試圖杜絕它。作為交換，即使在計算使用符合IT隱喻建筑規范的隱喻管道和布線來重構其設計所需的努力之后，您也可以增加帶寬。
如果你將IT變成集成系統，你也可以將該API提供給公司的影子IT團隊，同時解決局部自動化問題。
IT瓶頸之七：堅持100%的解決方案
IT的本能就是使一切防彈。但是為一個每隔1000次交易就攻擊系統的案例編寫代碼所需的時間和為一天發生幾百次的案例編寫代碼是一樣的。
從IT的久遠年代汲取的教訓是：為主要的案例編程，并將其余作為手工處理的例外。
電腦擅長主要案例。人類善于例外。
IT瓶頸之八：創建數據倉庫
選擇一個字兒來描述典型的數據倉庫項目，它可能會是“晚點”。
好吧，這是兩個字兒。告我吧。但數據倉庫由于難以設計OLAP數據結構而總是慢一拍，這些數據結構被優化來回答他們現在要問的問題而沒有人知道他們會問出這樣的問題。
輸入NoSQL。使NoSQL有趣的不僅僅是它處理大數據量的能力。更有價值的是它現在可以接受數據的能力，當以后要查詢組織形式時，NoSQL還可以讓分析師弄清楚其組織形式。
相比之下，讓Hadoop疾速實現的正是這種“按需模式”的質量。
IT瓶頸第之九：強調TCO
你的決策者是否忘記成本會帶來好處?
瞧，任何一個笨蛋都可以削減成本。訣竅在于削減成本而不損害交付。這就是總體擁有成本(TCO)發揮作用的地方，而且沒有發揮好的作用。
除了打消人們對功能的念頭，TCO并不關心功能。畢竟，降低成本的最簡單的方法是提供和支持功能較弱或不太得力的東西。少用=較低成本。
因為不可侵犯的其中一條指標規則而強調TCO，這是不可避免地會發生的事情：你不會去測量任何你得不到的東西。這包括IT所能創造的價值。
此外，如果每個人的關注點都是降低成本，那么就沒有人會專注于加快速度。如果速度不是優先事項——遑論本該有的優先事項——速度根本不會產生。
IT瓶頸之十：迫使創新者進入“高保真”IT架構
企業過去常常堅持與昨天一樣的明天。他們要求防彈，永不丟失數據并始終提供正確的答案的“高保真”系統，。
現在，創新與防彈一樣重要。這是未來;這就是競爭優勢產生的地方?
不要強迫創新者——例如影子IT——進入“高保真”IT架構。當創新者弄清楚事情并使未來發生時，給他們一個屬于自己的隔離空間。只要他們成功了就有足夠的時間來使他們的創新高保真。
IT瓶頸之十一：允許自滿的文化
即使經營良好的IT工場也可能會過時，特別是那些當有人嘗試創新事物而未果“對人們問責”而不是恭喜他們承擔風險的的公司。
自滿的文化放慢了運營，因為沒有人認為有必要加快速度。畢竟，這就是我們在這里的慣常做事方式。
如果這就是你所擁有的文化，那就努力改變現狀。另一個選擇就是無聊至死。
IT瓶頸之十二：建立疏遠的業務/ IT關系
你認為哪些可以更快地給出結果：疏遠的形式，其中IT“協商”服務水平協議，同時要求其業務“客戶”“批準需求和規范”，或以“你試圖完成什么，我們怎樣才能幫上忙?”開始的非正式對話，
很多專家將正式方法稱為“最佳實踐”。忽略它們吧。采用超最佳實踐。培養強有力的非正式關系，絕不談判。
為什么呢?因為談判是針對坐在桌子對面的人。
理論上，IT和其它業務處在同一立場——難道不是嗎?
京公網安備 11010502049343號