都996了，需求還是沒法按時交付，怎麼辦？

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

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

酒吧門前的路燈下，一個醉漢踉踉蹌蹌地找著什麼，警察遠遠地看著，十多分鐘過去了，終於忍不住走上前去。

“你在找什麼？”警察問到。
“我的鑰匙” 醉漢說。
警察快速掃視了一下：“沒有啊，是丟在這嗎？”
“不是！”醉漢回答。
“那幹嘛在這找？”警察不解地問。
“只有這能看見啊！”醉漢不耐煩地說。

鑰匙的英文是\u0026quot;Key\u0026quot;，也有“關鍵”和“答案”的意思。路燈照亮的地方，並非“關鍵”所在。在路燈下尋找不存在的鑰匙，當然是愚蠢的。然而，在產品開發中類似情境卻一再發生。

在產品開發中，光照亮的是各個區域性，比如：各環節的產出怎麼樣，工程師是否在忙。然而，整體並不是區域性的簡單疊加。如果缺乏全域性的協調，即使各個區域性都很繁忙，整體的效率卻不一定高。

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

在錯誤的地方尋找不存在的鑰匙，註定無功而返，甚至適得其反——區域性優化損害整體效能，這是研發過程改進最大的坑。研發效能提升的關鍵究竟在哪裡呢？

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

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

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

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

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

然而，停滯的需求是影響研發效能的關鍵所在，但是卻很少被關注。因為它很難看見，是光未能照亮的地方。

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

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

在產品開發中，視覺化實踐並不新鮮。很多號稱應用敏捷開發的團隊，都在做，比如：在白板上貼上不同顏色的即時貼，或者應用看板展示工作任務。然而，它們中的大多數只不過是展示團隊工作的任務牆，並沒有照亮產品交付的關鍵，對效能改進的作用有限。

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

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

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

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

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

在這個案例中，我們看到有效的視覺化要做到四點：

1. 使用者價值驅動——需求反映使用者價值，是流動的主線索；
2. 前後職能拉通——以端到端的需求交付為線索，連線各個職能和環節；
3. 左右模組對齊——保證任務向需求對齊，快速交付需求；
4. 瓶頸問題即時可見。

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

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

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

為了視覺化端到端的需求流動，我們首先要明確流動的是什麼。它大致可以分為兩類：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 瓶頸 ：某個環節流動不暢時，需求就會積壓形成瓶頸。關注和解決瓶頸，價值才能夠順暢地流動。

• 中斷：指某個步驟供給不足，價值流動出現中斷，它意味著上游可能存在瓶頸。

• 需重點關注的需求：指涉及重大的商業利益或風險的重點需求，這是團隊要特別關注，在看板應該重點標記。

• 被阻礙的需求：指因為外部（如依賴）或內部（如設計問題）原因無法正常進展的需求。

• 缺陷：缺陷是阻礙需求交付以及返工的重要原因，應該被凸顯，並優先解決。

• 即將或已經到期的需求：有明確的完成時間要求的需求，如果它們即將或已經到期，就應該被凸顯，並給與特別關注。

通常，團隊會在每日的站會上，檢視需求流動的狀態，以及流動過程中的問題，關注並即時解決這些問題，讓需求更順暢和快速的流動並交付。

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

雲效的看板服務，貫徹了上文提到的理念和方法，互動上也針對主要使用場景做了優化。我們來看幾個實際使用的案例。

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

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

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

在這個例子中，視覺化讓團隊看到了問題和影響，並採取管理和技術的手段去解決這些問題，團隊的持續釋出和交付效率和質量都得到了明顯改善。

雲效的看板的功能是提升團隊協作、改善研發效能的有力工具，值得大家去探索和使用。

總結：視覺化端到端價值流動，照亮關鍵所在

“視覺化端到端價值流動”是基礎實踐，它照亮研發過程改進的關鍵所在，為持續快速交付價值，為研發效能改進奠定基礎。

總結:

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

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

• 使用者價值驅動，前後職能拉通，左右模組對齊，是視覺化價值流動的基礎。

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

作者簡介

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