[美] 加里·奧布萊恩 ThoughtWorks創(chuàng)始人 Roy著

本質(zhì)問題的反思：如何超越績效

之前工作時有一種感覺一年更比一年強，我們財務(wù)規(guī)劃的能力與業(yè)務(wù)的期望是不匹配的，財務(wù)規(guī)劃的水平對業(yè)務(wù)結(jié)果有著決定性的力量。ThoughtWorks老板的思考非常的有啟發(fā)意義，并且給出了幾個概括。

第一種是運營支出與資本性支出沒有對齊，具體的體現(xiàn)就是研發(fā)投入不夠、銷售激勵沒錢等等

“運營支出（OPEX）預(yù)算和資本性支出（CAPEX）預(yù)算由不同的團隊決定，沒有相關(guān)性。換句話說，想做的工作與相關(guān)運營成本之間沒有聯(lián)系，導(dǎo)致無法支付那些業(yè)務(wù)承諾要做的工作所對應(yīng)的人員薪水。”

第二種是滯后，因為平衡預(yù)算比高價值的工作更重要

我們很容易將所有阻礙敏捷性的問題歸咎于財務(wù)人員。財務(wù)度量出結(jié)果的時間通常很滯后，也就是說，發(fā)生在工作完成之后很長時間，以至于不能準(zhǔn)確地將工作歸因于財務(wù)度量中的變動。財務(wù)度量的影響包括：使工作變慢或延遲；預(yù)算很快就花完了；組織這時對低價值的工作做出了“糟糕的”決定，因為預(yù)算平衡比高價值的工作更重要。以一家大型電信公司為例，我們見證了一些常見的財務(wù)行為模式：

上半財年的過度支出使得財務(wù)預(yù)算在財年中期被削減。這通常會對進行中的工作范圍造成壓力，延誤新工作，降低當(dāng)年交付的價值。可預(yù)見的下個月招聘凍結(jié)（下半財年的第一個月）。這導(dǎo)致職能部門倍感壓力，填補大量職位空缺，基于運氣而不是工作價值來決定。第四季度息稅折舊攤銷前利潤（EBITDA）目標(biāo)上升。這導(dǎo)致不可避免的爭先恐后地調(diào)整支出目標(biāo)和優(yōu)先級。財務(wù)目標(biāo)是減少支出，財年結(jié)束時工作放慢了速度。在接下來幾年的第一個月出現(xiàn)了巨大的“曲棍球棒式”的工作，又回到了上面的第一點。

理論上來講，財務(wù)度量是度量企業(yè)業(yè)績的指標(biāo)。只是它不能成為唯一的度量標(biāo)準(zhǔn)，不應(yīng)被用于確定工作優(yōu)先級或決定工作內(nèi)容。但是實際上迫于生存、資本的壓力財務(wù)度量有著非常強的指導(dǎo)能力。

幾乎可以預(yù)測的是：上半年超支，招聘凍結(jié)，EBITDA（息稅折舊攤銷前利潤）增長，臨近本財年結(jié)束時工作放緩以降低支出。為了使預(yù)算獲得批準(zhǔn)，通常會采用局部優(yōu)化的思維方式。與“戰(zhàn)略”的松耦合。具有模糊性的數(shù)字化時代，科學(xué)管理理論已過時，變革的步伐使預(yù)測周期大大縮短，準(zhǔn)確性比確定性更有價值。財務(wù)周期帶來的壓力已經(jīng)把預(yù)算花不完變成了一個需要管理的“風(fēng)險”。由于資本性支出（CAPEX）預(yù)算很低，因此“能否將其作為運營支出（OPEX）？

IT部門需要使用自動化測試，但是該工作對應(yīng)的業(yè)務(wù)部門不想為此買單，因為這部分工作受益于所有人，而不僅僅是這個業(yè)務(wù)部門，在IT部門通常有一個“IT4IT”的預(yù)算。IT部門對所有業(yè)務(wù)部門一視同仁，圍繞可提供給它們的最低公共服務(wù)進行優(yōu)化。業(yè)務(wù)部門的特殊需求被忽視了，也意味著忽視了客戶的需求，與此同時，業(yè)務(wù)部門將IT部門視為成本中心，而預(yù)算被分別分配給業(yè)務(wù)部門和IT部門。

