對(duì)于企業(yè)組織來(lái)說(shuō)重要的是在數(shù)字化浪潮下如何生存和發(fā)展，那些無(wú)法適應(yīng)的企業(yè)將就此沉淪。同樣，每一次浪潮都是一個(gè)新陳代謝的機(jī)會(huì)，這不是制造焦慮。處于這樣的大時(shí)代，在這樣的洪流中，我們別無(wú)選擇，只有加入其中，成為數(shù)字化時(shí)代的弄潮兒。 理解、應(yīng)用和駕馭數(shù)字化的力量——弄潮數(shù)字化時(shí)代 數(shù)字化是一個(gè)巨大的力量，為了弄潮數(shù)字化時(shí)代，我們需要做到3點(diǎn)： 1）理解數(shù)字化力量：理解它怎么發(fā)生作用，怎么影響我們的業(yè)務(wù)，也就是認(rèn)識(shí)數(shù)字化的本質(zhì)。 2）應(yīng)用數(shù)字化力量：就是在理解的基礎(chǔ)上，把它應(yīng)用于我們的業(yè)務(wù)中，實(shí)現(xiàn)業(yè)務(wù)的數(shù)字化轉(zhuǎn)型。 3）駕馭數(shù)字化力量：我們組織必須變革，技術(shù)和業(yè)務(wù)協(xié)同方式必須發(fā)生變革，這樣才能保證業(yè)務(wù)數(shù)字化轉(zhuǎn)型的開(kāi)展。理解、應(yīng)用和駕馭數(shù)字化的力量，弄潮數(shù)字化時(shí)代，這是一個(gè)很大的主題——時(shí)代的主題。 BizDevOps是什么？ BizDevOps 是關(guān)于在數(shù)字化時(shí)代業(yè)務(wù)和技術(shù)如何高效協(xié)同的實(shí)踐、方法和理念。其中Biz是業(yè)務(wù)，Dev和Ops是技術(shù)。業(yè)技協(xié)同是 BizDevOps 的核心，也是駕馭數(shù)字化力量的關(guān)鍵。 我們首先回顧一下業(yè)務(wù)和技術(shù)這兩者之間的關(guān)系的演變歷史。 從早期信息化到今天的數(shù)字化過(guò)程中，業(yè)務(wù)和技術(shù)之間的關(guān)系一直在變化，我們說(shuō)的是IT技術(shù)。在工業(yè)化時(shí)代，技術(shù)和業(yè)務(wù)的關(guān)系是相對(duì)獨(dú)立的。業(yè)務(wù)的需求是明確的——支撐現(xiàn)有的業(yè)務(wù)，改進(jìn)它的運(yùn)營(yíng)效率。所以技術(shù)是支撐者，改進(jìn)既有業(yè)務(wù)的運(yùn)行效率。技術(shù)是支撐業(yè)務(wù)，業(yè)務(wù)的需求是明確的，只不過(guò)要把他分析和整理出來(lái)。在那個(gè)時(shí)代 CMMI、結(jié)構(gòu)化工程是較為適合的方法。 到了互聯(lián)網(wǎng)時(shí)代，發(fā)生了一些變化。技術(shù)和業(yè)務(wù)開(kāi)始融合，它們的邊界變得模糊，互聯(lián)網(wǎng)技術(shù)與業(yè)務(wù)相結(jié)合，拓展了新的商業(yè)模式。社交、電商、互聯(lián)網(wǎng)娛樂(lè)等都是那個(gè)時(shí)代產(chǎn)生的，它們是新的商業(yè)，但沒(méi)有技術(shù)賦能，這些商業(yè)也不會(huì)產(chǎn)出。 到了數(shù)字化時(shí)代發(fā)生了更根本的變化。數(shù)字化技術(shù)已經(jīng)成為我們今天一切業(yè)務(wù)的內(nèi)核，業(yè)務(wù)、甚至包括非常傳統(tǒng)的業(yè)務(wù)，都要運(yùn)行在IT系統(tǒng)之上。任何業(yè)務(wù)的價(jià)值交付、業(yè)務(wù)創(chuàng)新都要以數(shù)字化產(chǎn)品為支撐，技術(shù)已經(jīng)成為業(yè)務(wù)的內(nèi)核了。 在與企業(yè)經(jīng)營(yíng)上，業(yè)務(wù)和技術(shù)已經(jīng)不可分割，甚至技術(shù)成為業(yè)務(wù)的內(nèi)核。 然而，回到組織內(nèi)部，業(yè)務(wù)和技術(shù)的協(xié)作關(guān)系是什么樣子的呢？前幾年，整個(gè)行業(yè)在DevOps 浪潮中有很多積累和發(fā)展，讓技術(shù)內(nèi)部的價(jià)值交付變得更順暢了。 在 DevOps 的旗幟上，我們也試圖去突破做技術(shù)組織和業(yè)務(wù)之間的分離。不能說(shuō)沒(méi)有突破，但毫無(wú)疑問(wèn)，他們今天還沒(méi)有做到很好的融合，不管在組織上，流程上還是實(shí)踐上，業(yè)務(wù)和技術(shù)都還是分離的。這已經(jīng)成為業(yè)務(wù)交付和創(chuàng)新的關(guān)鍵堵點(diǎn)。 現(xiàn)實(shí)中，數(shù)字業(yè)務(wù)的創(chuàng)新與發(fā)展，要求業(yè)務(wù)和技術(shù)不斷融合；而在組織和機(jī)制上業(yè)務(wù)和技術(shù)依然相互割裂。這已成為我們駕馭數(shù)字化力量的核心矛盾。 BizDevOps 要解決的正是這一核心矛盾，它的目的是：打造業(yè)務(wù)和技術(shù)有機(jī)融合的數(shù)字化組織，賦能數(shù)字業(yè)務(wù)持續(xù)創(chuàng)新和長(zhǎng)期發(fā)展。 BizDevOps是為數(shù)字化時(shí)代服務(wù)的，數(shù)字化時(shí)代需要這樣的變革。我們業(yè)務(wù)需要數(shù)字化轉(zhuǎn)型，組織同樣需要數(shù)字化轉(zhuǎn)型，技術(shù)和業(yè)務(wù)是我們組織中兩個(gè)最核心的職能。 我們認(rèn)為成功數(shù)字化轉(zhuǎn)型應(yīng)該是蝶變的過(guò)程，化繭成蝶后機(jī)體還是過(guò)去的機(jī)體，但具有了超越的能力。我們今天做 DevOps，改變效能，提高交付能力。但站在組織數(shù)字化角度，組織的數(shù)字化轉(zhuǎn)型還停留在內(nèi)部，比如說(shuō)技術(shù)職能內(nèi)部，而沒(méi)有改變面向客戶(hù)的交付模式，我們得到的不過(guò)是一調(diào)爬得更快的毛毛蟲(chóng)。 BizDevOps，要面向客戶(hù)，改變技術(shù)與業(yè)務(wù)的協(xié)同方式，改變業(yè)務(wù)創(chuàng)新、業(yè)務(wù)交付模式，它必然是一個(gè)蝶變的過(guò)程。 如何實(shí)施 BizDevOps？ 這里介紹一下整體的內(nèi)容。我們用1個(gè)目標(biāo)，3個(gè)能力和5個(gè)實(shí)踐做了概括。 1個(gè)整體目標(biāo)：打造業(yè)務(wù)和技術(shù)有機(jī)融合的數(shù)字化組織，賦能數(shù)字業(yè)務(wù)的持續(xù)創(chuàng)新和長(zhǎng)期發(fā)展。 3個(gè)能力要求：它是實(shí)現(xiàn)這個(gè)目標(biāo)，組織必須具備的能力要求。 5個(gè)關(guān)鍵實(shí)踐：是關(guān)于做什么，如何做才能實(shí)現(xiàn)這三個(gè)能力。 接下來(lái)我們看三個(gè)能力要求。 第一個(gè)能力，形成以客戶(hù)價(jià)值為核心的組織協(xié)同能力。這就要求我們打通Biz到Dev、到Ops，價(jià)值交付鏈路和反饋閉環(huán)。 在打通鏈路，形成閉環(huán)的基礎(chǔ)上，還要實(shí)現(xiàn)全鏈路數(shù)字化運(yùn)作。全鏈路指的是從Biz到Dev、到Ops貫通；數(shù)字化運(yùn)作是指的是基于共同的底層模型、共同的作業(yè)對(duì)象，在各個(gè)環(huán)節(jié)里實(shí)現(xiàn)數(shù)據(jù)的即時(shí)共享，真正實(shí)現(xiàn)價(jià)值貫通。 全鏈路數(shù)字化運(yùn)作是第二個(gè)能力，只有全鏈路數(shù)字化運(yùn)作才能保障效率、質(zhì)量和有效性，并產(chǎn)生高可用的數(shù)據(jù)，這個(gè)數(shù)據(jù)不再是獨(dú)立環(huán)節(jié)，是一個(gè)整體的，全要素、實(shí)時(shí)貫通的數(shù)據(jù)。 第三個(gè)能力，基于高可用數(shù)據(jù)的過(guò)程透明和效能度量能力，保障數(shù)字化執(zhí)行落地，并持續(xù)提升組織效能。 這是 BizDevOps 需要的三個(gè)能力，它們形成一個(gè)閉環(huán)，不斷加強(qiáng)和持續(xù)改進(jìn)。 三個(gè)能力是要求，而5個(gè)實(shí)踐則是達(dá)成這些要求的具體操作。 我們來(lái)看看這5個(gè)實(shí)踐，它是一個(gè)四宮格，左邊是協(xié)作和管理實(shí)踐，右邊是工程和技術(shù)實(shí)踐，上面是組織層面整體相關(guān)的實(shí)踐，下面則是團(tuán)隊(duì)級(jí)別的操作實(shí)踐。 這樣相互交叉，左上方是組織層面的協(xié)作和管理實(shí)踐，我們稱(chēng)其為：業(yè)務(wù)驅(qū)動(dòng)組織協(xié)同機(jī)制；左下方是團(tuán)隊(duì)層面的協(xié)作和管理實(shí)踐，我們稱(chēng)其為：產(chǎn)品導(dǎo)向組織交付方式。右上方是整體的工程和技術(shù)實(shí)踐，我們稱(chēng)其為：適配業(yè)務(wù)特征的持續(xù)業(yè)務(wù)交付；右下方是單產(chǎn)品層面的工程和技術(shù)實(shí)踐，我們稱(chēng)其為：應(yīng)用為核心的研發(fā)資產(chǎn)和流程管理。在加上中間的關(guān)于度量和改進(jìn)的實(shí)踐，我們稱(chēng)其為：全量、全要素、實(shí)時(shí)數(shù)據(jù)支持的度量和持續(xù)改進(jìn)。這五個(gè)實(shí)踐構(gòu)成一個(gè)整體，最終是為了支撐數(shù)字業(yè)務(wù)的持續(xù)創(chuàng)新和長(zhǎng)期發(fā)展。 下面分別介紹這5個(gè)實(shí)踐。從協(xié)作和管理實(shí)踐開(kāi)始介紹，先講團(tuán)隊(duì)層面的，未來(lái)團(tuán)隊(duì)?wèi)?yīng)該是怎樣的，今天有一個(gè)根本的變化就是從項(xiàng)目導(dǎo)向，向產(chǎn)品導(dǎo)向遷移。前面我們說(shuō)過(guò)，數(shù)字化時(shí)代所有業(yè)務(wù)都要依靠數(shù)字產(chǎn)品支撐，數(shù)字產(chǎn)品承載了數(shù)字業(yè)務(wù)——業(yè)務(wù)的規(guī)則會(huì)沉淀并體現(xiàn)產(chǎn)品當(dāng)中，最核心的數(shù)據(jù)資產(chǎn)也必須由產(chǎn)品沉淀。我們對(duì)業(yè)務(wù)產(chǎn)期負(fù)責(zé)，就必須有人對(duì)于產(chǎn)品長(zhǎng)期質(zhì)量、長(zhǎng)期演進(jìn)以及對(duì)業(yè)務(wù)支撐能力負(fù)責(zé)。為此，我們需要從項(xiàng)目導(dǎo)向走向產(chǎn)品導(dǎo)向。 第一：基本假設(shè)不同。項(xiàng)目是以確定性為假設(shè)的，項(xiàng)目范圍是確定的，按照確定的范圍、確定時(shí)間交付確定的內(nèi)容就可以。而今天我們的業(yè)務(wù)持續(xù)演進(jìn)，產(chǎn)品與業(yè)務(wù)一同演進(jìn)，怎么可能是確定的？我們不得接受不確定性，建立反饋和調(diào)整的閉環(huán)，來(lái)支持我們探索和發(fā)現(xiàn)業(yè)務(wù)價(jià)值。當(dāng)然更主動(dòng)的是擁抱不確定性，與業(yè)務(wù)共同探索、創(chuàng)新。 第二：成功標(biāo)準(zhǔn)定義不同。項(xiàng)目導(dǎo)向，是把技術(shù)看作成本中心，以按時(shí)、按預(yù)算交付衡量成功；產(chǎn)品導(dǎo)向，則要求業(yè)務(wù)和技術(shù)融合，產(chǎn)品和業(yè)務(wù)共同構(gòu)成利潤(rùn)中心，以業(yè)務(wù)目標(biāo)和結(jié)果的達(dá)成來(lái)衡量成功。 第三：工作分配模式不同。項(xiàng)目導(dǎo)向是從把人作為資源分配到預(yù)先確定的工作（項(xiàng)目范圍）上，傾向批量式的規(guī)劃和交付；產(chǎn)品導(dǎo)向是把工作分配到穩(wěn)定的價(jià)值交付團(tuán)隊(duì)，尋求持續(xù)迭代交付和演進(jìn)。 第四：團(tuán)隊(duì)組織方式不同，項(xiàng)目導(dǎo)向是面向項(xiàng)目的范圍和時(shí)間要求，臨時(shí)組建團(tuán)隊(duì)；產(chǎn)品導(dǎo)向是面向業(yè)務(wù)和產(chǎn)品愿景，組織跨職能的相對(duì)穩(wěn)定的長(zhǎng)期團(tuán)隊(duì)，長(zhǎng)期的團(tuán)隊(duì)才能對(duì)長(zhǎng)期的質(zhì)量、演進(jìn)和業(yè)務(wù)結(jié)果負(fù)責(zé)，對(duì)所承載的業(yè)務(wù)資產(chǎn)負(fù)責(zé)。 第五：關(guān)鍵產(chǎn)出不同，項(xiàng)目團(tuán)隊(duì)的關(guān)鍵產(chǎn)出是單次項(xiàng)目的交付物；而產(chǎn)品導(dǎo)向的團(tuán)隊(duì)的產(chǎn)出是服務(wù)于業(yè)務(wù)創(chuàng)新和發(fā)展的產(chǎn)品，以及其沉淀的資產(chǎn)，包括數(shù)據(jù)資產(chǎn)，工程資產(chǎn)等。 再看組織層面的協(xié)作和管理實(shí)踐。其核心是業(yè)務(wù)和技術(shù)要真正連通，形成系統(tǒng)的閉環(huán)。 從業(yè)務(wù)目標(biāo)的制定和機(jī)會(huì)識(shí)別開(kāi)始、再到業(yè)務(wù)規(guī)劃，產(chǎn)出為目標(biāo)服務(wù)的業(yè)務(wù)需求，再分解成各產(chǎn)品的需求。 前面講過(guò)，產(chǎn)品由相對(duì)穩(wěn)定團(tuán)隊(duì)負(fù)責(zé)，它們共同分解設(shè)計(jì)產(chǎn)品需求，完成排期和交付。產(chǎn)品團(tuán)隊(duì)對(duì)產(chǎn)品的演進(jìn)、產(chǎn)品的資產(chǎn)沉淀以及維護(hù)負(fù)責(zé)，對(duì)產(chǎn)品的交付效能負(fù)責(zé)。 今天一個(gè)明確的趨勢(shì)，整體的應(yīng)用交付模式在向云原生遷移，將更多工程活動(dòng)標(biāo)準(zhǔn)化并委托給基礎(chǔ)設(shè)施完成，一方面效率提升，一方面也保證系統(tǒng)地彈性和韌性。 近期的一個(gè)核心變量是 ChatGPT 帶了的沖擊，AIGC會(huì)從根本上改變應(yīng)用生態(tài)和軟件交付生態(tài)，我相信開(kāi)發(fā)模式近五年會(huì)發(fā)生根本性轉(zhuǎn)變，技術(shù)開(kāi)發(fā)范式會(huì)發(fā)生根本變化，但業(yè)務(wù)和技術(shù)協(xié)同方式只會(huì)越來(lái)越緊密，反饋越來(lái)越快速。業(yè)技協(xié)同的要求也會(huì)更高。 再看來(lái)看右邊工程和技術(shù)領(lǐng)域，在 BizDevOps 時(shí)代有什么變化？基礎(chǔ)部分并沒(méi)有變化，云原生、微服務(wù)不會(huì)變化。但是很重要的，今天在講持續(xù)交付時(shí)核心的是持續(xù)交付什么，我們講的是持續(xù)業(yè)務(wù)交付，這點(diǎn)非常關(guān)鍵。 它不去刻意區(qū)分穩(wěn)態(tài)和敏態(tài)，也不分持或非持續(xù)的交付的。我們首先在模型上統(tǒng)一它們，然后再去辨別所謂穩(wěn)態(tài)和敏態(tài)，持續(xù)或非持續(xù)，究竟是哪些行為、模式不同。這將為我們的改進(jìn)提供非常有針對(duì)性的指導(dǎo)。 大致上看一下這個(gè)模型，它由三個(gè)核心部分，分別是：業(yè)務(wù)交付、產(chǎn)品發(fā)布和應(yīng)用變更。所有的交付都要處理好這三個(gè)問(wèn)題。當(dāng)然應(yīng)用變更，在不同的地方稱(chēng)謂是不同的，互聯(lián)網(wǎng)產(chǎn)品中用應(yīng)用變更比較多，傳統(tǒng)產(chǎn)品可能會(huì)稱(chēng)其為模塊或產(chǎn)品變更。 穩(wěn)態(tài)和敏態(tài)的交付并不是兩個(gè)截然對(duì)立的狀態(tài)，而是一個(gè)連續(xù)過(guò)程的兩級(jí)。 是什么區(qū)分敏態(tài)和穩(wěn)態(tài)？ 最重要的是三個(gè)要素。第一：部署單元的大小。穩(wěn)態(tài)部署單元會(huì)通常會(huì)更大，云原生開(kāi)發(fā)以微服務(wù)化的應(yīng)用為單元發(fā)布，發(fā)布單元會(huì)更小，紙質(zhì)單應(yīng)用部署發(fā)布。第二：發(fā)布的批量。穩(wěn)態(tài)的發(fā)布批量也會(huì)更大，即使你已經(jīng)做了云原生改造，理論上的部署單元比較小，但由于種種限制，仍然可以要求多個(gè)應(yīng)用必須一起發(fā)布。比如，每個(gè)月只有一發(fā)布窗口，要求所有應(yīng)用放在一起發(fā)布，發(fā)布批量也會(huì)變大；第三：發(fā)布過(guò)程的靈活性和效率。穩(wěn)態(tài)的發(fā)布過(guò)程的靈活性和速度會(huì)更低。在穩(wěn)態(tài)發(fā)布中，通常過(guò)程會(huì)更僵化和緩慢，可能有比較多的手工和審批環(huán)節(jié)。這可能是因?yàn)橄到y(tǒng)對(duì)穩(wěn)定性的高要求。但現(xiàn)實(shí)中更多的還是受制于技術(shù)的復(fù)雜度和技術(shù)能力，或者是單純的流程限制。 穩(wěn)態(tài)和敏態(tài)并不是非黑即白的兩個(gè)狀態(tài)，而是一個(gè)連續(xù)的過(guò)程。這個(gè)圖里面從紅到綠，它是連續(xù)譜，過(guò)度的區(qū)分這是穩(wěn)態(tài)的、這是穩(wěn)態(tài)的，設(shè)定人為的限制，事實(shí)上變相剝奪了那穩(wěn)態(tài)業(yè)務(wù)變得敏捷的權(quán)利。 明確敏態(tài)和穩(wěn)態(tài)的圖譜，更是為了指明改進(jìn)路徑。而這個(gè)路徑的設(shè)計(jì)既要?jiǎng)?wù)實(shí)，也要積極。務(wù)實(shí)就是要與業(yè)務(wù)的要求和能力水平相匹配；積極就是持續(xù)尋求改進(jìn)的可能。 比如，我可以讓發(fā)布單元的粒度變小一點(diǎn)點(diǎn)。我們不用上來(lái)追求微服務(wù)的絕對(duì)的“微”，將龐大的應(yīng)用適當(dāng)?shù)牟鸱?，依?lài)關(guān)系解耦的更好，讓它們可以單獨(dú)驗(yàn)證、單獨(dú)部署。這樣發(fā)布單元的粒度變小了一點(diǎn)點(diǎn)，是不是變得更敏捷一點(diǎn)？ 比如，我們可以讓發(fā)布的批量小一點(diǎn)點(diǎn)，從半年做一次上線發(fā)布，現(xiàn)在變成三個(gè)月發(fā)布，批量變得小了，是不是更敏捷了呢？當(dāng)然改進(jìn)要與能力的提升匹配，為了減小批量，往往需要流程、工具和工程的配套才行。 比如，我們可以持續(xù)減少發(fā)布過(guò)程耗時(shí)，依靠技術(shù)改進(jìn)，比如集成流程的優(yōu)化，自動(dòng)測(cè)試改進(jìn)，把一個(gè)月的發(fā)布變成了三周，是不是也變得更敏捷？ 我們想強(qiáng)調(diào)的是，從穩(wěn)態(tài)到敏態(tài)是一個(gè)持續(xù)和連續(xù)的過(guò)程。而決定我們偏向敏態(tài)和穩(wěn)態(tài)是三個(gè)變量。我們的改進(jìn)也可以圍繞這三個(gè)方面展開(kāi)。 我們定義了理想的持續(xù)交付模式，我們把它描述為：?jiǎn)螒?yīng)用部署、單業(yè)務(wù)需求發(fā)布、最小化發(fā)布流程。也就是上圖中的模式。 這是持續(xù)業(yè)務(wù)交付“完美”目標(biāo)，是 BizDevOps 追求的理想模型，最卓越團(tuán)隊(duì)可以做到的。 然而，現(xiàn)實(shí)中我們有種種業(yè)務(wù)、技術(shù)和流程的限制。這一理想交付模式只是給我們指引方向，至于我們要走到哪一步，要依現(xiàn)實(shí)而定，我們既要考慮業(yè)務(wù)需要，也要考慮團(tuán)隊(duì)的能力和投入。 全量、全要素、實(shí)時(shí)數(shù)據(jù)支撐度量和持續(xù)改進(jìn) 最后講一下度量和改進(jìn)，也就是第五個(gè)實(shí)踐，我簡(jiǎn)單講其中的一個(gè)部分。 今天效能度量成為大家的關(guān)注，我覺(jué)得熱度有點(diǎn)過(guò)了。大家定了很多指標(biāo)，但現(xiàn)實(shí)中起到作用的不多。為了澄清和選擇這些指標(biāo)，很重要的一點(diǎn)需要分清楚這些指標(biāo)的類(lèi)別。 指標(biāo)體系有一個(gè)很重要的是業(yè)務(wù)結(jié)果指標(biāo)，這是業(yè)務(wù)的最終目標(biāo)，比如收入、用戶(hù)轉(zhuǎn)化和利潤(rùn)等。業(yè)務(wù)結(jié)果當(dāng)然重要，問(wèn)題是它很難建立與交付或產(chǎn)品團(tuán)隊(duì)的直接關(guān)聯(lián)，這就失去了指標(biāo)的引導(dǎo)改進(jìn)的意義。 為此，我們定義了團(tuán)隊(duì)的效能指標(biāo)，但我們必須明白我們要的并不是交付效能，而是業(yè)務(wù)結(jié)果。交付效能和業(yè)務(wù)結(jié)果之間是有一個(gè)轉(zhuǎn)化函數(shù)的。我們要時(shí)刻檢討，這些效能真的能帶動(dòng)業(yè)務(wù)結(jié)果嗎，轉(zhuǎn)化函數(shù)有效嗎？這個(gè)問(wèn)題幫我們聚焦到有效的效能結(jié)果上去。 交付效能指標(biāo)，對(duì)于研發(fā)要盡可能偏向結(jié)果，比如交付速度、質(zhì)量、有效性等，這是交付效能指標(biāo)。這些效能指標(biāo)大家一定要清楚，它是業(yè)務(wù)結(jié)果的代理而已。應(yīng)不應(yīng)該使用這樣的結(jié)果指標(biāo)，我們?cè)谂袛嘟Y(jié)果指標(biāo)有沒(méi)有問(wèn)題時(shí)，最終都是看它對(duì)業(yè)務(wù)結(jié)果的影響是什么樣的。 交付效能指標(biāo)有一個(gè)問(wèn)題，它無(wú)法直接導(dǎo)向改進(jìn)行動(dòng)。比如，缺陷密度太高，說(shuō)明質(zhì)量差，可是我們?cè)撟鍪裁茨?？所以我還會(huì)關(guān)注內(nèi)部能力和行為指標(biāo)，比如：說(shuō)測(cè)試覆蓋率、架構(gòu)解耦度，這些是能力指標(biāo)；比如：代碼評(píng)審的比例，需求并行度這是行為指標(biāo)。能力、行為都是為交付效能服務(wù)的，它們不是我們最終追求的結(jié)果，卻是導(dǎo)向結(jié)果的依據(jù)和手段。 區(qū)分上面三類(lèi)指標(biāo)很重要，它們目的不同，用法也是不同的。越是左邊的越是偏向內(nèi)部，應(yīng)該授權(quán)給團(tuán)隊(duì)，賦能他們?nèi)シ治龊桶l(fā)現(xiàn)問(wèn)題。越是偏向右邊的，越偏向外部，可以作為組織的導(dǎo)向和要求。我們可以說(shuō)相對(duì)而言，左邊的是指標(biāo)，右邊的是目標(biāo)。我們要的是目標(biāo)，而非指標(biāo)。指標(biāo)只是分析問(wèn)題的依據(jù)。 度量是一個(gè)復(fù)雜命題，能用好度量的團(tuán)隊(duì)少之又少，這是現(xiàn)實(shí)。它的本質(zhì)困難來(lái)自于業(yè)務(wù)創(chuàng)新和產(chǎn)品交付是一個(gè)復(fù)雜系統(tǒng)，很難靠一個(gè)預(yù)先確定的度量系統(tǒng)來(lái)衡量和約束。而且產(chǎn)品交付中也存在測(cè)不準(zhǔn)原理，就是測(cè)量本身會(huì)干擾行為，從而得出錯(cuò)誤的數(shù)據(jù)，甚至導(dǎo)向錯(cuò)誤的行為。越是向內(nèi)的和微觀的，越難以測(cè)準(zhǔn)，這一點(diǎn)和物理學(xué)的測(cè)不準(zhǔn)原理也是一致的。 我講的只是原則。其實(shí)最重要的是，降低對(duì)度量的期待，尤其把它作為管理手段的期待，然后才能正確的應(yīng)用它，以目標(biāo)為導(dǎo)向，指標(biāo)更多的是賦能團(tuán)隊(duì)。如果能建立指標(biāo)和目標(biāo)的有效映射，并指導(dǎo)改進(jìn)，那度量就能發(fā)揮作用了。 總結(jié)，今天從數(shù)字業(yè)務(wù)的創(chuàng)新和發(fā)展的交付看，組織的煙囪或豎井，依然是創(chuàng)新和交付效率和效果的最大問(wèn)題。 我們看各個(gè)職能，他們往往是忙碌而“高效”的，當(dāng)然這個(gè)高效是要打引號(hào)的。因?yàn)閺目蛻?hù)角度、特別是業(yè)務(wù)角度就是另外一會(huì)事了。忙是內(nèi)部的資源效率，客戶(hù)感受到的是對(duì)業(yè)務(wù)需求響應(yīng)和流動(dòng)效率，業(yè)務(wù)感受到的是從想法到實(shí)現(xiàn)和驗(yàn)證反饋閉環(huán)的效率和效果，這些都往往與內(nèi)部的繁忙相反。 事實(shí)上，敏捷、精益還有 DevOps 都在試圖打破組織的豎井。但回到 BizDevOps 的視角，這是 Biz，這是Dev，這是Ops，Ops指的是運(yùn)維，其實(shí)還有運(yùn)營(yíng)。那么，今天影響數(shù)字化創(chuàng)新的是這三個(gè)豎井，打通和融合它們就成立一個(gè)重要命題。 BizDevOps目標(biāo)就是要打通這三個(gè)環(huán)節(jié)，業(yè)技融合，真正加速業(yè)務(wù)交付速度和形成有效的業(yè)務(wù)反饋、調(diào)整閉環(huán)。數(shù)字化業(yè)務(wù)轉(zhuǎn)型已經(jīng)成為時(shí)代的浪潮，相應(yīng)的組織必須變革，實(shí)現(xiàn)蝶變，才能駕馭數(shù)字化的力量，弄潮數(shù)字化時(shí)代。BizDevOps 是我們駕馭數(shù)字化力量的必由之路。