10 月 21 日上午，在 2021 Qcon 全球軟體開發大會（上海站）上，ONES CTO 馮斌作了題為《大型團隊研發效率持續改進實踐》的主題演講，與眾多行業大咖和從業者分享研發效能提升的實踐經驗。
以下是該演講的主要內容。
根據統計，平均而言，關於大型研發團隊 IT 專案失敗的原因，延期、超出預算、功能不滿足、軟體質量太差等涵蓋了其中的 75%。
因此，如果這幾方面的問題能得到有效解決，那麼，軟體研發的成功率有望大大增加。
結合 ONES 的實踐，我們發現，大型研發團隊面臨以下這些挑戰：
大型研發團隊面臨的挑戰
01 工作效果差異大
由於不同團隊使用不同工具，平臺化方案難統一應用，團隊資料分散，導致團隊協作效率低，整體效能提升難。成績優良的團隊通常依賴若干位專家，但「專家」難以複製到其他團隊。
同時，專案進度是衡量團隊效率的核心指標，需要研發團隊協作推進，然而中大型團隊任務進度的可預測性低。
02 業務滿意度低
在日常工作中，總會有業務部門會質疑研發團隊：這個需求不很簡單嗎？為什麼做這麼久？
這反映了「需求前置時間過長」的問題，即需求從提出到交付的時間過長，無法滿足業務方或客戶的期待。
同時，因為技術風險、緊急事故等各種難以避免的客觀問題，專案進度承諾容易被打破，同時可能導致返工率高，使得團隊怨聲載道。
03 改進措施難落地
改進措施的落地需要所有團隊成員的配合。然而在改進初期，管理者經常遇到這樣的問題：團隊成員認為「我們本來就很忙，還要額外付出時間和精力來改進」？這樣一來，導致團隊認為此事「執行成本高」。
不僅如此，改進常常意味著團隊內部的「改革」，可能會打擊某些人原有的角色或位置，讓團隊成員對改進措施產生質疑，從而導致落地阻力大。而改進的培訓和溝通成本高，尤其是對於中大型團隊而言，需要進行持續的培訓，成本高，見效慢；培訓後的執行效果難以跟蹤。這些因素綜合影響了團隊的改進措施的執行落地。
基於對大型研發團隊所面臨的挑戰，我們認為，研發管理改進必須以「不依賴人的手段」來推進，而是通過制定標準，並將其落地到工具中，實現自動化的管理。
在落地改進之前，我們首先要找出影響研發效率的底層因素是哪些。
影響研發效率的因素
01 工作量與工作節奏
如前所述，專案執行過程中常常因為突發的緊急任務打破研發節奏，造成研發任務的累積。這意味著部分業務部門提出的需求，研發部門遲遲沒有完成，長此以往將形成嚴重的工作量堆積，出現失控的局面。
02 標準的建立與執行
標準是保證團隊規模化的最重要手段。一個有效的標準，應該是一個被清晰定義的工作流程，是被清晰定義的各個環節的完成標準。而且，管理者必須確認團隊是圍繞該標準進行工作的。
03 改進的阻力源
如何讓團隊成員理解並接受改進？
實際上，在改進具體的事情之前，首先應該改變人的認知。而當涉及多個因素的改進時，阻力會加倍，它可能涉及了人、事、工具等方方面面，例如組織架構調整、工作習慣改變、工具落地等。
針對上述的關鍵因素，我們來看看如何有效落地改進？
持續改進落地實踐
改進過程可以採用 PDCA 迴圈理論框架。
PDCA 迴圈又稱戴明迴圈。P-D-C-A 這四個字母，分別代表：Plan（計劃），Do（行動），Check（檢查），Act（處理）。戴明是一位美國的質量管理大師，他認為，高質量，不是來自基於結果的產品檢驗，而是來自於基於過程的不斷改善。後來，他的理念不但被用於質量管理，更被廣泛地用於企業管理領域。
PDCA 迴圈
1 計劃階段
如何改變人的認知？專案的視覺化是第一步。
科學的資料視覺化能夠直接給團隊反饋，為理性分析提供依據，為感性認知提供視覺印象。
下圖是 ONES 報表中顯示的團隊需求週期時間分佈圖，這是一個高度離散的分佈圖，說明了需求的交付時間可預測性很弱。
需求週期時間分佈圖
另一個「狀態趨勢圖」則表明了團隊的待研發需求一直在不斷增加，然而釋出的速度卻跟不上待研發需求的速度，最終可能導致團隊需求累積，降低研發效率。
狀態趨勢圖
而持續視覺化需要線上化、結構化工作內容。以使用者故事的管理為例，通過 ONES 研發管理工具，管理者能夠根據團隊實際場景，自定義配置使用者故事欄位，供執行人員填寫，從而保證研發資料被結構化地記錄，便於後期進行資料視覺化的效能分析。
結構化工作內容
此外，計劃階段還需要限制並行的任務數量，找到流程中的瓶頸；並識別不同的工作流程，在組織架構和人力投入上進行隔離，保證資源高效利用。改進時如果遇到多個阻力因素，應優先選擇影響因素少的細節開始改進，這樣做的好處是能夠快速給到團隊正向反饋，提升團隊對改進的信心——前提是，管理者對團隊的全域性待改進情況有系統的認知。
例如通過看板工具可以直觀地瞭解到該團隊的「待研發任務」很少，但「研發中」、「待測試」、「測試中」的任務堆積，此時管理者則需要調整資源，疏通阻塞。
ONES Project 看板檢視
2 執行階段
首先，建立一個簡單、容易被理解的標準——該標準更容易被認可和落地執行。
一個簡單的標準並不需要覆蓋儘可能多的場景，大而全的標準反而容易導致標準落地困難，簡單的標準覆蓋 90%的場景即可。標準並不是告訴大家工作的「所有」工作是什麼，而是「至少」要做到什麼。
其次，利用工具數字化工作流程，內嵌完成標準。「內嵌」是指將團隊中各個角色的工作及狀態流轉規則落地到工具中，以減少人為因素的干擾和噪音導致的偏差。
ONES Project 工作流引擎
再次，鼓勵團隊使用工具展開日常工作，以實現研發過程真正地按照標準執行。
最後，利用工具儘可能地實現自動化。如圖，顯示了一個經典的需求和任務狀態聯動的自動化流轉。當關聯同一需求的多個子任務都完成時，則該需求自動完成。
ONES Project 自動化引擎
從這裡我們可以看出，這些做法的好處是：通過工具引導團隊以標準高效地完成工作。
3 分析階段
改進措施落地後，管理者需要持續進行效能資料的監測。
例如，對比改進前後的「需求週期時間分佈圖」可分析出，改進後團隊的需求週期時間集中在 20 以內，證明團隊的需求交付可預測性變強了。
（左）改進前 （右）改進後
又例如下圖的「狀態趨勢圖」，可以看到改進後，團隊釋出的需求逐漸增多，而新增的需求不斷消耗，證明研發效率明顯提升。
（左）改進前 （右）改進後
4 調整階段
標準並非一成不變的，而是需要定期覆盤，以保證標準在團隊發展變化的過程中有更好的適應性，而覆盤結果則匯入到下一迴圈中進行規劃。
最後，對以上內容做兩點總結：
一、改進效率，要關注工作量的安排、是否有簡單清晰的工作標準、從單個因素入手。
二、工具落地標準化，有助於持續大範圍落地標準和視覺化，進而達到持續改進的狀態。