這里給的一種解法是海盜指標(biāo)

組織可以使用這些度量標(biāo)準(zhǔn)制訂關(guān)于業(yè)務(wù)增長的決策。首先度量網(wǎng)站上的瀏覽量作為先見性指標(biāo)，然后通過海盜指標(biāo)漏斗跟蹤瀏覽量的轉(zhuǎn)換。例如，獲取用戶階段瀏覽量總額的X%轉(zhuǎn)換為活躍度，Y%轉(zhuǎn)換為收入等。使用這種類型的先見性指標(biāo)，還可以獲得可能存在問題的信號，設(shè)置策略在漏斗頂部放入更多內(nèi)容，從而在相同的轉(zhuǎn)化次數(shù)下獲得更多的瀏覽量，或者著重于提高一個或多個元素的轉(zhuǎn)化率

后見性指標(biāo)固然不錯，但它是一種隨時間變化的指標(biāo)，根據(jù)過去的所有活動來度量當(dāng)時的表現(xiàn)。很難確定哪些活動對這類度量標(biāo)準(zhǔn)有什么影響。這些度量標(biāo)準(zhǔn)本身往往需要數(shù)月的分析才能建立起來，等到以可讀的形式展現(xiàn)時，就已經(jīng)“過時”了。比如財務(wù)報告通常代表至少一個月前的數(shù)據(jù)。

這里舉了一個麥當(dāng)勞自定義漢堡的反例。

盡早試驗和識別適當(dāng)?shù)南纫娦灾笜?biāo)，可以幫助找到正確的方法來交付客戶價值，并產(chǎn)生更多業(yè)務(wù)收益。在“自制漢堡”的例子中，潛在的先見性指標(biāo)可能是：

· 知道餐廳中有定制漢堡的客戶的百分比。

· 在自助點餐機前駐足的客戶的百分比。

· 使用自助點餐機定制漢堡但在付款環(huán)節(jié)取消的客戶的百分比。

· 研究購買定制漢堡后下一次光臨時卻購買常規(guī)漢堡的客戶的百分比：

◆由于等待時間放棄的客戶的百分比。

◆由于價格放棄的客戶的百分比。

其中一些潛在的先見性指標(biāo)可能很難度量，但數(shù)字技術(shù)正在使捕捉這些微弱的信號成為可能，而且使其變得更容易。在投入大量資金之前，一些指標(biāo)可能會幫助發(fā)現(xiàn)“星廚系列”比“自制漢堡”更好。

配套還需要組織調(diào)整

隨著協(xié)調(diào)成本超過某個點的價值，大多數(shù)組織都達到了收益遞減的地步，降低了協(xié)調(diào)成本就能提升組織收益。角色執(zhí)念是一種制度上的癥狀，不只是由人力資源政策引起的。比如基于項目的投資導(dǎo)致了巨大的隱性成本，并在中層管理中形成了一個金融權(quán)衡的黑市。這種現(xiàn)象是個普遍現(xiàn)象，大廠中會很常見，需要練習(xí)的是怎么在黑市中完成交易。這就是所謂的協(xié)調(diào)資源的能力還不夠強，本質(zhì)是不愿意去黑市交易。

一個循環(huán)：

1、一個項目獲得了投資

2、投資基于員工人數(shù)而不是項目實際成本，意味著團隊不能以較低的成本獲得更多的資源。

3、可擴展性、維護工作、自動化測試、基礎(chǔ)設(shè)施等成本，要么被忽略，要么被低估，人們寄希望于這些成本來自其他的預(yù)算。

4、該項目隨著時間和預(yù)算的推移而完成。

5、維護成本被計入下一年的運營預(yù)算中，但運營預(yù)算又是每年都要削減的。

6、難以為繼的預(yù)算將導(dǎo)致走捷徑并犧牲質(zhì)量，直到出現(xiàn)問題。

7、創(chuàng)建一個新項目來修復(fù)相關(guān)工作。

8、開始下一個循環(huán)

