下圖是一個某研發(fā)團隊近半年的數據，您看到這三張圖尤其是框了紅色的部分，會得到什么樣的信息呢?大家可以先看一下然后再往下面去看我對這些數據的認識。

??

根據上面這三張圖的數據，我們可以得到的關于這個團隊的信息是：

(1)3月份完成的需求數量是最多的，比其它***的月份也要高40%左右。

(2)3月份的缺陷數也是各個月份***的。

(3)3月份線上發(fā)布的成功率是***的。

結合3月份這個對于我們阿里很特別的日子，我們可以大膽做一些推測：這個月份我們研發(fā)人員的負載其實是相當重的，大家可能會去趕工完成更多的工作(需求)，趕工干活可能引起的副作用就是質量上的下滑，增多了很多的缺陷數和下降了不少的發(fā)布成功率也是印證了這一點。

so數據是會說話的，那我們該怎么去聽它說話呢?如果你覺得，哎呦，這個挺有意思，那么，就讓我?guī)е阕咭槐槿绾卫迷菩系倪@些研發(fā)數據，去了解團隊現狀、發(fā)現團隊中可能存在的問題、再結合團隊具體實際情況去做調整和改進，從而達到提升團隊整體效率和質量的目標。

前言

先表示感謝和敬意：本文中所有數據都來自云效度量數據功能頁面截圖(部分數據功能云效暫未開放給所有用戶，所以截圖會有些許區(qū)別)。我會在本文就各種具有關鍵表征的數據進行介紹，但是詳細數據包括您的研發(fā)團隊的數據，還是需要您親自訪問云效公有云度量功能頁面。

我是傳送門：??https://rdc.aliyun.com/my/metric??

這個推導我深信不疑：團隊效率高，質量好-> 數據表征好

于是我也是充分的利用了云效公有云度量功能，加之以偷師學來的敏捷部分方法指導，實踐于某事業(yè)部幾十號人的團隊，3月有余，所沉淀下來的一些asset，以及取得的成果，希望能有一些借鑒意義給到大家。

數據展現

先直接給大家數據，我是4月份開始進入這個團隊的。大家重點看這個團隊3月份的數據：

??

??

問題分析

上面幾張圖比較容易看出來，其實跟引子里面提到的情況差不多，這個團隊明顯特征是

(1)3月份完成需求數明顯上升，且團隊負載較重

(2)質量不高 - 缺陷數、reopen率以及線上發(fā)布成功率

(3)需求平均完成時長特別長 ，很多需求都是很久之前的3月份才完成

(4)突增故障

于是我們帶著數據暴漏出來的這幾個問題走進了團隊，和團隊一線研發(fā)人員、PD、TL都進行了溝通，并把數據展現給他們和大家一起去分析數字背后的意義，大家比較快的達成了一致，發(fā)現團隊存在的主要問題是：

(1)需求deliver傳統(tǒng)瀑布模型，要1個半到2個月去完成一個特別大的需求，***卻和用戶期望偏差較大，數據表征上就是之前需求數量較少，3月份突然完成了很多而且時間很長的需求。

(2)大家加班加點的干活，負載較重，引入的缺陷也較多，PD和用戶不滿意帶來的修改又會加重工作量，如此惡性循環(huán)。

(3)缺陷重視度不高，管理不規(guī)范，優(yōu)先級劃分不清楚，甚至殘留重要缺陷留在bug列表里面未解決而流到了線上引發(fā)故障。

上面三點相當于形成了個閉環(huán)，惡性循環(huán)，其結果就是，越做越多，越多越錯，越錯越改，越改越多。

解決方案落地和數據運營

發(fā)現了大家的問題之后，有針對性的進行解決和落地就相對容易，給到團隊的解決方案是：

(1)需求細化，拆分成最小可交付產出，盡量避免一個需求做了1個多月才去和PD和用戶驗收。

(2)隨時擁抱用戶，迭代式產出，交付即驗收，讓不準確性降到***，在錯誤誤差最小的時候修正。

(3)重點跟進質量管理和運營，透明數據，鼓勵團隊盡早盡快修復bug，并有嚴格的上線前bug解決率標準。

(4)盡***力量保證線上發(fā)布成功率。

同時輔助于團隊的決策，我們進行定期的數據運營，每周都會去統(tǒng)計和分析數據，包括質量和效率相關的，確保我們能在***時間發(fā)現問題，糾正偏差，所以我這邊在整個3個多月的過程中，重點關注了如下的數據，這些數據都在云效上可以得到，云效還包括別的較為豐富的數據，期間如果別的數據反應或者暴漏了問題，我也會納入進來進行整體分析，關于這些數據的解讀和分析，其內容也比較深入，可以專門開一篇文章來講了，我這里只做簡單的概括性介紹：

(1)需求的吞吐量 - 團隊指定時間段內完成的需求數，可大體反應出團隊的產出趨勢。

(2)需求的平均完成時長 - 需求從創(chuàng)建到終態(tài)的平均時長，時間越多，需求交付粒度越小效率越高。

(3)新增缺陷的數量 - 統(tǒng)計時間段內團隊被新增指派的缺陷數量，結合存量缺陷以及缺陷平均解決時長，反應團隊產品的質量以及對于缺陷解決的效率。

