業務創新取決于支撐企業的軟件，像優步和Airbnb這種擁有顛覆性創意的新創企業才得以與歷史悠久的大企業和行業展開競爭，所有這一切都要依賴于創意和軟件的力量。然而，傳統企業的IT部門還在努力按業務發展所需的速度進行交付。很少聽到業務部門的領導說：“我們的IT團隊響應力極強且非常迅速。” 因為IT部門通常被視為業務創新的瓶頸。在許多企業中，業務部門盡量避免和IT部門打交道，而是創建某種形式的影子IT。

傳統的IT治理

DevOps原則和實踐讓更快交付和更高質量成為可能。然而，最大障礙來源之一卻是注重IT項目和項目治理的的傳統。

一個項目可能意味著一大筆投資，有限的資源迫使企業負責人謹慎地對“應批準哪些創意和計劃”進行排序和規劃。但無論是多么周密的打算，這種治理方式也無法滿足創意經濟時代所需要的速度。

事實上，IT部門運作機能失調，如需求過度、各部分部署脫節和質量問題，往往由傳統的投資組合規劃和項目管理方式所造成。從用戶案例和需求管理角度出發。在由項目驅動的傳統世界中，項目是一次性商機，企業往往會在其用戶案例中得到一份詳盡的“必備”功能清單。

然而，這會從一開始就帶來技術債務和更多復雜性，特別是考慮到實際上只有一小部分“必備” 功能會被真正用到。最近一項調查顯示，高達45%的軟件功能經常是閑置的。從衡量項目是否成功的標準出發，項目團隊的評估指標通常包括是否能夠按時、按預算交付的能力，和其他各種質量和滿意度指標。而最后期限和成本的壓力可能會迫使企業作次優選擇。

因此，隨著進度被壓縮，測試往往也會被縮略，以實現按時交付。這經常會導致產品發布時有缺陷——服務臺不得不處理爛攤子，最終會降低信任度和團隊合作精神。項目完成之后，項目團隊往往會依據對具體技能的需求，被重新分配到其它項目上。那么積累的團隊知識和智慧則會被丟棄，因為團隊已解散，所以也沒有進一步的措施來激勵自動化投資或進行流程優化。

DevOps轉變

DevOps 是一種非常不同的方案，它要求重新思考工作是如何被資助和治理的。從根本上來說，DevOps團隊負責快速交付小型且高質量的版本。團隊獲得快速反饋，以消除瓶頸和浪費，并利用不間斷的自動化讓任務變得可重復且高效。

鑒于團隊每年將交付至少十幾個版本，它的獎勵方式也不同于傳統的“項目”團隊。DevOps團隊往往在開發、測試和生產過程中就“擁有”應用，并對其價值共同承擔責任。團隊減少了組員交接和任務耽擱，通過頻繁的微小變動來管理業務需求、客戶反饋和系統性能。

傳統IT治理的困難需要用DevOps來克服。其中一個方式就是轉變模式——把上述描述中的項目轉為產品。關鍵是要重視價值和業務成果，以及員工和客戶的滿意度。關鍵區別在于：為產品融資是一項長期工作，且產品團隊能夠提供持續價值及業務改進，企業可依靠這些來滿足需求。

我們的客戶正在探索如何把傳統的項目的概念演進為長期的產品導向。一些企業明確改良了產品，而另一些企業則采取更加優化的方式。無論采用哪種方法，發展融資模式的需求都是顯而易見的。

產品治理與項目監管的不同之處在于，產品團隊與業務團隊合作，會得到長期的融資：一年、半年、或一個季度，具體情況取決于業務需求。隨后產品團隊會迅速交付業務驅動型創新版本，并根據持續的產品評估反饋來快速更新系統。

由于團隊仍然完整，它才能夠學習、改進，同時加快交付。此外，因為產品團隊能夠迅速交付， “可有可無”的功能負載才大大降低。

這并不意味著未來不會有項目團隊，但是在大型企業中，將會出現產品和項目團隊的組合。事實上，我們有望看到項目轉變成一種能在創意經濟中，針對業務成功提出、評估、構思新產品的方式。

本文作者：李時，Hewlett Packard Enterprise 中國區副總裁，軟件集團總經理