在現(xiàn)代IT中，存在一個“產(chǎn)品，而非項目”的概念，項目有一個確定的完成日期，工期有限。產(chǎn)品只要有價值，就會一直存在。項目通常是通過估算工作量，再添加一個大的余量，然后將投資控制在整個預(yù)算范圍內(nèi)來獲得投資的。產(chǎn)品通常是通過估算你需要構(gòu)建一個有用的、有價值的產(chǎn)品所需的團隊規(guī)模來獲得投資的，而且是長期投資這個團隊。大部分資金都花在了改進產(chǎn)品上，而不是在最初的開發(fā)上。

首先是環(huán)境，通過建立“安全地失敗”的環(huán)境，把先見性指標(biāo)變?yōu)閺姶笄矣卸床炝Φ闹笜?biāo)。尋找透明與可視化的舉措，將是一家企業(yè)經(jīng)歷的最有成效的文化變革之一。這樣，企業(yè)就能夠理解期望的成效、花費的資金和交付的價值之間的關(guān)系。有了輕量級的治理過程，就應(yīng)該能夠每兩個月或每個季度審查和重新調(diào)整客戶價值交付與財務(wù)責(zé)任。

所謂的“組織”很大程度上是落在團隊組織，考核標(biāo)準(zhǔn)上的，比如考核到底考核的是價值還是工作的度量。瀑布式軟件開發(fā)方法是度量完成的工作而不是交付的價值的典型例子。將產(chǎn)品周期分解為多個步驟：需求收集、特性和架構(gòu)設(shè)計、編碼和實現(xiàn)、測試、投產(chǎn)使用。如果需求沒有不確定性，開發(fā)過程中沒有戰(zhàn)略或市場條件的變化，技術(shù)平臺和集成沒有意外發(fā)生，生產(chǎn)環(huán)境和開發(fā)環(huán)境之間沒有差異，那么這就是一個完美的模型。需求收集、設(shè)計、編碼——這些階段客戶還不能使用系統(tǒng)，因此沒有向客戶交付任何價值。然而，從工作完成的角度來看，項目團隊進展順利，慶祝了一個又一個里程碑——整潔的文檔和信息板在整個流程中被完美地生成和呈現(xiàn)。通常，項目預(yù)警在編碼和測試的后期才會響起。“如果很痛苦，那就盡早并且頻繁地去做”的原則應(yīng)用到軟件產(chǎn)品的編譯和測試中之后，我們開始將其進一步推廣，而不僅僅是集成代碼。軟件交付生命周期（SDLC）中另一個高風(fēng)險和令人痛苦的步驟是實際部署和上線階段

解決這個問題聽起來很容易，但實際上非常困難——架構(gòu)標(biāo)準(zhǔn)、API設(shè)計和代碼質(zhì)量如何？度量、流程跟蹤和支出控制呢？落實到具體的管理動作，文化倡導(dǎo)落地到管理動作，包括架構(gòu)（分工）、責(zé)任定義、支出（利益分配）

頂層規(guī)劃如何敏捷實現(xiàn)？

圍繞交付價值，明確投資回報：關(guān)鍵項目持續(xù)展示成本與交付價值的關(guān)系圖。

常見的脫節(jié)示例：可以看到工作是與戰(zhàn)略保持一致的，并試圖與組織的重點領(lǐng)域保持一致。在這個階段，領(lǐng)導(dǎo)者會感到舒適和滿足，認為工作緊隨戰(zhàn)略，他們可能會轉(zhuǎn)身離開，將剩下的工作留給中層管理人員去執(zhí)行。但是可以看到在該圖的右側(cè)會發(fā)生什么：工作被沿著職能線分解，并與戰(zhàn)略失去聯(lián)系。組織中的職能劃分造就了里程碑和工作交接，但組織的價值流需要所有這些職能團隊的共同參與。許多得到圓點的工作仍然沒有開始進行，因為很難停止進行中的工作。繼續(xù)做團隊已經(jīng)在做的事情更容易，對于無論如何都要做的工作來說更是如此。這也是一個非常具有對抗性的過程，對參與者來說是充滿爭論和不愉快的。

分工模型：級聯(lián)模型

以下是級聯(lián)模型中的關(guān)鍵步驟摘要：

· 將客戶成效目標(biāo)進一步分解為二層、三層或四層工作，以及與之對應(yīng)的成功的度量標(biāo)準(zhǔn)。每一項相互關(guān)聯(lián)的工作保持緊密聯(lián)系，每一次分解都是自主的，度量標(biāo)準(zhǔn)都是獨立的。

