本文內容節選自第六屆全球軟體案例研究峰會，時任華為敏捷精益專家陳軍老師分享的《華為百人團隊精益看板演進變革之路》實錄，重點分享：精益看板的建立，團隊革新。（PPT+文稿）。

陳軍老師是華為精益敏捷專家；現負責精益看板在整個華為的落地實施，輔導的各產品線團隊規模均上百人，團隊效率提升明顯。 原騰訊高階專案經理；PMP；CSM；EXIN LEAN IT中國首位認證講師；NLP教練；國家三級心理諮詢師。

編者按：2017年11月9-12日，第六屆全球軟體案例研究峰會在北京國家會議中心盛大開幕，現場解讀2017年「壹佰案例榜單」。時任華為敏捷精益專家陳軍老師分享的《華為百人團隊精益看板演進變革之路》實錄。

【內容簡介】在面對市場需求的激增和快速的變化時，研發團隊要如何靈活應對並快速響應，如何在有限的人力下提升研發效率。本文將介紹華為百人團隊精益看板演進變革的歷程，從建立看板到運作看板，取得小勝利，再到團隊遇到困局，停滯不前甚至倒退，面對困局同團隊一起再審視改進，重新走上了正確的道路。

1

華為研發面臨的挑戰

客戶分類：

傳統運營商客戶：運營商受到網際網路企業的衝擊，要求版本更新得更快。

企業客戶：以華為的DCN資料網路中心為例，承載了大量的資料業務，企業對此格外重視，版本更新迭代較之以往提速許多。

終端客戶：個人客戶需求變化頻繁，甚至是每天都在改變。

華為內部：團隊龐大，產品、業務複雜。一個產品的解決方案有時會牽扯到上千人導致效率低下。

02

為什麼要選擇精益看板

1.對研發衝擊小：精益看板不會改變組織架構、人員角色，但可以將整體格式化、規範化。

2.適應性強：看板是“元流程”，它可以和任何流程相匹配，無需擔心要怎麼去融入看板。

3.可提升吞吐量：研發的吞吐量與車道流量十分相似，其相關定義如下圖：

 

 

在研發過程中，難免會存在吞吐量非常小的環節，我們可以稱其為研發中的瓶頸，瓶頸發生的地方稱之為阻塞點。那麼如何解決呢？關鍵在於保證WIP一定情況下縮短Leadtime，這可以從縮短Worktime和waittime兩個方面著手。例如做自動化測試，可以大大縮短編譯時間，提高整體“通道的流速”。

4.看板是一種持續改進的機制。

 

 

仔細觀察上圖，可以看到開發已經沒有正在進行中的事項，但還有許多待辦事項，這是由於測試環節處存在積壓事項。但此時我們仍要進行深入的分析其究竟是不是瓶頸再做定奪。

在圖中，異常卡片所代表的事項是環節中的阻塞點。異常卡片這一設定是看板上的視覺化元素，可以讓團隊持續改進，把問題充分暴露出來。

03

百人團隊實施案例分享

下圖是在引入一個新方法時，絕大多數團隊會經歷的歷程。下面我們以引入看板為例：

 

 

出於產品的訴求，引入了看板機制，之後會取得一定的小勝利，但在使用過程中也逐漸出現新的問題，只有解決新問題後團隊才能走上正確道路。

但大多數團隊會由於沒有正視問題而迷失在困局內，這不是引入模式的問題，而是團隊使用方法出現了問題。

業務痛點

1.市場增加，需求增大：外部市場的增加，同時團隊面臨著組織的調整，團隊的人數減少了，這種情況下更急需提升團隊的產能。

2.需求變化快，需要快速響應：在研發無法滿足市場時，需要進行一些變革，這也是引入精益看板的原因。但也需要考量專案團隊是否與精益看板相匹配：第一業務訴求與精益看板是否相匹配；第二團隊積極性是否高昂。

看板的引入

在引入看板時，存在兩組實踐。

 

 

第一組實踐是建立看板，另一組為運作看板。並把八大實踐分為兩組，建立視覺化過程。

價值流對映

將研發過程視覺化，對映到看板上。

 

 

按照華為團隊需求結構可分為三層：IR、SR、AR。

第一層IR是初始來自客戶的需求，隨後分解到第二層的系統需求，最後分配到團隊級的AR。我們根據上述特點，建立了產品級看板和團隊級看板。需求從上往下分解，狀態從下向上卷積。

顯示化流轉規則

卡片的每一次向下流動都需要一個規則，這些規則是共同定製的質量條件，目的是為了保證每一步的程序都是良好可執行的。

但規則不是死的，是隨著環境、研發的變化而變化，是可以被重新商議更改的。唯一的條件是，規則制定後必須嚴格執行。

規則的制定來源於自働化。眾所周知，自働化是豐田的重要原則之一。豐田最早做自動織布機時，把傳統的手動織布機改為自動織布機，但是問題來了，當有線斷掉的時候織布機不會停止，這樣出來的產品時殘次品，後來經過改良在織布機出現故障時由人工 來檢查重啟，檢查通過後才會繼續運作。這也是內建質量的過程。

 

 

