從2020年全球的疫情爆發(fā)，到今天烏克蘭戰(zhàn)爭(zhēng)危機(jī)，這兩年整個(gè)世界都在經(jīng)歷著巨變。全球供應(yīng)鏈的破壞，大宗商品、能源價(jià)格的暴漲，無(wú)不給脆弱的經(jīng)濟(jì)雪上加霜。在如此大環(huán)境下，國(guó)內(nèi)經(jīng)濟(jì)自然也無(wú)法獨(dú)善其身，房地產(chǎn)債務(wù)問(wèn)題、財(cái)政赤字問(wèn)題、通脹的深度傳導(dǎo)都影響著我們的方方面面。

很多企業(yè)在需求萎縮加上高成本的雙重壓力下，可謂是負(fù)重前行，尤其是在數(shù)字化轉(zhuǎn)型過(guò)程中發(fā)現(xiàn)越來(lái)越迷茫。很多公司都在發(fā)出疑問(wèn)，在IT技術(shù)領(lǐng)域的投入是不是已經(jīng)進(jìn)入低ROI階段了？小編今天來(lái)嘗試分析一下。

在前面的一篇文章《數(shù)字化轉(zhuǎn)型與宮保雞丁》中曾經(jīng)闡述過(guò)一個(gè)觀點(diǎn)：

轉(zhuǎn)型最終是要滿足客戶的需求，當(dāng)客戶要求的是吃宮保雞丁時(shí)，你不能按照醬爆雞丁來(lái)做，那樣做出來(lái)的最終可能就連形似都沒(méi)有了。再先進(jìn)的產(chǎn)品或技術(shù)，如果不能用來(lái)解決問(wèn)題，被用戶拋棄只是早晚的事。所謂數(shù)字化轉(zhuǎn)型，數(shù)字化只是手段，轉(zhuǎn)型才是目的，而這背后更重要的是：轉(zhuǎn)型是為了滿足新的需求，而不是為了應(yīng)用新技術(shù)，這才是根本。

從某種程度上講，今天的每家公司本質(zhì)上都是一家軟件公司，首席信息官（CIO） /首席技術(shù)官（CTO）的角色從未像現(xiàn)在這樣重要，但保住這份工作變得更加具有挑戰(zhàn)性?？焖侔l(fā)展的業(yè)務(wù)需要更好的軟件支撐，更快地交付能力，對(duì)中斷或安全漏洞零容忍。CIO/CTO的績(jī)效不再以運(yùn)營(yíng)效率來(lái)衡量，而是以客戶體驗(yàn)、數(shù)字化產(chǎn)品和創(chuàng)收來(lái)衡量。

換句話說(shuō)，現(xiàn)代化企業(yè)的IT建設(shè)正在從傳統(tǒng)的偏重資源投入，向如今的傾向業(yè)務(wù)價(jià)值的回報(bào)來(lái)過(guò)渡。

在談價(jià)值流概念前，先帶大家看一句Mike Rother在他的書《Learning to See》中說(shuō)的話：

?“Whenever there is a product for a customer, there is a value stream. The challenge lies in seeing it”.

這句話并不難理解，翻譯過(guò)來(lái)就是：但凡是有客戶使用的產(chǎn)品，都會(huì)有價(jià)值流，挑戰(zhàn)在于如何看見(jiàn)它。

放到軟件產(chǎn)品里這也是成立的，這里的客戶可以是真正的客戶，也可以是企業(yè)內(nèi)部的員工，所以不存在沒(méi)有客戶的軟件產(chǎn)品的。

好了，該切入正題了，我們來(lái)給價(jià)值流下個(gè)定義：

價(jià)值流是指從最初的需求到客戶實(shí)現(xiàn)價(jià)值的過(guò)程中，為客戶增加價(jià)值而采取的一系列行動(dòng)。價(jià)值流通常從最初的概念開始，經(jīng)過(guò)不同的發(fā)展階段，然后進(jìn)行交付和支持，價(jià)值流總是以客戶開始和結(jié)束。

（圖片來(lái)自文檔網(wǎng)）

回到軟件領(lǐng)域，評(píng)估一個(gè)軟件的價(jià)值最簡(jiǎn)單的方式就是：看客戶愿意用多少經(jīng)濟(jì)單位（時(shí)間或金錢）來(lái)交換你的軟件。我們不妨給這個(gè)價(jià)值一個(gè)單位，類似于貨幣里的“元”，我們暫且叫它“客值”。

那么問(wèn)題就簡(jiǎn)單了，我們?cè)谲浖r(jià)值流中所有人員和團(tuán)隊(duì)的所有工作都應(yīng)專注于創(chuàng)造這種“客值”。舉個(gè)最簡(jiǎn)單的示例：假設(shè)我們提供了一項(xiàng)新產(chǎn)品的功能，如果客戶正好需要它或?qū)Υ烁械礁吲d，他們顯然會(huì)為此付費(fèi)，那么這個(gè)功能就是有“客值”的。以此類推，我們對(duì)影響產(chǎn)品使用的缺陷的修復(fù)，也是具有明顯“客值”的一種示例。

