隨著信息技術(shù)深入應(yīng)用，企業(yè)的IT組織效能提升與數(shù)字化轉(zhuǎn)型需求越發(fā)迫切。9月起，嘉為藍鯨《研效一體，價值釋放》線上課程直播，針對企業(yè)IT部門DevOps落地實踐分六期詳解項目管理、制品分發(fā)、持續(xù)交付、測試管理、研發(fā)效能洞察、價值流管理場景。

11月9日，嘉為藍鯨DevOps咨詢顧問段亞浩帶來《企業(yè)如何量身打造研發(fā)效能數(shù)據(jù)洞察體系》的主題分享，圍繞以下幾點，深入探討如何為企業(yè)量身打造研發(fā)效能數(shù)據(jù)洞察體系，幫助企業(yè)管理層和研發(fā)團隊更好地理解和應(yīng)用數(shù)據(jù)，提高研發(fā)效率。

• 如何設(shè)計有效的、合適的度量指標體系？
• 在度量體系落地的過程中，我們會遇到哪些問題？如何解決？
• DevOps成熟度三級對研發(fā)效能度量提出了哪些要求？

01. 為什么要做研發(fā)效能度量？

如果你無法度量它,你就無法改進它（If you can’t measure it, you can’t improve it）—— 彼得 ? 德魯克

研發(fā)過程如同黑盒，往往缺乏可見性。通過采集研發(fā)過程中產(chǎn)生的客觀數(shù)據(jù)，并將數(shù)據(jù)轉(zhuǎn)換為關(guān)鍵的度量指標，能夠幫助管理者發(fā)現(xiàn)研發(fā)過程中存在的問題點和風(fēng)險點，并為后續(xù)的持續(xù)改進提供決策方向。

02. 找準四個關(guān)鍵，輕松設(shè)計度量指標

目前很多企業(yè)在做指標體系設(shè)計時，指標通常來源于員工以往工作經(jīng)驗的積累、公眾號文章的推薦、效能大會上的分享，通過這些方式得到的度量指標往往只是簡單的堆砌，缺乏對指標的用途、意義和指標間的關(guān)聯(lián)的清晰解釋。指標看似很多，卻達不到最終期望的度量效果。

嘗試找到度量的根本目的，能夠幫助我們找到有效的、合適的度量指標，場景化地度量研發(fā)過程。下面請回答一個問題：“這些指標是為了幫助什么角色解決什么問題？”基于上面的問題，在設(shè)計指標的時候，我們可以抓住四個關(guān)鍵詞“角色-問題-步驟-指標”，指標又可以通過“多（數(shù)量）-快（效率）-好（質(zhì)量）-省（成本）”四個方面進行拆解。下面舉一個例子：

基于上述的指標拆解方法，最終可以得到面向“高層-中層-基層”的不同主題指標，這些指標能夠回答上面的問題：“這些指標是為了幫助什么角色解決什么問題？”然而雖然我們知道了這些指標能夠解決的問題，但是若某個指標數(shù)值出現(xiàn)異常，該以什么路徑追蹤原因？

• 橫向關(guān)聯(lián)指標：串聯(lián)觀察整個研發(fā)過程
• 縱向?qū)Ρ戎笜耍?/strong>深度關(guān)注重點維度情況

以上圖為例，若研發(fā)停留時長過長：

• 橫向分析（考慮關(guān)聯(lián)步驟中是否有異常情況）：是否需求調(diào)研停留時長過短反映需求調(diào)研不清晰、研發(fā)階段返工多？
• 縱向分析（考慮各維度間的相互影響）：是否因并發(fā)任務(wù)數(shù)多導(dǎo)致研發(fā)任務(wù)堆積，或是代碼質(zhì)量差導(dǎo)致的研發(fā)效率低下？

通過上述方法拆解的指標，擺脫了簡單地堆砌。該用什么指標進行度量，指標能幫助誰解決什么問題，指標關(guān)聯(lián)關(guān)系如何解讀就都清楚了。

03. 巧用配置化工具，快速建成度量體系

度量指標從設(shè)計到落地，還需經(jīng)歷一系列“數(shù)據(jù)獲取->數(shù)據(jù)處理->數(shù)據(jù)呈現(xiàn)->權(quán)限管控”的過程。但在建設(shè)過程中，可能會遇到下面的問題：

下面通過實際的案例說明度量平臺在建設(shè)過程中常見的問題及推薦的解決辦法。

1）案例一

某集團的多個科室同時使用多套系統(tǒng)，包括自研的項目管理平臺、需求管理平臺，還有從第三方采購的集成工具、代碼庫管理工具等。數(shù)據(jù)散落在各個平臺，需求數(shù)據(jù)展示在需求管理平臺、代碼數(shù)據(jù)呈現(xiàn)在代碼平臺上，指標數(shù)據(jù)由各個系統(tǒng)維護，查看數(shù)據(jù)的時候需要打開并登陸多個系統(tǒng)。此時某集團提出希望在同一界面查看來自多個系統(tǒng)的度量數(shù)據(jù)。

