研發效能提高 36 計第二課：照亮問題，效能提高從可視化交付過程開始

摘要：互聯網時代，業務與協做複雜度與日俱增，競爭日趨激烈，提高研發效能已成爲軟件行業的共同挑戰。《研發效能提高和敏捷實施 36 計》是阿里雲聯合 Teambition 精心打造的系列課程，課程由何勉、張剛、張燎原等國內多位在研發效能領域擁有數十年經驗的精益敏捷資深專家擔任講師；將從敏捷項目協做、敏捷需求管理、持續交付與工程實踐、設計及代碼實踐、業務創新 5 大方面，首次系統分享阿里巴巴研發效能提高方法、解析阿里巴巴及業界優秀實踐案例，並經過工具的直觀演示，幫助企業研發管理者們突破研發效能瓶頸、通往業務成功之路。

「提高研發效能」是產品研發的共同目標。可是，應該從哪裏開始呢？本次課程，是研發效能提高 36 計系列課程第二課，兩位講師將分享阿里巴巴的經驗——從可視化端到端交付過程、暴露問題開始，開啓研發效能提高之路。你將瞭解到：

可視化什麼
如何有效可視化的四個步驟
檢驗可視化效果的三個標準

注：如下內容是演講視頻的精要整理，點擊文末連接可前往課程信息合集頁面查看往期視頻、PPT 以及最新直播預告。

相信你們對可視化並不不陌生。不少敏捷團隊，都會使用實體或電子看板來實現信息透明和可視化。至於效果如何，就褒貶不一了。認爲有用並堅持的很多，認爲是形式主義的也大有人在。

咱們認爲，可視化是否有用，首先取決於：「可視化什麼?」，

一. 可視化什麼？——可視化照亮問題所在

故事發生在酒吧門前，一個醉漢正在路燈下面尋找什麼。警察在旁邊默默地看着他……，10 分鐘過去了，警察忍不住走上前去。
「你在找什麼？」警察問道;
「個人鑰匙」 醉漢回答 。
「是丟在這嗎？」警察看了一眼，並無發現鑰匙，因而問到。
「不是」 醉漢回答。
「那爲啥在這兒找？」警察不解地問道。
「只有這裏能看得見啊」醉漢很不耐煩的回答。

光照亮的地方，並非鑰匙（key）所在。英文中，「Key」 除了鑰匙的意思外，還有 「關鍵」 或 「答案」 的意思。可以看見的地方，卻不是 「關鍵」 所在，固然也找不到須要的答案。

研發過程中，咱們是否會範一樣的錯誤？很不幸，不但會，並且還很是廣泛。

對於研發過程，咱們容易看到是：人是否繁忙。咱們傾向從彙報線的角度考察各個職能部門的產出，如開發、測試、產品等職能的效率。

然而，致使研發過程的問題,如：集成、質量、進度對齊、需求溝通、環境維護及交付模等。這些問題的根源每每是系統性的，而非局部。它們不是光照亮的地方，也所以容易被忽略。

產品交付中的各種問題會致使需求的停滯，停滯的需求阻礙了價值的順暢流動，從根本上損害了研發效能。

在軟件產品的研發過程當中，其實根本問題歷來都不是停滯的資源（工程師），而是停滯的產品需求（用戶價值）。

這也爲研發過程的可視化提供了方向。研發過程可視化，就是要可視價值端到端的交付過程，讓咱們看到價值流動的過程，以及流動過程當中的阻礙、停滯和問題。

可視化的核心是：「照亮問題所在」。

讓咱們看一個例子。下圖是阿里天貓新零售團隊兩年前的看板。這個看板從左到右分紅了多個列，每列表明一個階段。看板上藍色的卡片是需求，它們從左到右，依次通過各個列，其中包括：選擇、設計、待評審、待開發、開發設計、開發中、測試等階段，一直到發佈。

咱們看到，「開發中」這一列比較寬，它分紅了若干個子列，最前面的這一列叫「需求」，用以停放需求卡片。其餘的子列分別是「前端、後端、測試、依賴」，這些子列中的黃色卡片是需求拆分出來的下屬任務。任務完成以後，就移到最後一個子列 —— 「完成」列。

「開發中」的需求和其下屬的任務處於同一行，咱們稱之爲「需求泳道」。某個需求下屬的全部任務都 「完成」後，則需求開發完成,能夠繼續日後流動到「待測試」，任務則能夠清理或摺疊。泳道空出，能夠準備讓下一需求進入。