· 圍繞已確定的工作建立跨職能團隊，在團隊級別采用敏捷方法以及其他迭代的持續(xù)交付方法。

· 以全新的眼光審視進行中的工作，看看它是否與剛剛確認的目標(biāo)與度量標(biāo)準(zhǔn)相符。如果是，應(yīng)用前文提到的四個問題將當(dāng)前工作帶入新的工作方式。

· 采用輕量級的優(yōu)先級排序和治理模型，以確保所有工作（新工作或正在進行的工作）都得到定期審查，為最有價值的交付優(yōu)化資源和能力。

級聯(lián)工作為團隊提供了成效的清晰視野。它可以幫助識別用于實時決策的先見性指標(biāo)，并更快地反饋在成效上的進展。工作的級聯(lián)和相關(guān)分解將簡化度量、工作依賴關(guān)系和團隊組成。級聯(lián)模型是消除摩擦、確保所有工作都對齊并聚焦實現(xiàn)預(yù)期成效（而不僅僅是完成）的好方法。

級聯(lián)模型與價值鏈分解思路非常接近，是把核心指標(biāo)進行層次分解，逐層拆解到細致的一層指標(biāo)，每一層指標(biāo)都是自主獨立的。

現(xiàn)狀與未來

在墻上復(fù)制組織架構(gòu)。這是一個很常見的錯誤，我們可以默認當(dāng)前組織肯定存在問題。反模式中的一個共同點是希望證明現(xiàn)狀是正確的，并抵制任何實際的更改。最危險的一句話是：“我們一直都是這么做的。”

從大處講就是組織架構(gòu)與客戶價值交付不一致。

· 投資組合不關(guān)注產(chǎn)生最大價值的事情，而是與現(xiàn)有商業(yè)模式一致。

· 優(yōu)先級排序重視確定性和完整性，勝過價值和準(zhǔn)確性。

· 人力資源政策和流程不利于團隊穩(wěn)定性和跨職能協(xié)作。

· 個人的目標(biāo)不一致或沒有與成效成就對齊，獎金和KPI更加激勵個人貢獻而不是團隊協(xié)作，沒有鼓勵每個人都朝著同一個方向工作，即共贏。

組織的規(guī)章制度阻礙和減緩客戶價值交付，而不是參與其中并推動交付。所有組織都或多或少地受到以上所列的影響，有些很僵化，有些很靈活。組織就像“發(fā)動機”中一個巨大而沉重的齒輪，不斷轉(zhuǎn)動，無論試圖做出什么改變，這個大齒輪都會在下一個循環(huán)中又轉(zhuǎn)回來，并把自己調(diào)整回原來的模式。把一根棍子插到齒輪間不是解決問題的辦法。

展示預(yù)算負責(zé)人與交付團隊之間的關(guān)系的Circos圖，請注意圖中右側(cè)圈出的兩個區(qū)域。在上面的圈中，一條粗線表明這一組工作在兩個領(lǐng)域之間有著緊密的聯(lián)系，大部分工作都是為彼此完成的，并強烈表明它們應(yīng)該成為一個團隊。在下面的圈中，從一個領(lǐng)域飛出許多細線貫徹整個組織，在這種情況下，團隊幾乎看不到其領(lǐng)導(dǎo)者，他們正在整個組織中四處奔波，通過談判和管理關(guān)系來完成工作。

自己在去年數(shù)據(jù)治理中歪打正著的畫了類似的一個圖，估計還被不少人拿去講了，以后自己有類似想法的點，需要把他做成一個立體全面的材料，而不只是一個idea，向上需要的是現(xiàn)狀、目標(biāo)和預(yù)算，不講需要什么支持，要講具體的預(yù)算，與收益。

嘗試新人

我們會定期有意地雇用沒有技術(shù)背景的人員進入一家技術(shù)公司，并且使他們成為出色的技術(shù)專家。我們注重學(xué)習(xí)的意愿、適應(yīng)的能力，讓那些尋求新的挑戰(zhàn)、能克服自己的缺點與局限性的人為團隊做出貢獻。

什么叫技術(shù)債