限制在製品

這是看板中最難實施的一個步驟。因為為保證投入的精力，每人同時只能幹兩件事情。

儘管在以往，一個人同時做多件事情被認為也是無傷大雅的。但這是由於需求流動無法被直觀看到，最終極易導致需求流轉不動，一直停留在開發程序中。這時候我們需要轉換自己的視角，更多關注流動效應。

 

 

因為研發的交付速度需要很快，所以研發人員的流動效率與資源效率理應很高。但實際上，效率是無法都達到百分百的。所以我們提倡提高流動效率，減少浪費，自然可以提高資源效率。

看板正是為我們提供了這樣一個視角，把不可見的需求轉化到視覺化的看板上，把需求的變動轉化為卡片的流動。

看板運作

運作看板首先有一個需求的填充，這個過程在華為被稱為二次填充。從大的流程看，二次填充仍然屬於IPD，但可以限制大的IPD，更好地管理風險。

 

 

第二個是通過看板站會管理流動效率。站會與以往不太一樣，不再關注要做什麼，遇到什麼問題，而是關注卡片和價值的流動。

看板從右向左看，成員更多的關注如何讓右邊的卡片儘快向下流動。在這個過程中儘快解決可能存在的阻塞、瓶頸，其最終目的也是為了讓卡片向下流通。

拉動式開發

拉動式開發是團隊形成自組織非常重要的一點。這也意味著，如果你的團隊想要做到拉動式開發必須是自組織的。在建立拉動式開發時，必須要關注上下游的每一步質量究竟如何，只有下游可以流動，上游才能被拉下來。

 

 

組織者必須具有全域性觀，善於發現問題。

建立規則

這些規則會定製的十分詳細，包括團隊運作看板時的操作規則。例如，看板站會之前，團隊人員會把卡片拖動到正確位置，標記異常情況。

示例

觀察下面看板圖片：

 

 

在運作過程中，我們發現在團隊級看板的AR一級，SDV測試內沒有任何卡片，反而都堆積在Ready For SDV。看起來SDV是一個瓶頸，但實際上這是因為自身流程——批量式轉乘造成的。

回顧改進：從下示意圖中，可以看到批量式互動的累積流程是呈現階梯狀的，散點圖是集中於某一時間交付。

 

 

在回顧改進時，我們制定了改進測試，每週進行小批量的SDV測試。

在有了這樣的小勝利後，團隊的趨勢從上圖變成了下圖。團隊從原來的的批量交付，修改大量缺陷。變成了當前的每週發現問題，每週進行修改。

 

 

困局與破局

在這個版本結束後，看板使用率就大大降低了。和其他團隊溝通後，發現是因為團隊太忙根本沒有時間顧慮看板。

破局一：建立看板的分析請求分配產能

下圖是Muri、Mura、Muda浪費示意圖。

 

 

特別注意Muri、Mura直接導致Muda。Muri系統超載導致任務的切換，任務切換本身就產生很多的浪費。Mura系統的波動性會打亂團隊的節奏，例如突然來一波需求導致系統過載進而產生浪費。

這個團隊Mura情況比較嚴重，除了本身的特性包需求意外，還會有一些需要快速響應的小需求，導致團隊疲於應付。解決方法是把團隊人員分為兩組，一組人做運營快速釋出版本，小需求出現後，以固定的節奏快速釋出。大的需求用火車版本。

美國海軍陸戰隊有句話“慢就是穩，穩就是快”（slow is smooth，smooth is fast）。這和豐田的“均衡化”原則的原理相似，需求進入管道時一定是穩定的，如果不穩定會導致優化大打折扣。

破局二：找回需求

AR只是任務，不能稱作需求。測試是檢測SR，所以我們轉換視角關注到需求上面，採用FO，拉通端到端。

 

 

破局三：減小批量

下圖的瀑布中，總計44天，但編碼只佔用10天，後面20天是沒有任何編碼的。在這樣的情形下，做的需求會較少。

解決措施：按周填充，減少SDV批量，減小SIT批量，加速價值流動，質量保證前移，減少fix時間段，增加編碼實踐，提升吞吐量。

04

Q&A

Q：如何能真正做到減員增效？

A：看板。因為在業界裡面，比較好流動效率才剛20%到40%，所以如果你的流動效率能達到40%，其實你有60%還是浪費的。所以如何不斷的提升流動效率，讓卡片流動越來越快帶動吞吐量提高。只有不斷的把水分給擠掉，這就是減員增效。

Q：華為是怎麼突破精益看板中的坑呢？

A：最大的坑是思維的變化，對於某些看板上展示出的問題不以為然。我們團隊認為要持續改進。持續改進其實已經是改善的結果。

改善要有自我批判的精神，能夠不滿足現狀，能夠有勇氣去改進，然後才會用到相關的工具去做持續改進。在有了這種思維後，才會使用看板。所以首先要改善，其次才是改進。

以上內容來自陳軍老師的分享。

 

更多案例乾貨，可關注“壹佰案例”公眾號獲取。