痛點分析

• 數(shù)據(jù)存儲分散，數(shù)據(jù)由多個系統(tǒng)分別維護
• 重復(fù)登錄多個平臺查看數(shù)據(jù)，操作步驟繁瑣
• 指標關(guān)聯(lián)性差，查看全生命周期數(shù)據(jù)需要反復(fù)切換平臺
• 已有數(shù)倉，部分數(shù)據(jù)已存入現(xiàn)有數(shù)倉
• 部分數(shù)據(jù)通過接口形式返回，預(yù)覽數(shù)據(jù)時常卡頓

解決方法

構(gòu)建統(tǒng)一的大數(shù)據(jù)倉庫/數(shù)據(jù)湖，構(gòu)建統(tǒng)一的度量平臺。大數(shù)據(jù)倉庫提高供點強大的計算能力，解決了數(shù)據(jù)預(yù)留卡頓的問題。

2）案例二

某銀行，根據(jù)組織架構(gòu)劃分為“大數(shù)據(jù)部門-研發(fā)部門-科技管理部門-業(yè)務(wù)服務(wù)部門”，度量體系建設(shè)初期存在的主要矛盾是：業(yè)務(wù)服務(wù)部門覺得科技管理部門的需求交付周期太長，科技管理部門覺得研發(fā)資源不夠用。

通過代碼實時計算統(tǒng)計結(jié)果進行呈現(xiàn)，計算效率不高，系統(tǒng)容易崩潰。為了保證系統(tǒng)可用性，需要大數(shù)據(jù)部門對每個指標提供一張事先計算好的聚合表（事先計算好結(jié)果，研發(fā)直接讀取大數(shù)據(jù)部門的結(jié)果進行展示）。

痛點分析

• 指標開發(fā)周期長，且每次修改都需要投入研發(fā)人員
• 研發(fā)資源消耗多
• 數(shù)據(jù)處理工作量大，數(shù)據(jù)表復(fù)用性差
• 指標公式變更，需重新排期進行修改，定開無法適應(yīng)統(tǒng)計口徑的快速調(diào)整
• 每次修改指標都需要發(fā)版，無法做到無感和改動實時生效

解決方法

利用大數(shù)據(jù)倉庫的計算能力，使用明細表數(shù)據(jù)配置指標，指標配置實時生效，無需發(fā)版。原方案單個指標定開需要2.5人天；新方案單個指標配置小于0.5人天。

3）案例三

某公司部門眾多，不同部門間的業(yè)務(wù)相互隔離，因此希望精細化地管控權(quán)限。該公司組織架構(gòu)調(diào)整頻繁，只要有新成員加入或人員項目調(diào)整，就需要手工重新修改權(quán)限，耗時費力，因此迫切地希望簡化權(quán)限配置工作。

痛點分析

• 需要對用戶可預(yù)覽點數(shù)據(jù)范圍進行精細化管控，實現(xiàn)數(shù)據(jù)權(quán)限控制
• 組織架構(gòu)或人員的流動，都需要重新授權(quán)，重復(fù)工作費時費力

解決方法

使用用戶標簽表進行授權(quán)。權(quán)限讀取用戶標簽表數(shù)據(jù)，用戶標簽表定時同步第三方系統(tǒng)數(shù)據(jù)，數(shù)據(jù)標簽表數(shù)據(jù)更新后權(quán)限即自動更新，無需重新配置。

04. 信通院DevOps成熟度評級

1）對效能度量提出的要求

在搭建度量體系及度量平臺后，企業(yè)最終需要在實踐中檢驗落地成果，可參考信通院推出的DevOps持續(xù)交付三級標準中對研發(fā)效能度量提出的要求。下面內(nèi)容是在協(xié)助客戶過級的過程中總結(jié)的經(jīng)驗，為有過級需求的企業(yè)提供參考：

其中：

• 指標全面，需要覆蓋全流程（需求-研發(fā)-測試-部署），以便觀察研發(fā)過程中的各種情況。
• 指標數(shù)據(jù)準確，統(tǒng)計口徑清晰，指標上支持查看統(tǒng)計口徑。
• 具備跨領(lǐng)域指標，如：千行代碼質(zhì)量缺陷等。
• 指標具備輔助線或參考值，通過數(shù)據(jù)對比反映數(shù)據(jù)情況。
• 對指標進行版本管理，定期剔除舊指標，加入合適的新指標。
• 自動收集數(shù)據(jù)形成報告，并發(fā)送給相應(yīng)的干系人。
• 考慮數(shù)據(jù)重要性、數(shù)據(jù)增長量，建立歷史數(shù)據(jù)清理機制。

下面通過幾張圖簡單呈現(xiàn)部分DevOps三級標準在實際應(yīng)用中的效果：

以下為部分過級建議指標，按照全流程、多維度方式進行展示。實際使用過程中的具體指標還需結(jié)合實際業(yè)務(wù)場景進行梳理。

希望通過本期內(nèi)容，能對企業(yè)管理者和研發(fā)團隊提供幫助。