漸進式的研發管理改進之路
2002年諾貝爾經濟學獎獲得者丹尼爾·卡尼曼在其新書《噪聲》中表示，「噪聲」是指決策過程中不必要的隨機變異性。哪里有判斷，哪里就有「噪聲」。
研發效能改進的過程中本身會存在很多判斷，自然會產生很多噪聲。而這些噪聲大多是隱形的，你看不到它卻會被它所影響。
以下是研發過程中的三種常見「噪聲」。
第一種是執行預測性決策而產生的「噪聲」。在推動敏捷、DevOps 等管理方法落地的過程中，團隊往往需要進行組織架構的轉型。這是一件風險較大的決策，需要公司管理層的信任與支持，而做這種預測性決策會產生隨機變數。
第二種是目標理解偏差導致的「噪聲」，其中目標理解偏差是比較常見的。例如，企業管理者的 OKR 是「提升研發效能20% 」，這個目標拆分到不同部門后，測試部門認為要將測試效能提升20%，而研發團隊認為要將研發效能提升20%。但其實管理者想要的是實現整個研發流程中端到端的研發效能提升，這就是目標理解偏差上的噪聲。
第三種是主觀情緒變化導致的「噪聲」。研發過程改進通常會改變團隊的工作流程和一線員工的工作習慣。要求一線員工離開自己熟悉的工作方法是一件”反人性“的事情，員工可能會產生一些抗拒感，從而影響改進措施最后完整落地。
約束理論
以團隊的效能改進實踐為例。
成立了交付團隊以響應客戶的需求，提升客戶滿意度。隨著時間推移，團隊的效能提升出現瓶頸。我們首先想到了增加團隊規模、提高團隊人員素質或者通過引入自動化的流程改善團隊效能。然而上述每一種方法都要求投入大量的資源，甚至可能需要團隊暫停業務進行改進，這并不現實。因此，我們采用了漸進式的改進方法。
我們從分析交付團隊的核心困境入手。
首先，交付團隊必須完全了解所有產品及其細節，否則會導致團隊在做優化需求時，最終產出的產品質量不高。
其次，客戶對需求有預期的交付時間，團隊花費大量時間進行工時預估并給出一個較精準的時間。但由于開發過程中的種種復雜因素導致交付延期，而需求也不斷累積，最后，即使小的優化也需要很長的時間響應，最終導致業務滿意度降低。
再者，客戶的需求數量和需求提出時間具有極大的不確定性，新需求的預估會打斷團隊當前的迭代研發，導致效能降低。
與此同時，在面對大大小小的線上缺陷時，交付團隊全盤響應，處理缺陷也會打斷研發工作。
為了解決上述問題，我們對交付團隊進行了效能分析：
-
需求每月新增 15-20 個，大量的需求在等待研發
-
規模預估每月需要完成 15-20 個，且預估時間半天到一天不等
-
無論是何種缺陷都需要立即響應，經常打斷研發
-
研發完成的需求在開始測試后仍然需要研發投入去修復測試缺陷
-
設立優化需求的 SLA（服務級別協議）響應等級，以粗略預估替代精準預估，從而大大降低團隊用于需求預估的時間，將更多的資源用于直接產生客戶價值的活動中去。
-
將研發中和研發完成一并設置 WIP（在制品） 限制，減少「接近完成」的需求，從而加速價值流動。
-
設立缺陷的 SLA，嚴重缺陷可臨時突破 WIP 限制。通過看板，我們對缺陷進行優先級管理，并可視化地展現缺陷的處理流程和處理情況，讓上下游團隊更清楚地了解研發團隊的研發能力，配合研發團隊調整自己的需求的優先級。
-
每月基于看板召開需求規劃會，和上下游協商 Backlog 中的需求優先級。
我們對改進措施進行了持續觀測，實施兩三個月后，團隊的需求周期時間新增集中在了5天、10天、20天，交付時間可預測性增強。同時，待研發需求數量持續下降并穩定在了健康水平，并行的任務也維持在了2-3個，研發流程的瓶頸環節得到一定的疏通。
改進后：需求周期可預測
改進后：待研發需求數量
為更大程度地完成疏通，接下來便是突破約束。為此，我們還做了三件事：
-
排查并分析缺陷中的客戶服務問題，成立獨立部門應對，讓研發團隊更專注
-
分離路線圖需求，與上游部門和產品部門協商響應策略
-
擴大團隊規模，提升 WIP 的限制
在漸進式的研發改進實踐中，團隊效能和業務滿意度都得到了明顯的提升。從 團隊的漸進式效能改進經驗中，我們總結出兩個核心理念：
首先，最大化利用非瓶頸資源只會造成堆積和等待，效能改進需要聚焦疏通瓶頸，讓改進變得落地簡單可執行。
