都996了，研發效能仍是提不起來，關鍵在這裏

上一篇咱們介紹了研發效能提高目標及其度量方法。（本文是阿里「研發效能提高系列」的第2篇，第1篇「研發效能的定義和度量」敬請期待【下週三】的釘釘羣直播：釘釘搜索羣號 23192180）

研發效能的提高必須落實爲團隊需求、協做和工程技術等實踐。接下來的幾篇文章，我將結合不一樣BU的案例，介紹研發效能提高的具體實踐。

本篇將從團隊協做的實踐開始，經過可視化端到端的價值流動過程，創建持續快速交付價值的基礎。

爲了改進研發效能，首先要知道從哪裏開始。讓咱們將從一個故事講起。

一. 不要作路燈下的醉漢 —— 效能改進從找到關鍵開始

酒吧門前的路燈下，一個醉漢踉踉蹌蹌地找着什麼，警察遠遠地看着，十多分鐘過去了，終於忍不住走上前去。「你在找什麼？」警察問到；「個人鑰匙」 醉漢說；警察快速掃視了一下：「沒有啊，是丟在這嗎？」；「不是！」醉漢回答；「那幹嗎在這找？」警察不解地問；「只有這能看見啊！」醉漢不耐煩地說。

鑰匙的英文是"Key"，也有「關鍵」和「答案」的意思。路燈照亮的地方，並不是「關鍵」所在。在路燈下尋找不存在的鑰匙，固然是愚蠢的。然而，在產品開發中相似情境卻一再發生。

在產品開發中，光照亮的是各個局部，好比：各環節的產出怎麼樣，工程師是否在忙。然而，總體並非局部的簡單疊加。若是缺少全局的協調，即便各個局部都很繁忙，總體的效率卻不必定高。

上圖列舉了部分長期困擾咱們的問題，如：團隊協做問題、目標和進度對齊問題、環境穩定性問題、集成問題等。這些都是系統性的問題，根源不在局部，不然，以阿里工程師的能力和責任心，它們早就被解決了。

在錯誤的地方尋找不存在的鑰匙，註定無功而返，甚至拔苗助長——局部優化損害總體效能，這是研發過程改進最大的坑。研發效能提高的關鍵究竟在哪裏呢？

二. 關注停滯的需求——研發效能改進的關鍵所在

在《The Principles of Product Development Flow》一書中，做者Don Reinertsen指出：

產品開發的核心問題歷來不是停滯的資源（工程師），而是停滯的價值項（用戶需求）。

以下圖所示，產品交付中的各種問題，都會致使需求停滯。好比常見的協做、環境、工程方法、質量等問題，都會表現爲需求停滯，停滯的需求又從根本上損害研發效能，圖中列出了其中的一些影響。

若是僅僅關注「停滯的工程師」，咱們總有辦法讓各個資源環節忙起來，至少看上去忙起來，但它每每只是掩蓋了問題。解決「停滯的需求」纔是根本，爲了讓需求順暢流動，咱們必須解決各種根本問題，需求的順暢流動又直接促進了效率、響應能力、靈活性、質量、創新以及士氣的提高。

然而，停滯的需求是影響研發效能的關鍵所在，可是卻不多被關注。由於它很難看見，是光未能照亮的地方。

三. 讓光照亮關鍵——可視化端到端的需求流動過程

爲改進研發效能，咱們不能作路燈下的醉漢。而是要讓光照亮關鍵所在，讓需求的停滯以及停滯的緣由即時顯現，可視化需求端到端的流動過程是作到這一點的基礎。

在產品開發中，可視化實踐並不新鮮。不少號稱應用敏捷開發的團隊，都在作，好比：在白板上貼上不一樣顏色的即時貼，或者應用Jira，Aone等電子看板展現工做任務。然而，它們中的大多數只不過是展現團隊工做的任務牆，並無照亮產品交付的關鍵，對效能改進的做用有限。

什麼纔是有效的可視化呢？咱們先看一個實體看板的例子。下圖中，天貓新零售某產品技術團隊的看板，它可視化了需求端到端的流動過程。

看板的中藍色卡片是需求，對應可交付的用戶價值。讓光照亮關鍵所在，就是要可視化用戶價值端到端流動和交付的過程。

需求在看板上從左至右流動，通過看板上的每一個階段，直至交付。從最左的「選擇」列，決定作一個需求開始，直到上線結束。這是一個端到端的過程，拉通了產品、開發、測試、運維等各個先後環節。

