鑽石舞台

技術中心的年度研發效能報告已於前不久發布，在吞吐的分析中，我們新增了一個指標「標準差」（計算公式見圖1）。

圖1. 標準差計算公式

標準差在概率統計中最常使用作為統計分布程度上的測量。它反映組內個體間的離散程度。標準差越大，表示大部分數值和其平均值之間差異較大，反之亦然。

上面的公式不用記，Excel 中有對應的計算函數：STDEVP（見圖2）。

圖2. Excel 中的標準差函數

常見的數據分析方法包括：趨勢分析、指標下鑽分析、關聯影響分析。而標準差，就是下鑽分析維度的產物。我們的目標是提升吞吐量（即：單位周期交付的需求數量），所以重點關注在「吐」的情況。

然而，利特爾法則指出，過高的在制品數量會影響需求的交付周期，進而影響需求交付效率。故在吞吐量的分析中，我們加上了在制品的分析，引入了對「吞」的觀察（即：單位周期規劃的需求數）。

但是，我們僅僅以自然月為單位周期進行分析，發現規劃需求數和交付需求數只是兩組無規律的波動。僅用周期內發生的需求個數和時間趨勢，難以評價吞吐量是否正常，我們只能看到一張隨月度起伏變化的曲線圖（見圖3）。

圖3. 某研發團隊的需求吞吐量分析

我們希望有個指標或數據統計方式，可以直觀反映出吞吐的「問題」，一方面可以做部門間的橫向對比，另一方面也能提醒我們介入干預。標準差就是這樣一個指標，它適用於分析一組數據，擅長只用一個數值，就可以表達波動幅度的情況，這對任何一支團隊都是適用的。

吞吐標準差，統計了兩個維度的數據：規劃需求波動、交付需求波動。標準差表示，每月新規劃或上線需求數，與平均值的離散程度。標準差越大，每月規劃個數或上線個數越不穩定，對團隊生產秩序的衝擊越大（見圖4）。

圖4. 多個研發團隊需求吞吐波動的對比

在圖4的案例（數據來自年度研發效能報告，挑選了最典型的三條業務線）中，我們有幾個發現：

1. 單純橫向比較這三條業務線的吞或吐，都沒有意義，在團隊規模、需求場景、業務架構等維度上都沒有可比性。

2. 吞（左圖）：業務線C（藍點）的波動性最大，意味着該業務的產品方案輸入最不穩定（這真是個意外的收穫，用研發效能的度量指標也能觀測產品端的生產節奏），對研發團隊的影響最大，可能出現過需求大小月：在小月里可能發生過團隊空轉或承接了持續數月的巨型需求，在大月里則需要投入額外的管理成本和資源來維持生產。

3. 吐（右圖）：業務線B（紅點）的波動性最小，意味着該業務的研發團隊產出最穩定。真實的情況是，該業務線的研發團隊已通過敏捷轉型實現了時間盒內交付的穩定節奏，與此同時，其吞的標準差（左圖紅點）也是最低的（這是不是意味着，敏捷研發模式可以降低生產波動呢？敏捷真是個好東西！）。

4. 吐（右圖）：業務線A（綠點）的研發產出最不穩定，需要進一步介入分析（一般來說，原因會比較多元，本文不做展開），並採取改進措施。

吞吐的標準差可以用于衡量研發團隊的穩定性以及成熟度（敏捷轉型相關），但因為軟件研發不同於工廠製造，無論吞還是吐，每一條需求都會受到功能顆粒度和研發複雜度的影響，故無須追求消除偏差的極致目標。

標準差可用於事前。吐的標準差在一定程度上可以用於指導規劃活動（吞）的開展，對於同一個團隊來說，交付能力（吐）通常是穩定的，規划過多則會造成在制品積壓反而影響交付，適得其反。

標準差也可用於事後。當吐的標準差過大，但總體需求交付數卻不理想時，就需要結合過往需求研發並行程度、需求研發周期等數據，做進一步下鑽分析。

傳統的吞吐量指標，意在觀察團隊是否挖掘了產能極限。但筆者認為，團隊的產能水平通常是恆定的，唯一影響其發揮的因素是「吞」，可通過吞的標準差來評價。而「吐」一方面折射出「吞」的效果，另一方面則是為了滿足需求提出方的體感訴求。

吞吐的標準差指標可挖掘和探索的領域還有很多，如果讀者朋友有更多的相關實踐，歡迎在留言區溝通。

一則物理看板的演進實踐

「研發共建」提升中台效能初探

效能指標「研發濃度」在項目度量中的應用

有贊效能數據賦能實踐

項目制實踐如何助力組織進化

有贊如何打造高績效的千人技術團隊？

敏捷與 OKR：系統思考與組織設計的藝術

大規模產品待辦列表處理策略—需求分級

大規模產品技術團隊需求管理實踐

如果讀者對效能改進也有興趣，歡迎加入有贊效能改進團隊，請將簡歷投遞至：chenyu_yu@youzan.com，我們共同探討和實踐。