10 月 17 日，ONES 出席 2021 全球技術領導力峰會-杭州站（簡稱“GTLC 大會”）。大會上，ONES 研發總監、ONES Core 業務中臺負責人陳亮宇作了題為《漸進式的研發管理改進之路》的演講，與各行各業的技術大咖一起，分享 ONES 的研發效能提升實踐經驗。
以下是陳亮宇演講的主要內容。
研發管理中的噪聲
研發管理是一個龐大的體系，需要從「大處考慮，小處著眼」。在實踐過程中，企業管理者往往會制定大的目標，但在「小處」實施的時候會遇到各種各樣的困難。這些困難的根本原因是整個研發效能改進過程中存在很多「噪聲」。
2002 年諾貝爾經濟學獎獲得者丹尼爾·卡尼曼在其新書《噪聲》中表示，「噪聲」是指決策過程中不必要的隨機變異性。哪裡有判斷，哪裡就有「噪聲」。
研發效能改進的過程中本身會存在很多判斷，自然會產生很多噪聲。而這些噪聲大多是隱形的，你看不到它卻會被它所影響。
以下是研發過程中的三種常見「噪聲」。
第一種是執行預測性決策而產生的「噪聲」。在推動敏捷、DevOps 等管理方法落地的過程中，團隊往往需要進行組織架構的轉型。這是一件風險較大的決策，需要公司管理層的信任與支援，而做這種預測性決策會產生隨機變數。
第二種是目標理解偏差導致的「噪聲」，其中目標理解偏差是比較常見的。例如，企業管理者的 OKR 是「提升研發效能 20% 」，這個目標拆分到不同部門後，測試部門認為要將測試效能提升 20%，而研發團隊認為要將研發效能提升 20%。但其實管理者想要的是實現整個研發流程中端到端的研發效能提升，這就是目標理解偏差上的噪聲。
第三種是主觀情緒變化導致的「噪聲」。研發過程改進通常會改變團隊的工作流程和一線員工的工作習慣。要求一線員工離開自己熟悉的工作方法是一件”反人性“的事情，員工可能會產生一些抗拒感，從而影響改進措施最後完整落地。
由此可見，研發效能改進是由多因素多環節相互影響的複雜活動。《易經》中提到「易則易知，簡則易從；易知則有親，易從則有功」，這一思想可以應用到效能改進落地過程中，化繁為簡，採用簡單的漸進式的改進措施，使其容易被團隊理解、執行，從而減少整個研發效能過程中的噪聲影響。
化繁為簡
漸進式的研發效能改進
研發流程其實是價值流動的過程。我們將研發流程想象成一條公路，研發效能提升就是清除這條路上可能產生的障礙（如道路變窄、交通事故等），避免因為一個道路障礙而產生越來越多的障礙，最終導致堵車。
我們可以利用「約束理論」來進行研發過程中的「道路疏通」。約束理論是指，實際業務中瓶頸節點的節拍決定了整個業務流程，它分為五個步驟，分別是：識別約束、用盡約束、配合約束、突破約束，然後再回到第一步來，進行迴圈改進。根據這個理論，我們可以不斷地識別瓶頸、突破瓶頸，最終實現效能的漸進式改進。
約束理論
以 ONES 團隊的效能改進實踐為例。
ONES 成立了交付團隊以響應客戶的需求，提升客戶滿意度。隨著時間推移，團隊的效能提升出現瓶頸。我們首先想到了增加團隊規模、提高團隊人員素質或者通過引入自動化的流程改善團隊效能。然而上述每一種方法都要求投入大量的資源，甚至可能需要團隊暫停業務進行改進，這並不現實。因此，ONES 採用了漸進式的改進方法。
我們從分析交付團隊的核心困境入手。
首先，ONES 產品矩陣豐富，已經發布了 8 款產品，交付團隊必須完全瞭解所有產品及其細節，否則會導致團隊在做優化需求時，最終產出的產品質量不高。
其次，客戶對需求有預期的交付時間，團隊花費大量時間進行工時預估並給出一個較精準的時間。但由於開發過程中的種種複雜因素導致交付延期，而需求也不斷累積，最後，即使小的優化也需要很長的時間響應，最終導致業務滿意度降低。
再者，客戶的需求數量和需求提出時間具有極大的不確定性，新需求的預估會打斷團隊當前的迭代研發，導致效能降低。
與此同時，在面對大大小小的線上缺陷時，ONES 交付團隊全盤響應，處理缺陷也會打斷研發工作。
為了解決上述問題，ONES 對交付團隊進行了效能分析：
- 需求每月新增 15-20 個，大量的需求在等待研發
- 規模預估每月需要完成 15-20 個，且預估時間半天到一天不等
- 無論是何種缺陷都需要立即響應，經常打斷研發
- 研發完成的需求在開始測試後仍然需要研發投入去修復測試缺陷
改進前：需求週期時間離散
改進前：待研發需求高於釋出需求
綜合分析後，我們最終確定交付團隊效能提升的約束就是研發環節，併為此制定瞭解決方案：
- 設立優化需求的 SLA（服務級別協議）響應等級，以粗略預估替代精準預估，從而大大降低團隊用於需求預估的時間，將更多的資源用於直接產生客戶價值的活動中去。
- 將研發中和研發完成一併設定 WIP（在製品） 限制，減少「接近完成」的需求，從而加速價值流動。
- 設立缺陷的 SLA，嚴重缺陷可臨時突破 WIP 限制。通過看板，我們對缺陷進行優先順序管理，並視覺化地展現缺陷的處理流程和處理情況，讓上下游團隊更清楚地瞭解研發團隊的研發能力，配合研發團隊調整自己的需求的優先順序。
- 每月基於看板召開需求規劃會，和上下游協商 Backlog 中的需求優先順序。
我們對改進措施進行了持續觀測，實施兩三個月後，團隊的需求週期時間新增集中在了 5 天、10 天、20 天，交付時間可預測性增強。同時，待研發需求數量持續下降並穩定在了健康水平，並行的任務也維持在了 2-3 個，研發流程的瓶頸環節得到一定的疏通。
改進後：需求週期可預測
改進後：待研發需求數量
為更大程度地完成疏通，接下來便是突破約束。為此，我們還做了三件事：
- 排查並分析缺陷中的客戶服務問題，成立獨立部門應對，讓研發團隊更專注
- 分離路線圖需求，與上游部門和產品部門協商響應策略
- 擴大團隊規模，提升 WIP 的限制
在漸進式的研發改進實踐中，團隊效能和業務滿意度都得到了明顯的提升。從 ONES 團隊的漸進式效能改進經驗中，我們總結出兩個核心理念：
首先，最大化利用非瓶頸資源只會造成堆積和等待，效能改進需要聚焦疏通瓶頸，讓改進變得落地簡單可執行。
其次，漸進式的研發效能改進能在短期內給團隊正向反饋，從而提升團隊的自驅力。同時也能通過提升需求的可預測性，有效地提升業務的滿意度，建立透明、信任的團隊氛圍。