即使是最好的團隊也會欠下技術(shù)債。無論是如何構(gòu)建起來的，從長遠來看，沒有一個團隊能夠承擔(dān)得起技術(shù)債。對技術(shù)卓越的承諾需要一種平衡的觀點——緊急角度是日常要交付需求，長期角度是對內(nèi)部質(zhì)量投資。

邊試邊做 學(xué)名叫TDD

測試驅(qū)動開發(fā)（TDD）是在編寫實現(xiàn)特性的代碼之前編寫單元測試或功能測試的實踐。

外包也沒那么省事

如內(nèi)部員工與供應(yīng)商員工的數(shù)量比值1:6，那么管理2.4萬名外包人員需要4000名內(nèi)部員工。難怪IT被認為是昂貴、低效、緩慢和復(fù)雜的。

文中也建議試試內(nèi)包，值得一提的是，并非所有的內(nèi)包都是由要在內(nèi)部建立數(shù)字化競爭優(yōu)勢的需求所驅(qū)動。隨著供應(yīng)商和承包商的成本持續(xù)上升，一些COO或CFO得出結(jié)論：從長遠來看，從內(nèi)部雇用員工可能比從供應(yīng)商雇用員工成本更低。但這種心態(tài)仍然是成本驅(qū)動，而不是價值驅(qū)動。一個更便宜的內(nèi)部成本中心仍然是一個成本中心。內(nèi)包應(yīng)該是建立一種競爭優(yōu)勢，而不是一種實用性能力，它建立的是營收中心而不是成本中心。然每個以卓越的軟件工程能力著稱的組織背后都有挖人的目標(biāo)，那么在建立了這種能力之后，應(yīng)該如何處理人員流失呢？組織能承擔(dān)得起這種損失嗎？

組織成功的關(guān)鍵

管理者的日常任務(wù)不應(yīng)該以“告訴別人做什么和怎么做”為主。

第一個是讓員工明白自己做的事情的價值，在整體業(yè)務(wù)中的地位

第一個挑戰(zhàn)是保持歸屬感。這意味著通過工作和度量一致性、明確性和可視化，將其與更大范疇的企業(yè)目標(biāo)和意義聯(lián)系起來。還要確保人們對自己的“家人團隊”——一個他們在情感上和工作上都可以依靠的支持網(wǎng)絡(luò)有清晰的認識。在某種程度上，這是人們?nèi)绾慰创齻€人品牌與組織品牌的關(guān)系。“我如何看待自己，別人就如何看待我所在的企業(yè)。”

第二點更難，明白事情的基礎(chǔ)上跳出團隊的限制（所謂的矩陣式？）

第二個挑戰(zhàn)是，幫助人們將其所屬的更大范疇的組織與其所屬的小團體聯(lián)系起來。在變化的時代，人們可能傾向于團結(jié)一致，變得過于依賴當(dāng)前團隊。它變成了關(guān)于“我的”價值體系而不是“我們的”價值體系，關(guān)于“我的”活動而不是目的。在為生存而戰(zhàn)的過程中，行為可能會變得很有競爭性，甚至與其他團隊有對抗性。保護現(xiàn)狀比支持變革更重要。未能保持廣泛的歸屬感可能會導(dǎo)致孤立員工的意外后果。團隊構(gòu)成變化即使符合邏輯且與客戶結(jié)果相一致，也會消除員工對組織的任何歸屬感，你可能會失去優(yōu)秀人才。

用用戶故事來寫需求

與正式、詳細的系統(tǒng)需求或用例不同，“用戶故事”是對特性的簡單、非正式的描述。其格式通常是“作為（一種類型的用戶），我想（做某事），以便（實現(xiàn)某種價值）”。用戶故事并不是針對系統(tǒng)需求的精確文檔，而是業(yè)務(wù)用戶與開發(fā)故事的技術(shù)團隊之間的口頭交流工具。一個抽象的用戶故事可以被分解成許多更小、更具體的故事。用戶故事列表是待排序、待挑選和待處理的待辦事項列表。

架構(gòu)師經(jīng)常花費數(shù)月時間來分析需求，力求構(gòu)建可以支持未來可能狀態(tài)中某個版本的系統(tǒng)，但最后卻猜錯了，或者外部環(huán)境（如業(yè)務(wù)戰(zhàn)略的變化）使他們的假設(shè)無效。

數(shù)據(jù)自助訪問方面都對團隊的效率至關(guān)重要