經過這個看板咱們能夠看到需求流動的整個過程，看到需求被拆分紅多個任務以及團隊協做完成任務的過程。它幫助團隊暴露和發現問題，促進團隊更好地協做交付需求。爲團隊的高效協做和價值的順暢流動奠基了基礎。

以上是一個具體的例子，團隊各自的狀況不同，其可視化模式固然也不同。團隊如何結合團隊自身的上下文，設計本身的可視化方案呢？這是咱們接下來要介紹的。

二. 如何可視化——四個步驟實現有效可視化

爲告終合團隊具體的上下文，實現有效的可視化。在實踐中，咱們總結了 4 個步驟。

第一步：用戶價值驅動，識別有效的流動單元

咱們首先須要分析的是：團隊或組織對外交付的是什麼，從而識別有效的流動單元，明確可視化的主體。

下圖的示例，來自一個真實團隊。他們將流動單元分爲四種類型。

1. 產品規劃類需求：源自產品設計和規劃，服務於長期的業務目標；
2. 用戶平常需求：產品使用過程當中，來自用戶或業務方的平常反饋和要求，開發團隊須要及時響應,並按優先級排期開發；
3. 技術改進需求：爲了可持續的交付，或技術領先而提出需求，如技術重構、開發測試環境改進以及關鍵技術的引入等；
4. 問題和缺陷：團隊必須即時響應和解決的。

以上四類需求是這個團隊須要交付的主體內容，也是看板上的流動單元。

你們能夠根據本身團隊特色，分析並分類需求，肯定看板上的流動單元。在此基礎上，咱們才能夠分析和建模價值流動過程，也就是接下來介紹的第二步。

第二步：先後職能拉通，定義端到端價值流

這裏用不一樣顏色的卡片表明了不一樣類型的需求。如：綠色卡片表明用戶需求，藍色卡片表明技術改進需求。

團隊須要分析和建模需求流動的過程。上圖是其中的一個實例，需求從（被）「選擇」開始，通過「分析」、「待評審」階段到達「就緒」階段（注：就緒指的是對開發團隊而言的就緒）；再通過「實現」、「待測試」、「測試待發布」，最後到「已發佈」階段。這個端到端的過程就是需求交付的價值流。

端到端的價值流動過程,涉及不一樣的職能，如產品設計、交互視覺、開發和測試等。爲了提高流動效率，必須拉通組織中的各個職能，實現整個過程的可視化。

一些團隊由於條件約束，沒法當即作到全面的端到端拉通。條件容許，仍是要儘可能向兩端擴展，才能實現真正的端到端的敏捷和精益。這也爲團隊的進化提供了方向。

先後職能拉通是快速交付的基礎，除此以外，團隊還須要關注環節內的協做，特別是不一樣角色的協做，如：先後端開發團隊的協做，與外部依賴方的協做等，它也是促進價值快速流動的重要方面，這就是咱們接下來要討論的「左右模塊對齊」。

第三步：左右模塊對齊，體現環節的任務協做

環節內任務的協做，從需求的角度來看，反映的是需求的分解和合並。典型的一個例子是：實現過程當中，需求被拆分紅不一樣的任務，由不一樣的職能（如前端、後端、iOS、Andriod、外部依賴方等）完成。

上圖中間的「實現」階段中，綠色卡片所表明的需求被拆分紅多個任務（黃色卡片）。這些任務，分屬後端、iOS 開發、安卓開發以及外部依賴等。團隊的目的不是完成更多的任務，而儘快交付需求。

這就是咱們說的：左右模塊對齊，也就是任務向需求對齊，儘早交付需求。它促進團隊以需求交付爲牽引，更有效的協做，並幫助團隊發現影響需求交付的瓶頸。

識別有效流動單元，先後職能拉通和左右模塊對齊。這三個步驟讓需求交付過程清晰可見,並即時暴露流動過程當中的問題和瓶頸。

不過，爲了讓團隊更有效協做，咱們還必須在此基礎上，定義明確的需求流轉規則。這也是咱們接下來要介紹的第四步。

第四步：明確流轉規則，賦能團隊本地決策、內建質量

明確流轉的規則，就是定義需求向下一階段流動所必須知足的條件。好比:達到什麼條件才能從「待評審」進入「就緒」環節。團隊應該定義明確的需求流轉規則，並達成一致理解。

明確流轉規則幫助團隊作到內建質量。所謂內建質量，是讓需求在每個階段的質量，都獲得有效地保證，避免問題在最後的階段集中爆發，和避免沒必要要的返工，這也是持續順暢價值流動的基礎。