單獨看"開發中"這個階段，需求被分解成爲任務——圖中黃色紙條。任務與其所屬的需求處於同一行，咱們稱之爲泳道。泳道的首列（藍色紙條）是需求，下屬任務（黃色卡片)按模塊不一樣放在各自的列內，如前端、後端、以及外部依賴任務等。運行過程當中，同一需求下屬的任務儘可能對齊進度，快速完成需求。所屬的任務所有完成後，需求進入待測試，泳道清空，可讓下一需求進入。

以端到端的價值流動過程爲基礎，團隊就能即時看到問題，如：需求是否順暢流動，在哪裏發生了停滯和積壓，是否存在瓶頸。這就是所謂：光照亮了問題所在。

在這個案例中，咱們看到有效的可視化要作到四點：1）用戶價值驅動——需求反映用戶價值，是流動的主線索；2）先後職能拉通——以端到端的需求交付爲線索，鏈接各個職能和環節；3）左右模塊對齊——保證任務向需求對齊，快速交付需求；4）瓶頸問題即時可見。

其中，第四點是前三點的結果。它們共同做用，讓團隊看到需求流動（也是價值交付）的端到端的過程，看到需求在流動過程當中的狀態、問題和瓶頸，奠基持續快速的交付價值，以及持續改進的基礎。這就是讓光照亮了關鍵所在。

接下來，咱們按這四點，分別介紹可視化價值流動的操做實踐。

2.1 業務價值驅動 —— 明確流動單元，創建端到端流動的基礎

爲了可視化端到端的需求流動，咱們首先要明確流動的是什麼。它大體能夠分爲兩類：

1）業務需求。它們直接體現業務價值、貢獻業務能力，如：用戶對產品的需求、業務規劃的需求，體驗提高需求等。

2）支持性的需求。它們不直接體現業務價值，但幫助更快、更高質量和持續的交付價值，如：基礎設施的建設和改進，持續交付管道和自動化測試的建設，技術架構的升級和重構，新的技術框架或算法庫的引入等。

不一樣的產品和組織，對流動單元的分類不一樣。上表是某個產品交付團隊的需求分類，它區分了需求的類別，其輸入的規律及處理的規則等。

重點是：需求是價值的載體，是端到端流動和交付的基本單元，可視化的主體應該是從用戶出發的需求，而不是組織內部的任務。

2.2 先後職能拉通 —— 確保價值流動過程的端到端

識別了流動的基本單元——需求，接下來要作的是：展示需求端到端的流動過程。

所謂「端到端」，必須從業務視角定義——從業務出發，到業務結束，造成閉環，上圖表示了端到端流動過程當中的標誌性階段。

前一個「端」是輸入。典型的是從需求的選擇開始，市場的潛在機會老是無窮的，團隊從中選擇某些機會，並決定投入，這是價值流的起點。「被選擇」的價值項並不能直接進入開發階段，它須要被分析和澄清，才能夠輸入給開發。咱們稱達到這一狀態爲「就緒」。"就緒"是一個重要的階段，它決定開發團隊的輸入質量。

後一個「端」是輸出，典型的是需求交付完成，如：在線應用的發佈上線，商業軟件的交付和實施。還作不到持續發佈的團隊，有必要區別「待發布」和「已發佈」兩個階段，以清晰展現需求停滯在哪裏。

選擇、就緒、待發布和已發佈是四個典型的狀態。而中間細分的狀態則根據團隊的協做和開發模式而異。上一篇關於度量的文章中，反映流動效率的週期時間也是以這四個階段爲基準定義的。

這四個階段設定了端到端價值流動的框架。以此爲基礎，團隊還要設定流動的具體流程步驟，下一節中將展現具體的實例。

2.3 左右部門（模塊）對齊 —— 讓開發任務向價值交付對齊

可視化應該體現團隊協做和交付價值的過程，下圖中的看板再現了團隊的先後職能，以及平行模塊間協做交付價值的過程。

首先，它反映了環節間的協做。看板上的各個列，表明需求交付的環節。價值項沿各個列順序流動，體現上下游之間的協做。它們中有些是工做列，如：分析、實現、測試等，價值項在工做列被處理；有些則是等待列，如待評審、就緒、待測試、待發布等。

其次，這一價值流也反映了環節內相關方的協做，如：前、後端的協做，內部團隊與外部依賴方的協做等。圖中，在實現階段，一個需求被分解成不一樣模塊以及外部依賴方的任務。需求及其分解出的任務被放在同一橫向泳道之中，體現了它們的關聯關係。全部下屬任務完成了，需求才能移入下一環節——待測試列，它佔用的泳道也被清空，等待下一個需求進入。