當(dāng)談到“自助訪問”數(shù)據(jù)時，并不是指為一群用戶提供一個大型數(shù)據(jù)庫和Tableau的副本，以便他們可以建立自己的查詢（盡管這可能是整體數(shù)據(jù)戰(zhàn)略的有效部分），而是實際上在討論跨組織的不同團隊的自助訪問。通常，訪問數(shù)據(jù)涉及大量官僚主義、繁文縟節(jié)和摩擦。數(shù)據(jù)被鎖定在另一個系統(tǒng)中或由另一個團隊控制。在這種情況下，“自助訪問”意味著跨組織的團隊可以輕松地訪問適當(dāng)?shù)臄?shù)據(jù)，而且摩擦很小。

內(nèi)部提效應(yīng)該怎么做

一個REA Colab產(chǎn)品包含：

· 一位產(chǎn)品經(jīng)理，負責(zé)產(chǎn)品愿景、路線圖、受眾、度量標(biāo)準(zhǔn)、商業(yè)案例、用戶采用戰(zhàn)略和溝通計劃。

· 一位管理員，通過精簡待辦事項列表、改進技術(shù)、為用戶提供支持、維護文檔和高舉服務(wù)水平協(xié)議（SLA）大旗來保證質(zhì)量。

· 一個據(jù)點，團隊可以了解產(chǎn)品、閱讀文檔、做出貢獻、查看示例、學(xué)習(xí)、請求新功能并提供反饋。

確保有足夠的能力來繼續(xù)改進產(chǎn)品，將改進變成“日常工作”。

開始整合，建立一個集中式團隊，包含一個產(chǎn)品經(jīng)理和一個產(chǎn)品開發(fā)團隊。

企業(yè)網(wǎng)站可以被視為產(chǎn)品，各種各樣的讀者是客戶；與合作伙伴企業(yè)共享的數(shù)據(jù)集可以被視為產(chǎn)品；團隊使用的內(nèi)部基礎(chǔ)架構(gòu)平臺可以被視為產(chǎn)品；安全團隊的脆弱性和風(fēng)險評估可以被視為產(chǎn)品；內(nèi)部API或數(shù)據(jù)提要也可以被視為產(chǎn)品；等等。

待辦事項列表耦合

業(yè)務(wù)分析師擅長將業(yè)務(wù)需求分解為可開發(fā)的待辦事項，即當(dāng)一個團隊向其待辦事項列表添加一個PBI（Product Backlog Item，產(chǎn)品待辦事項列表項）時，另一個團隊必須向其待辦事項列表添加一個對應(yīng)的PBI。第一個團隊通常依賴于第二個團隊先完成這個PBI。這顯然會帶來很大的影響：團隊在等待下游團隊完成工作時放慢了速度，并且生產(chǎn)力急劇下降。如果遇到這種問題，首先要問的是為什么會出現(xiàn)這種耦合。是因為兩個看似獨立的團隊實際上在某種程度上是交織在一起的嗎？是否缺少一個抽象層或平臺，使團隊能夠避免耦合？這些團隊是否得到了充分的授權(quán)，可以自助訪問基礎(chǔ)設(shè)施和相關(guān)數(shù)據(jù)？

業(yè)務(wù)部門會直接與SaaS提供商接洽特定的服務(wù)，因為采購和實現(xiàn)流程似乎更簡單、更快。在業(yè)務(wù)部門中，經(jīng)常可以看到一個“數(shù)字化”部門，其任務(wù)是使用該部門自己的技術(shù)人員和合作伙伴構(gòu)建客戶參與的解決方案

附：推薦閱讀

數(shù)字化時代預(yù)算相關(guān)的文章多到可以占滿整本書的篇幅。實際上，杰里米·霍普（Jeremy Hope）和羅賓·弗雷澤（Robin Fraser）已經(jīng)撰寫了一本相關(guān)的書《超越預(yù)算：管理者如何跳出年度績效評估的陷阱》（HBR Press）。而在本書中，我們重點強調(diào)的是導(dǎo)致了以上癥狀的傳統(tǒng)預(yù)算模型的關(guān)鍵約束，以及你需要為此準(zhǔn)備好的應(yīng)對方法

文章來源：有虔秉鉞