如何定義規則呢？讓咱們以「就緒」階段的准入規則爲例。

對開發團隊而言，「就緒」是他們的輸入，輸入的質量很大程度上決定了輸出的質量。IT行業裏面有一句話：「Garbage in,Garbage out」——輸入的是垃圾，輸出的就必然是垃圾。

一般，咱們指望就緒後的需求可以順暢地向後流動，而不是問題不斷，走走停停。需求進入就緒隊列時，問題尚未發生。按項目管理的術語，尚未發生的問題應該被稱做風險。典型的有：業務風險——需求是否清晰並理解一致；關聯風險——識別對外依賴和獲得承諾；技術風險——方案基本可行。

在定義就緒隊列的准入規則是，咱們應該考慮以上風險。因而，就有了下面的例子。就緒隊列准入規則:

1. 開發、測試和業務共同澄清需求，並定義明確交互過程和驗收標準
2. 大需求已拆分爲工做量在兩週之內能夠完成和交付的需求
3. 已與業務關聯方（若有）確認相關計劃
4. 識別大的技術風險並定義應對方案
5. 涉及三個（含三個）開發人員以上的需求，指定好協調人，負責進度協調

上面以「就緒」列爲例，定義了流轉規則。基於相似的原則，團隊能夠定義其它環節的流轉規則。

明肯定義的規則應該由團隊定義，並共同擁有，團隊對它們達成一致的理解和承諾，並基於它們協做和決策。它賦能團隊更好的自主決策。一樣重要的是,規則並不是一成不變，它是質量保證的重要手段,更是團隊改進的基線。

總結 - 可視化價值流的基本步驟

簡單回顧一下可視化價值流的四個基本步驟。
第一步: 用戶價值驅動,識別有效的流動單元；
第二步: 先後職能拉通，定義端到端的整個價值流；
第三步: 左右模塊對齊，反映環節內的任務協做；
第四步: 明肯定義流轉規則，賦能團隊實現本地快速決策，並保證內建質量。

三. 怎樣確保可視化效果？——有效可視化的三個檢驗標準

如何結合團隊自身的上下文，設計本身的可視化方案。每團隊均可以去實踐，相信會產出許多有特點的方案。

那又如何判斷，產出的方案是否有效呢？我將基於在實際實施中的經驗，給出三條原則，它對應三個問題。

問題一：能反映端到端的交付過程嗎？

問題二：能即時體現影響價值流動的瓶頸和問題嗎？

問題三：團隊能依據可視化的信息協做和作決定嗎？

對這三個問題的確定回答，一直是我設計看板系統的底線要求。事實也證實，作到以上三點，能夠爲價值的順暢流動，奠基一個很是堅實的基礎。至於如何使得價值流動得更快，就是水到渠成的事了，這部份內容會在後續課程中爲你們介紹。

4、總結

不要作「路燈下的醉漢」， 「讓光照亮問題所在」。這是爲了有效可視化,在思惟上所必需要有的轉變。爲了照亮問題所在，可視化的主體必須是需求、需求的流動過程、以及流動過程當中的問題和瓶頸。基於這一訴求，咱們分享了可視化的四個步驟和三個檢驗標準。但願它們能幫助你和你的團隊照亮研發效能改進的前路。

下面四幅招貼是對以上總結的形象表述。

最後，可視化是手段——讓價值順暢流動的手段，而非目的。下一講，咱們將分享如何在可視化的基礎上，加速價值的流動。

最新課程直播預告

直播時間：9 月 24 日 20:00 - 21:30

直播主題：第五課：【階段小結】研發效能提高之路，從天文學的演進提及

直播內容：

研發效能提高是一個系統實踐
可是，離開思惟方式的轉變
一切實踐都將無從落地
而思惟的轉變歷來不容易

互聯網時代，提高研發效能，究竟須要怎樣的思惟轉變？本次課程將結合天文學演進歷程的啓示，總結研發效能提高的範式變化，並基於此造成完整的實踐體系。

講師陣容：
阿里雲研發效能部資深技術專家、Teambition 客戶成功首席顧問 何勉
阿里雲研發效能部高級技術專家、Teambition 客戶成功資深專家 張燎原

觀看方式：
點擊此處連接，預定本次網頁版直播。

更多課程信息
點擊此處連接獲取更多課程信息、查看往期視頻、PPT 以及最新直播預告。

---

本文做者：Teambition Developer

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。