阿裡雲雲效效能洞察産品正在灰階測試中，立即 測試體驗
本文作者：何勉
上一篇我們介紹了研發效能提升目标及其度量方法。（本文是阿裡“研發效能提升系列”的第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 瓶頸和問題即時可見 ——暴露阻礙價值流動的因素
價值驅動、前後拉通、左右對齊，這三條原則讓價值流動和傳遞的過程清晰可見。基于這一基礎，團隊就可以清晰的暴露需求傳遞過程中的問題和瓶頸。
上圖中的看闆展示了價值流動中最常見的問題，它們是：
- 瓶頸 ：某個環節流動不暢時，需求就會積壓形成瓶頸。關注和解決瓶頸，價值才能夠順暢地流動。
- 中斷：指某個步驟供給不足，價值流動出現中斷，它意味着上遊可能存在瓶頸。
- 需重點關注的需求 ：指涉及重大的商業利益或風險的重點需求，這是團隊要特别關注，在看闆應該重點标記。
- 被阻礙的需求 ：指因為外部（如依賴）或内部（如設計問題）原因無法正常進展的需求。
- 缺陷：缺陷是阻礙需求傳遞以及返工的重要原因，應該被凸顯，并優先解決。
- 即将或已經到期的需求 ：有明确的完成時間要求的需求，如果它們即将或已經到期，就應該被凸顯，并給與特别關注。
通常，團隊會在每日的站會上，檢視需求流動的狀态，以及流動過程中的問題，關注并即時解決這些問題，讓需求更順暢和快速的流動并傳遞。關于基于看闆的團隊站會，我的同僚舍衛有專文 介紹。
好的工具讓改進事半功倍 —— 雲效看闆的新功能全面落地了以上實踐和原則
雲效的看闆服務，貫徹了前文提到的理念和方法，互動上也針對主要使用場景做了優化。我們來看幾個實際使用的案例。
上圖是優酷的一個項目團隊看闆的截圖，它反映了端到端的價值流動過程，起到了拉通産品、設計、開發、測試等職能的作用。它支援對需求下屬任務分組，并展開顯示在同一泳道中，實踐上很好的促進了平行功能團隊（如：前後端、以及算法及相關依賴方）的任務向需求的對齊。
同時團隊基于它形成了順暢的協作和傳遞模式，做到了有效協作、順暢傳遞和品質内建（在每個過程環節保證品質），通過它以及相關配套實踐，團隊的協作、傳遞品質和時效都有了本質提升。
上圖是某中台技術團隊的例子，他們基于團隊看闆暴露了需求的嚴重停滞，團隊清楚看到了停滞帶來的影響，分析了造成停滞的原因。前後四個疊代，每個疊代都發現并聚焦不同的問題，通過協作、需求、工程等方面的實踐解決了這些問題，讓需求的流動順暢起來了，團隊傳遞品質和效率以及團隊對外的響應靈活性都顯著提升。
在這個例子中，可視化讓團隊看到了問題和影響，并采取管理和技術的手段去解決這些問題，團隊的持續釋出和傳遞效率和品質都得到了明顯改善。我的同僚
蔡春華 的文章介紹了其效能改進的實施過程，有興趣的同學可以參考。
雲效看闆的功能是提升團隊協作、改善研發效能的有力工具，值得大家去探索和使用。
總結：可視化端到端價值流動，照亮關鍵所在
“可視化端到端價值流動”是基礎實踐，它照亮研發過程改進的關鍵所在，為持續快速傳遞價值，為研發效能改進奠定基礎。
總結:
為了改進産品開發，我們必須讓團隊看到關鍵所在——需求的停滞
可視化端到端的價值流，照亮研發效能改進的關鍵
使用者價值驅動，前後職能拉通，左右子產品對齊，是可視化價值流動的基礎
在可視化價值流動的基礎上，做到問題和瓶頸即時和充分的顯現和解決
下一篇将介紹在可視化價值流動的基礎上，如何讓價值真正快速和高品質地流動起來。
作者介紹
何勉，阿裡巴巴資深技術專家，國内最早的精益産品開發實踐者之一，暢銷書《精益産品開發：原則、方法與實施》作者。專注于精益産品傳遞、精益創業創新及精益産品設計等領域，幫助組織提升研發效能。