(4)缺陷的平均解決時長 - 缺陷從創(chuàng)建到解決的平均時長，表征解決缺陷的效率。

(5)線上發(fā)布的成功率 - 線上發(fā)布成功次數與總次數之比，越高證明產品上線質量越高。

(6)缺陷的reopen率 - 缺陷被reopen的次數與缺陷數目之比，該值越高證明修復缺陷的質量越差，reopen率是表征產品質量的一個重要指標。

結果分析和總結

大家回到上面的6張圖以及下面的一張缺陷解決時間圖，我們3月底進入，重點看從4月份開始的數據：

(1)團隊的負載得到了控制，需求的完成數下降了，后續(xù)3個月保持一個相對平穩(wěn)的狀態(tài)。

(2)需求細化拆分后，交付的時長下降了，團隊以更快的速率去和用戶交付需求。

(3)缺陷的數量下降，reopen率下降，線上發(fā)布成功率上升 - 質量上在好轉。

(4)缺陷的平均解決時間明顯上升，團隊更快的交付，更快的反饋問題，更快的解決問題。

??

總體而言，就是需求交付的快，得到的反饋快，修正錯誤/缺陷的成本低，缺陷也會慢慢收斂，質量也會隨之提升，缺陷修復的也快了，這就是一個良性循環(huán)，概括總計就是：效率提高了，質量也保證了。團隊的人干活也是更加努力啦!~

進一步提升

根據對需求數量以及平均完成時長的數據顯示，團隊還是有上升空間的，對于需求的交付粒度和速率上，還是略顯波動，要想更快的知道我們做的是否是用戶需要的，就要快速的、迭代式的交付需求，以免用戶想要個車，我們給他了個4個輪子。所以能否徹底解決此團隊需求的交付和用戶期望偏差的問題，還是需要再向前走一步，需求繼續(xù)細化，提升交付速率。 參見敏捷中推薦的，快速迭代，快速交付，快速得到用戶反饋，只為了更快更準確。

總結

數據有魅力，研發(fā)數據也一樣，我們使用它就是為了兩個目的：一是保證質量;二是確保交付的速率。行走過程中深度使用了云效度量新功能，結合敏捷中部分理念，配合傳統(tǒng)測試方式保障，來助力研發(fā)團隊。

可能有的人會質疑，說用這么冰冷冷的數字的數字去衡量我們可愛的程序員哥哥嗎? 我的回答是：這不是衡量，數據只是手段，是幫助我們去診斷團隊的一個切實有效的手段。學會利用它并駕馭它。因此只需要我們：

1. 關注數據，讀懂數據

2. 重點問題，重點解決，優(yōu)先解決，一段時間只關注一個或很少的幾個問題

3. 相信團隊的自驅能力，同時結合TL的管理與激勵，養(yǎng)成良好的團隊建設力

***

研發(fā)團隊那點事，每天打交道最多的就是需求、缺陷、代碼、發(fā)布、應用、測試等等，這些和我們研發(fā)人員息息相關的數據，云效所擁有的，現在以研發(fā)大盤、團隊空間、人員效能、質量分布等多種維度整合到了數據平臺上，后續(xù)更會以定制化的方式滿足研發(fā)團隊對于研發(fā)數據的需求。利用好這個工具，能幫助我們清晰的了解團隊的現狀，暴漏問題，找到改進措施，去提升團隊效率和產品質量。

我是一個敏捷愛好者，在深入研發(fā)團隊做測試以及質量管理時候，也是吸取和借鑒了敏捷的部分思想去落地，我的感受是：拿最切實有用的來，比如站會，比如看板，比如快速迭代式交付需求，再加上數據輔助，都是能切實幫助到團隊更快、更準確的交付高質量產品的手段。

***的***

絮絮叨叨說了很多，***貼幾張我在度量上截的某研發(fā)團隊的數據展示，這個團隊是我們最近接觸的團隊，通過數據我們對這個團隊的推測是：團隊在質量上需要提升，在缺陷的管理上需要加強。首先團隊缺陷的數量逐月上升，這已經是質量不好的趨勢體現，另外缺陷的解決時間也沒有加快，這樣會導致越來越多的缺陷流到線上去，可見團隊除去1月份無故障，后續(xù)幾個月都有故障。而且這個團隊的線上發(fā)布成功率持續(xù)走低，開發(fā)對自己上線的代碼把控程度較低。 所以，找到這些數據表征的背后原因，并且著手去解決掉，是這個團隊近期最迫切的事情了。

??

養(yǎng)成良好的研發(fā)習慣，保持高效的團隊協(xié)作，應該作為每個研發(fā)同學持之以恒的追求。

作者簡介：張冠楠，阿里巴巴技術專家，負責過阿里巴巴集團運維系統(tǒng)、研發(fā)中臺系統(tǒng)以及阿里云持續(xù)發(fā)布系統(tǒng)的質量保障工作，致力于如何保障研發(fā)團隊產品質量，同時提升研發(fā)團隊的研發(fā)效率。在質量保障體系建設、持續(xù)集成領域、敏捷實踐領域和研發(fā)效能領域方面均有研究。

【本文為51CTO專欄作者“阿里巴巴官方技術”原創(chuàng)稿件，轉載請聯(lián)系原作者】

??戳這里，看該作者更多好文??