看板中的每一個泳道容納一個需求，團隊的目標是儘快完成需求，而不是每一個人手上有任務在作，它確保了任務向需求的對齊，這就是咱們所說的「左右部門（模塊）對齊」，對齊的對象是需求、是價值。

2.4 瓶頸和問題即時可見 ——暴露阻礙價值流動的因素

價值驅動、先後拉通、左右對齊，這三條原則讓價值流動和交付的過程清晰可見。基於這一基礎，團隊就能夠清晰的暴露需求交付過程當中的問題和瓶頸。

上圖中的看板展現了價值流動中最多見的問題，它們是：

• 瓶頸 ：某個環節流動不順暢時，需求就會積壓造成瓶頸。關注和解決瓶頸，價值纔可以順暢地流動。
• 中斷：指某個步驟供給不足，價值流動出現中斷，它意味着上游可能存在瓶頸。
• 需重點關注的需求 ：指涉及重大的商業利益或風險的重點需求，這是團隊要特別關注，在看板應該重點標記。
• 被阻礙的需求 ：指由於外部（如依賴）或內部（如設計問題）緣由沒法正常進展的需求。
• 缺陷：缺陷是阻礙需求交付以及返工的重要緣由，應該被凸顯，並優先解決。
• 即將或已經到期的需求 ：有明確的完成時間要求的需求，若是它們即將或已經到期，就應該被凸顯，並給與特別關注。

一般，團隊會在每日的站會上，檢視需求流動的狀態，以及流動過程當中的問題，關注並即時解決這些問題，讓需求更順暢和快速的流動並交付。關於基於看板的團隊站會，個人同事舍衛有專文 介紹。

好的工具讓改進事半功倍 —— Aone 看板的新功能全面落地了以上實踐和原則

Aone的看板服務，貫徹了前文提到的理念和方法，交互上也針對主要使用場景作了優化。咱們來看幾個實際使用的案例。

上圖是優酷的一個項目團隊看板的截圖，它反映了端到端的價值流動過程，起到了拉通產品、設計、開發、測試等職能的做用。它支持對需求下屬任務分組，並展開顯示在同一泳道中，實踐上很好的促進了平行功能團隊（如：先後端、以及算法及相關依賴方）的任務向需求的對齊。

同時團隊基於它造成了順暢的協做和交付模式，作到了有效協做、順暢交付和質量內建（在每一個過程環節保證質量），經過它以及相關配套實踐，團隊的協做、交付質量和時效都有了本質提高。

上圖是某中臺技術團隊的例子，他們基於團隊看板暴露了需求的嚴重停滯，團隊清楚看到了停滯帶來的影響，分析了形成停滯的緣由。先後四個迭代，每一個迭代都發現並聚焦不一樣的問題，經過協做、需求、工程等方面的實踐解決了這些問題，讓需求的流動順暢起來了，團隊交付質量和效率以及團隊對外的響應靈活性都顯著提高。

在這個例子中，可視化讓團隊看到了問題和影響，並採起管理和技術的手段去解決這些問題，團隊的持續發佈和交付效率和質量都獲得了明顯改善。個人同事 蔡春華 的文章介紹了其效能改進的實施過程，有興趣的同窗能夠參考。

Aone 看板的功能是提高團隊協做、改善研發效能的有力工具，值得你們去探索和使用。

總結：可視化端到端價值流動，照亮關鍵所在
「可視化端到端價值流動」是基礎實踐，它照亮研發過程改進的關鍵所在，爲持續快速交付價值，爲研發效能改進奠基基礎。

總結:

爲了改進產品開發，咱們必須讓團隊看到關鍵所在——需求的停滯

可視化端到端的價值流，照亮研發效能改進的關鍵

用戶價值驅動，先後職能拉通，左右模塊對齊，是可視化價值流動的基礎

在可視化價值流動的基礎上，作到問題和瓶頸即時和充分的顯現和解決

下一篇將介紹在可視化價值流動的基礎上，如何讓價值真正快速和高質量地流動起來。

做者介紹

何勉，阿里巴巴資深技術專家，國內最先的精益產品開發實踐者之一，暢銷書《精益產品開發：原則、方法與實施》做者。專一於精益產品交付、精益創業創新及精益產品設計等領域，幫助組織提高研發效能。

 

原文連接 更多技術乾貨 請關注阿里云云棲社區微信號 ：yunqiinsight