研發效能的提升必須落實爲團隊需求、協作和工程技術等實踐。接下來的幾篇文章，我將結合不同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 看板的功能是提升團隊協作、改善研發效能的有力工具，值得大家去探索和使用。
總結：可視化端到端價值流動，照亮關鍵所在
“可視化端到端價值流動”是基礎實踐，它照亮研發過程改進的關鍵所在，爲持續快速交付價值，爲研發效能改進奠定基礎。
總結:
爲了改進產品開發，我們必須讓團隊看到關鍵所在——需求的停滯
可視化端到端的價值流，照亮研發效能改進的關鍵
用戶價值驅動，前後職能拉通，左右模塊對齊，是可視化價值流動的基礎
在可視化價值流動的基礎上，做到問題和瓶頸即時和充分的顯現和解決
下一篇將介紹在可視化價值流動的基礎上，如何讓價值真正快速和高質量地流動起來。