[美] 加里·奧布萊恩 ThoughtWorks創始人 Roy著
本質問題的反思：如何超越績效
之前工作時有一種感覺一年更比一年強，我們財務規劃的能力與業務的期望是不匹配的，財務規劃的水平對業務結果有著決定性的力量。ThoughtWorks老板的思考非常的有啟發意義，并且給出了幾個概括。
第一種是運營支出與資本性支出沒有對齊，具體的體現就是研發投入不夠、銷售激勵沒錢等等
“運營支出（OPEX）預算和資本性支出（CAPEX）預算由不同的團隊決定，沒有相關性。換句話說，想做的工作與相關運營成本之間沒有聯系，導致無法支付那些業務承諾要做的工作所對應的人員薪水。”
第二種是滯后，因為平衡預算比高價值的工作更重要
我們很容易將所有阻礙敏捷性的問題歸咎于財務人員。財務度量出結果的時間通常很滯后，也就是說，發生在工作完成之后很長時間，以至于不能準確地將工作歸因于財務度量中的變動。財務度量的影響包括：使工作變慢或延遲；預算很快就花完了；組織這時對低價值的工作做出了“糟糕的”決定，因為預算平衡比高價值的工作更重要。以一家大型電信公司為例，我們見證了一些常見的財務行為模式：
上半財年的過度支出使得財務預算在財年中期被削減。這通常會對進行中的工作范圍造成壓力，延誤新工作，降低當年交付的價值。可預見的下個月招聘凍結（下半財年的第一個月）。這導致職能部門倍感壓力，填補大量職位空缺，基于運氣而不是工作價值來決定。第四季度息稅折舊攤銷前利潤（EBITDA）目標上升。這導致不可避免的爭先恐后地調整支出目標和優先級。財務目標是減少支出，財年結束時工作放慢了速度。在接下來幾年的第一個月出現了巨大的“曲棍球棒式”的工作，又回到了上面的第一點。
理論上來講，財務度量是度量企業業績的指標。只是它不能成為唯一的度量標準，不應被用于確定工作優先級或決定工作內容。但是實際上迫于生存、資本的壓力財務度量有著非常強的指導能力。
幾乎可以預測的是：上半年超支，招聘凍結，EBITDA（息稅折舊攤銷前利潤）增長，臨近本財年結束時工作放緩以降低支出。為了使預算獲得批準，通常會采用局部優化的思維方式。與“戰略”的松耦合。具有模糊性的數字化時代，科學管理理論已過時，變革的步伐使預測周期大大縮短，準確性比確定性更有價值。財務周期帶來的壓力已經把預算花不完變成了一個需要管理的“風險”。由于資本性支出（CAPEX）預算很低，因此“能否將其作為運營支出（OPEX）？
IT部門需要使用自動化測試，但是該工作對應的業務部門不想為此買單，因為這部分工作受益于所有人，而不僅僅是這個業務部門，在IT部門通常有一個“IT4IT”的預算。IT部門對所有業務部門一視同仁，圍繞可提供給它們的最低公共服務進行優化。業務部門的特殊需求被忽視了，也意味著忽視了客戶的需求，與此同時，業務部門將IT部門視為成本中心，而預算被分別分配給業務部門和IT部門。
這里給的一種解法是海盜指標
組織可以使用這些度量標準制訂關于業務增長的決策。首先度量網站上的瀏覽量作為先見性指標，然后通過海盜指標漏斗跟蹤瀏覽量的轉換。例如，獲取用戶階段瀏覽量總額的X%轉換為活躍度，Y%轉換為收入等。使用這種類型的先見性指標，還可以獲得可能存在問題的信號，設置策略在漏斗頂部放入更多內容，從而在相同的轉化次數下獲得更多的瀏覽量，或者著重于提高一個或多個元素的轉化率
后見性指標固然不錯，但它是一種隨時間變化的指標，根據過去的所有活動來度量當時的表現。很難確定哪些活動對這類度量標準有什么影響。這些度量標準本身往往需要數月的分析才能建立起來，等到以可讀的形式展現時，就已經“過時”了。比如財務報告通常代表至少一個月前的數據。
這里舉了一個麥當勞自定義漢堡的反例。
盡早試驗和識別適當的先見性指標，可以幫助找到正確的方法來交付客戶價值，并產生更多業務收益。在“自制漢堡”的例子中，潛在的先見性指標可能是：
· 知道餐廳中有定制漢堡的客戶的百分比。
· 在自助點餐機前駐足的客戶的百分比。
· 使用自助點餐機定制漢堡但在付款環節取消的客戶的百分比。
· 研究購買定制漢堡后下一次光臨時卻購買常規漢堡的客戶的百分比：
◆由于等待時間放棄的客戶的百分比。
◆由于價格放棄的客戶的百分比。
其中一些潛在的先見性指標可能很難度量，但數字技術正在使捕捉這些微弱的信號成為可能，而且使其變得更容易。在投入大量資金之前，一些指標可能會幫助發現“星廚系列”比“自制漢堡”更好。
配套還需要組織調整
隨著協調成本超過某個點的價值，大多數組織都達到了收益遞減的地步，降低了協調成本就能提升組織收益。角色執念是一種制度上的癥狀，不只是由人力資源政策引起的。比如基于項目的投資導致了巨大的隱性成本，并在中層管理中形成了一個金融權衡的黑市。這種現象是個普遍現象，大廠中會很常見，需要練習的是怎么在黑市中完成交易。這就是所謂的協調資源的能力還不夠強，本質是不愿意去黑市交易。
一個循環：
1、一個項目獲得了投資
2、投資基于員工人數而不是項目實際成本，意味著團隊不能以較低的成本獲得更多的資源。
3、可擴展性、維護工作、自動化測試、基礎設施等成本，要么被忽略，要么被低估，人們寄希望于這些成本來自其他的預算。
4、該項目隨著時間和預算的推移而完成。
5、維護成本被計入下一年的運營預算中，但運營預算又是每年都要削減的。
6、難以為繼的預算將導致走捷徑并犧牲質量，直到出現問題。
7、創建一個新項目來修復相關工作。
8、開始下一個循環
在現代IT中，存在一個“產品，而非項目”的概念，項目有一個確定的完成日期，工期有限。產品只要有價值，就會一直存在。項目通常是通過估算工作量，再添加一個大的余量，然后將投資控制在整個預算范圍內來獲得投資的。產品通常是通過估算你需要構建一個有用的、有價值的產品所需的團隊規模來獲得投資的，而且是長期投資這個團隊。大部分資金都花在了改進產品上，而不是在最初的開發上。
首先是環境，通過建立“安全地失敗”的環境，把先見性指標變為強大且有洞察力的指標。尋找透明與可視化的舉措，將是一家企業經歷的最有成效的文化變革之一。這樣，企業就能夠理解期望的成效、花費的資金和交付的價值之間的關系。有了輕量級的治理過程，就應該能夠每兩個月或每個季度審查和重新調整客戶價值交付與財務責任。
所謂的“組織”很大程度上是落在團隊組織，考核標準上的，比如考核到底考核的是價值還是工作的度量。瀑布式軟件開發方法是度量完成的工作而不是交付的價值的典型例子。將產品周期分解為多個步驟：需求收集、特性和架構設計、編碼和實現、測試、投產使用。如果需求沒有不確定性，開發過程中沒有戰略或市場條件的變化，技術平臺和集成沒有意外發生，生產環境和開發環境之間沒有差異，那么這就是一個完美的模型。需求收集、設計、編碼——這些階段客戶還不能使用系統，因此沒有向客戶交付任何價值。然而，從工作完成的角度來看，項目團隊進展順利，慶祝了一個又一個里程碑——整潔的文檔和信息板在整個流程中被完美地生成和呈現。通常，項目預警在編碼和測試的后期才會響起。“如果很痛苦，那就盡早并且頻繁地去做”的原則應用到軟件產品的編譯和測試中之后，我們開始將其進一步推廣，而不僅僅是集成代碼。軟件交付生命周期（SDLC）中另一個高風險和令人痛苦的步驟是實際部署和上線階段
解決這個問題聽起來很容易，但實際上非常困難——架構標準、API設計和代碼質量如何？度量、流程跟蹤和支出控制呢？落實到具體的管理動作，文化倡導落地到管理動作，包括架構（分工）、責任定義、支出（利益分配）
頂層規劃如何敏捷實現？
圍繞交付價值，明確投資回報：關鍵項目持續展示成本與交付價值的關系圖。
常見的脫節示例：可以看到工作是與戰略保持一致的，并試圖與組織的重點領域保持一致。在這個階段，領導者會感到舒適和滿足，認為工作緊隨戰略，他們可能會轉身離開，將剩下的工作留給中層管理人員去執行。但是可以看到在該圖的右側會發生什么：工作被沿著職能線分解，并與戰略失去聯系。組織中的職能劃分造就了里程碑和工作交接，但組織的價值流需要所有這些職能團隊的共同參與。許多得到圓點的工作仍然沒有開始進行，因為很難停止進行中的工作。繼續做團隊已經在做的事情更容易，對于無論如何都要做的工作來說更是如此。這也是一個非常具有對抗性的過程，對參與者來說是充滿爭論和不愉快的。
分工模型：級聯模型
以下是級聯模型中的關鍵步驟摘要：
· 將客戶成效目標進一步分解為二層、三層或四層工作，以及與之對應的成功的度量標準。每一項相互關聯的工作保持緊密聯系，每一次分解都是自主的，度量標準都是獨立的。
· 圍繞已確定的工作建立跨職能團隊，在團隊級別采用敏捷方法以及其他迭代的持續交付方法。
· 以全新的眼光審視進行中的工作，看看它是否與剛剛確認的目標與度量標準相符。如果是，應用前文提到的四個問題將當前工作帶入新的工作方式。
· 采用輕量級的優先級排序和治理模型，以確保所有工作（新工作或正在進行的工作）都得到定期審查，為最有價值的交付優化資源和能力。
級聯工作為團隊提供了成效的清晰視野。它可以幫助識別用于實時決策的先見性指標，并更快地反饋在成效上的進展。工作的級聯和相關分解將簡化度量、工作依賴關系和團隊組成。級聯模型是消除摩擦、確保所有工作都對齊并聚焦實現預期成效（而不僅僅是完成）的好方法。
級聯模型與價值鏈分解思路非常接近，是把核心指標進行層次分解，逐層拆解到細致的一層指標，每一層指標都是自主獨立的。
現狀與未來
在墻上復制組織架構。這是一個很常見的錯誤，我們可以默認當前組織肯定存在問題。反模式中的一個共同點是希望證明現狀是正確的，并抵制任何實際的更改。最危險的一句話是：“我們一直都是這么做的。”
從大處講就是組織架構與客戶價值交付不一致。
· 投資組合不關注產生最大價值的事情，而是與現有商業模式一致。
· 優先級排序重視確定性和完整性，勝過價值和準確性。
· 人力資源政策和流程不利于團隊穩定性和跨職能協作。
· 個人的目標不一致或沒有與成效成就對齊，獎金和KPI更加激勵個人貢獻而不是團隊協作，沒有鼓勵每個人都朝著同一個方向工作，即共贏。
組織的規章制度阻礙和減緩客戶價值交付，而不是參與其中并推動交付。所有組織都或多或少地受到以上所列的影響，有些很僵化，有些很靈活。組織就像“發動機”中一個巨大而沉重的齒輪，不斷轉動，無論試圖做出什么改變，這個大齒輪都會在下一個循環中又轉回來，并把自己調整回原來的模式。把一根棍子插到齒輪間不是解決問題的辦法。
展示預算負責人與交付團隊之間的關系的Circos圖，請注意圖中右側圈出的兩個區域。在上面的圈中，一條粗線表明這一組工作在兩個領域之間有著緊密的聯系，大部分工作都是為彼此完成的，并強烈表明它們應該成為一個團隊。在下面的圈中，從一個領域飛出許多細線貫徹整個組織，在這種情況下，團隊幾乎看不到其領導者，他們正在整個組織中四處奔波，通過談判和管理關系來完成工作。
自己在去年數據治理中歪打正著的畫了類似的一個圖，估計還被不少人拿去講了，以后自己有類似想法的點，需要把他做成一個立體全面的材料，而不只是一個idea，向上需要的是現狀、目標和預算，不講需要什么支持，要講具體的預算，與收益。
嘗試新人
我們會定期有意地雇用沒有技術背景的人員進入一家技術公司，并且使他們成為出色的技術專家。我們注重學習的意愿、適應的能力，讓那些尋求新的挑戰、能克服自己的缺點與局限性的人為團隊做出貢獻。
什么叫技術債
即使是最好的團隊也會欠下技術債。無論是如何構建起來的，從長遠來看，沒有一個團隊能夠承擔得起技術債。對技術卓越的承諾需要一種平衡的觀點——緊急角度是日常要交付需求，長期角度是對內部質量投資。
邊試邊做 學名叫TDD
測試驅動開發（TDD）是在編寫實現特性的代碼之前編寫單元測試或功能測試的實踐。
外包也沒那么省事
如內部員工與供應商員工的數量比值1:6，那么管理2.4萬名外包人員需要4000名內部員工。難怪IT被認為是昂貴、低效、緩慢和復雜的。
文中也建議試試內包，值得一提的是，并非所有的內包都是由要在內部建立數字化競爭優勢的需求所驅動。隨著供應商和承包商的成本持續上升，一些COO或CFO得出結論：從長遠來看，從內部雇用員工可能比從供應商雇用員工成本更低。但這種心態仍然是成本驅動，而不是價值驅動。一個更便宜的內部成本中心仍然是一個成本中心。內包應該是建立一種競爭優勢，而不是一種實用性能力，它建立的是營收中心而不是成本中心。然每個以卓越的軟件工程能力著稱的組織背后都有挖人的目標，那么在建立了這種能力之后，應該如何處理人員流失呢？組織能承擔得起這種損失嗎？
組織成功的關鍵
管理者的日常任務不應該以“告訴別人做什么和怎么做”為主。
第一個是讓員工明白自己做的事情的價值，在整體業務中的地位
第一個挑戰是保持歸屬感。這意味著通過工作和度量一致性、明確性和可視化，將其與更大范疇的企業目標和意義聯系起來。還要確保人們對自己的“家人團隊”——一個他們在情感上和工作上都可以依靠的支持網絡有清晰的認識。在某種程度上，這是人們如何看待個人品牌與組織品牌的關系。“我如何看待自己，別人就如何看待我所在的企業。”
第二點更難，明白事情的基礎上跳出團隊的限制（所謂的矩陣式？）
第二個挑戰是，幫助人們將其所屬的更大范疇的組織與其所屬的小團體聯系起來。在變化的時代，人們可能傾向于團結一致，變得過于依賴當前團隊。它變成了關于“我的”價值體系而不是“我們的”價值體系，關于“我的”活動而不是目的。在為生存而戰的過程中，行為可能會變得很有競爭性，甚至與其他團隊有對抗性。保護現狀比支持變革更重要。未能保持廣泛的歸屬感可能會導致孤立員工的意外后果。團隊構成變化即使符合邏輯且與客戶結果相一致，也會消除員工對組織的任何歸屬感，你可能會失去優秀人才。
用用戶故事來寫需求
與正式、詳細的系統需求或用例不同，“用戶故事”是對特性的簡單、非正式的描述。其格式通常是“作為（一種類型的用戶），我想（做某事），以便（實現某種價值）”。用戶故事并不是針對系統需求的精確文檔，而是業務用戶與開發故事的技術團隊之間的口頭交流工具。一個抽象的用戶故事可以被分解成許多更小、更具體的故事。用戶故事列表是待排序、待挑選和待處理的待辦事項列表。
架構師經常花費數月時間來分析需求，力求構建可以支持未來可能狀態中某個版本的系統，但最后卻猜錯了，或者外部環境（如業務戰略的變化）使他們的假設無效。
數據自助訪問方面都對團隊的效率至關重要
當談到“自助訪問”數據時，并不是指為一群用戶提供一個大型數據庫和Tableau的副本，以便他們可以建立自己的查詢（盡管這可能是整體數據戰略的有效部分），而是實際上在討論跨組織的不同團隊的自助訪問。通常，訪問數據涉及大量官僚主義、繁文縟節和摩擦。數據被鎖定在另一個系統中或由另一個團隊控制。在這種情況下，“自助訪問”意味著跨組織的團隊可以輕松地訪問適當的數據，而且摩擦很小。
內部提效應該怎么做
一個REA Colab產品包含：
· 一位產品經理，負責產品愿景、路線圖、受眾、度量標準、商業案例、用戶采用戰略和溝通計劃。
· 一位管理員，通過精簡待辦事項列表、改進技術、為用戶提供支持、維護文檔和高舉服務水平協議（SLA）大旗來保證質量。
· 一個據點，團隊可以了解產品、閱讀文檔、做出貢獻、查看示例、學習、請求新功能并提供反饋。
確保有足夠的能力來繼續改進產品，將改進變成“日常工作”。
開始整合，建立一個集中式團隊，包含一個產品經理和一個產品開發團隊。
企業網站可以被視為產品，各種各樣的讀者是客戶；與合作伙伴企業共享的數據集可以被視為產品；團隊使用的內部基礎架構平臺可以被視為產品；安全團隊的脆弱性和風險評估可以被視為產品；內部API或數據提要也可以被視為產品；等等。
待辦事項列表耦合
業務分析師擅長將業務需求分解為可開發的待辦事項，即當一個團隊向其待辦事項列表添加一個PBI（Product Backlog Item，產品待辦事項列表項）時，另一個團隊必須向其待辦事項列表添加一個對應的PBI。第一個團隊通常依賴于第二個團隊先完成這個PBI。這顯然會帶來很大的影響：團隊在等待下游團隊完成工作時放慢了速度，并且生產力急劇下降。如果遇到這種問題，首先要問的是為什么會出現這種耦合。是因為兩個看似獨立的團隊實際上在某種程度上是交織在一起的嗎？是否缺少一個抽象層或平臺，使團隊能夠避免耦合？這些團隊是否得到了充分的授權，可以自助訪問基礎設施和相關數據？
業務部門會直接與SaaS提供商接洽特定的服務，因為采購和實現流程似乎更簡單、更快。在業務部門中，經常可以看到一個“數字化”部門，其任務是使用該部門自己的技術人員和合作伙伴構建客戶參與的解決方案
附：推薦閱讀
數字化時代預算相關的文章多到可以占滿整本書的篇幅。實際上，杰里米·霍普（Jeremy Hope）和羅賓·弗雷澤（Robin Fraser）已經撰寫了一本相關的書《超越預算：管理者如何跳出年度績效評估的陷阱》（HBR Press）。而在本書中，我們重點強調的是導致了以上癥狀的傳統預算模型的關鍵約束，以及你需要為此準備好的應對方法
文章來源：有虔秉鉞