回到我們耳熟能詳?shù)腄evOps，它其實(shí)核心解決的是在軟件交付中提高“客值”通過(guò)價(jià)值流的速度，縮短創(chuàng)造“客值”的周期，就像是餐飲行業(yè)的“翻臺(tái)率”一樣。DevOps實(shí)踐主要是幫助企業(yè)，使用自動(dòng)化方式實(shí)現(xiàn)從代碼提交到生產(chǎn)的可重復(fù)操作路徑，這些多數(shù)都是線性的任務(wù)，類似于汽車裝配線。這樣帶來(lái)的好處也是顯而易見(jiàn)的，實(shí)施 DevOps后軟件從需要數(shù)周或數(shù)月才能發(fā)布新版本，到每天能夠?qū)崿F(xiàn)多次部署更改。

但這不能解決全部問(wèn)題，通過(guò)只關(guān)注部署提前而不是端到端的“價(jià)值實(shí)現(xiàn)周期”的結(jié)果，是只有部分價(jià)值流得到了優(yōu)化。來(lái)自客戶的需求（或市場(chǎng)需求）到產(chǎn)品上線后的運(yùn)營(yíng)，仍然是不可預(yù)測(cè)、無(wú)法衡量以及存在長(zhǎng)期風(fēng)險(xiǎn)的。

為什么DevOps無(wú)法應(yīng)用到整個(gè)價(jià)值流周期內(nèi)呢？這是因?yàn)镈evOps本質(zhì)的思想還是脫胎于精益生產(chǎn)原則，它的最主要目的也是為了消除浪費(fèi)和減少重復(fù)工作。而構(gòu)想和運(yùn)營(yíng)階段的工作與創(chuàng)建和發(fā)布階段有很大不同，其核心是，你基本上做的都是一些非標(biāo)準(zhǔn)化或非重復(fù)度高的工作，基至本身的工作都要經(jīng)過(guò)多次迭代，而這些迭代會(huì)增加工作本身的價(jià)值，而不是浪費(fèi)。

如果企業(yè)在產(chǎn)品開發(fā)整個(gè)周期中應(yīng)用精益生產(chǎn)原則就會(huì)阻礙創(chuàng)新，妨礙他們創(chuàng)造客戶所要求的更好的體驗(yàn)，也就是我們前面說(shuō)到的“客值”，這將導(dǎo)致價(jià)值流的中斷，我相信這也不不是任何一家企業(yè)希望看到的。

回答這個(gè)問(wèn)題之前，先來(lái)看一道互聯(lián)網(wǎng)上流傳的選擇題。

問(wèn)：以下哪種員工對(duì)企業(yè)可能造成的傷害最大？

A、聰明+勤奮

B、聰明+懶惰

C、愚笨+勤奮

D、愚笨+懶惰

現(xiàn)在讓你1秒鐘內(nèi)選擇答案，我相信很多人都會(huì)選擇D，但是真正的答案是C，不用解釋你仔細(xì)想一下就能明白。

回到價(jià)值流問(wèn)題上來(lái)，在需要非重復(fù)性工作產(chǎn)生“客值”的環(huán)節(jié)，我們更應(yīng)該優(yōu)先關(guān)注的是是“客值”的有效性，其次才是“客值”產(chǎn)生的效率，如果為了效率而犧牲“客值”有效性是非常愚笨的做法。那么此時(shí)的精益生產(chǎn)不僅不能提升業(yè)務(wù)價(jià)值，而是很可能會(huì)損傷原本的價(jià)值。

那我們就真的沒(méi)辦法了么？答案是不。

不管在哪個(gè)階段，你都應(yīng)該時(shí)刻關(guān)注業(yè)務(wù)對(duì)于客戶的價(jià)值交付情況，也就是保證你的價(jià)值流環(huán)節(jié)中“客值”的有效性和傳遞的可靠性，只有做到了這些才能說(shuō)我們的價(jià)值流是健康的，價(jià)值流健康也就代表著我們業(yè)務(wù)的健康?；氐阶铋_始的問(wèn)題，為什么你的產(chǎn)品越來(lái)越難賣？答案就是可能你的產(chǎn)品在“價(jià)值實(shí)現(xiàn)周期”中缺少對(duì)價(jià)值流的關(guān)注。

或者換個(gè)角度來(lái)下結(jié)論，價(jià)值流將是未來(lái)DevOps的更高級(jí)進(jìn)化形態(tài)，在數(shù)字化轉(zhuǎn)型中也將占有非常重要的地位，你準(zhǔn)備好了么？