0、引言

“效率”作為得物技術部的關鍵詞之一，大家在研發效能、會議效率、協作效率、辦公效率等方面一直進行著持續地探索。在實際落地的過程中，為了更好地評估應用效果，往往需要將定性描述轉換為可量化的數據指標。這些數據指標可以幫助我們了解研發過程中的變化和趨勢。但是你真的能“讀懂”這一堆冷冰冰的數字嗎？

在看到這些數據指標時，我們往往很容易陷入一個誤區：只關注具體的數字，而忽視了數據采集和分析解讀的過程。這意味著即使我們對這些指標進行了定期監控，我們仍然不能真正了解研發過程中的狀況和障礙。

因此，如何正確地解讀這些數據指標變得尤為重要。為了有效解讀數據，我們需要了解數據來源和分析過程，以及數據指標與業務實際情況之間的關系。只有這樣，我們才能更好地理解我們所面臨的問題和挑戰，并且采取適當的措施來加以解決。

1、研發數據從哪里來

第一階段：人肉統計 

當我們從0到1定義一個新流程、新數據指標時，通常是處于探索驗證的階段，這個時候通常不會耗費過多人力來搭建線上化的系統，導致數據采集的過程十分痛苦，文檔、表格、甚至群聊等五花八門的數據來源，不少同學應該有親身體會。

第二階段：分散、未經處理的系統數據

技術部全鏈路的研發過程數據往往分散在多個內部系統中，當你需要分析某個數據的時候，可能會涉及到不同系統之間的交互，而各個系統由于數據維度、統計口徑的不同，必須先梳理清楚數據背后對應的邏輯，其次再進行數據清洗、關聯業務線/部門等統計維度，最終形成可用的數據源。除此之外，一旦涉及到某個系統的改造/數據加工，想要獲取到可用的數據更是難上加難。

第三階段：流程不規范，導致數據不可用

這是系統建設中最常見的問題，由于系統沉淀的數據強依賴用戶操作，如果在流程中沒有規范化的操作方法及卡點管控，就有可能造成數據不可用。最典型的例子就是項目管理軟件中需求/任務的狀態流轉，會出現任務長時間處于未開始狀態、長時間滯留在進行中、任務完成但是消耗的工時為0等各種異常場景。

第四階段：成熟階段

工具一體化，流程規范化，數據標準化。效能度量和項目管理人士心馳神往的階段，這個階段要流程有流程、要系統有系統、要數據有數據，無需耗費大量精力來獲取數據和處理數據。

2、數據指標之略問一二

大數據時代，萬物皆可數據化。在研發過程中，沉淀下來的數據可以定義出種類繁多的數據指標，基于這些數據，我們往往會耗費大量人力打造出一個數據指標大盤，甚至美其名曰“駕駛艙”。雖然我們的理想絕不僅限于擁有數據大盤，但現實很骨感，殘酷到“你以為的起點竟變成了你的終點”，沒錯，數據大盤可能是大部分團隊的終點，它具有取數、看數以及基礎的可視化圖表，值得注意的是，面對五花八門的指標，我們稍不注意就會迷失了方向。

2.1 你知道X指標的定義是什么嗎？

看到這個問題，很多人認為沒有難度，不需要太多思考就可以列出具體的公式和取數邏輯，但是真正想問你的不僅僅局限于此，更深入一步的問題是：你知道X指標為什么這樣定義嗎？想要通過它來衡量什么？

在軟件研發領域，提到研發數據就不得不提研發效能度量，后者在各路大神的研究及科普下已經逐步走向成熟，與此同時也沉淀出很多業內通用的研發效能指標。但如果你僅僅是生搬硬套指標定義，而不去深入理解指標背后隱藏的業務目標，你會發現最終的結果往往不盡人意。所以我們要知其然，還要知其所以然，當你在使用或定義一個數據指標時，必須要清楚地知道度量X指標的真正目標，想要發現或改進什么問題，避免變成純純的數字游戲。

2.2 你知道最核心的指標是哪個嗎？

在幾十個數據指標中，你能分辨出哪個指標最重要嗎？看到這里，你可能在仔細對比各個指標的重要性，但是，

這是個帶有誤導性的問題，在我看來，沒有最核心的指標，只是不同的領域會有相對核心的指標。想想新廣告法開始限制“最”、“第一”這種詞語的使用，是不是感覺也挺合理？這些形容詞是需要基于真實場景的，同時又會因為所處階段不同，導致你關注的指標也會發生變化，就像OKR一樣，不同的時期你會設立不同的O，自然就會有不同的KR。

舉個例子：

• 公司在Q1要快速擴張，它對應的KR可能會包含DAU、GMV等指標
• 公司在Q2要提升體驗，它對應的KR可能有NPS、秒開率、工單解決工作時長等指標。

參照OKR的概念我們也能發現，我們要從一堆指標中篩選出你真正關注的指標，而不是所有指標一手抓。

3、不解讀 或 無效解讀 = 毫無意義

篩選出了核心指標后，就需要來合理地解讀指標。數據指標分成過程指標和結果指標，結果指標只能告訴你好壞，通常需要參照和它相關的多個過程指標來進行歸因。

對于大多數人來說，我們不是專業的數據分析師，即使是長期在項目管理和研發效能領域工作的專家，可能在數據分析方面的能力也有所欠缺，所以如何解讀數據指標就成了一個難題。

如果你不解讀數據指標，直接把一堆指標丟到用戶面前，用戶看了半天，沒看出指標的好壞，也不知道要不要改進，更不清楚如何改進，最終只能是一臉茫然。

如果你用數學的方式進行了無效解讀，比如需求吞吐率下降，解讀為團隊承接的需求數減少（分子），而提報的需求數增加（分母），這就屬于無效解讀，這個結論幾乎沒有價值，需要進一步挖掘分子減少和分母增加的根因。

所以，我們要通過數據指標解讀出關鍵性的結論，告訴用戶存在的問題及改進的方法，只有這樣你的指標才是有價值的，否則空有指標，啥也不是。

4、解讀數據指標的幾個步驟

度量數據指標不是目標，只是實現目標的手段。我們希望可以從中獲得有價值的信息和結論，從而指導實際的業務決策。碰巧之前數據團隊的大佬來團隊普及數據分析的基礎知識，提出了“可量化、可解釋、可干預”的觀點，此處正好把想問的三個問題分別對應到其中：

圖片

第一層：基礎

可量化：我們希望通過客觀的數據指標來描述現象，就需要明確數據指標的定義，確定其和業務目標的對應關系，判斷指標的適用性，以及在不同場景下的不同意義。

第二層：分析

可解釋：就是讓通過分析數據指標得到的結果，能夠被用戶理解。在開始正式工作之前，我們先熟悉下列幾個問題，因為接下來的工作，主要都是圍繞著這些問題進行的：

• 指標對應的數值是好還是壞？有沒有基線標準？跟基線相比是好是壞？
• 跟自己比趨勢是變好了還是變壞了？是正常波動還是異動？

帶著問題，接下來進入正式的研發數據分析流程：

1. 數據采集及清洗：獲取到高置信度的數據，同時可能會使用表格或者可視化的圖表來展示數據

2. 選取特定的維度，如業務線、部門、個人等維度，得到相應的數據；同時選定基線，得到基線的數據。根據這些數據，我們可以得出指標對應的數值是好還是壞的結論

3. 使用基礎的統計學方法，如對比分析、趨勢分析等方式對數據指標進行分析，通過橫向對比及歷史趨勢數據的對比，得出趨勢變好還是變壞的結論。與此同時，我們還需要分析出指標是正常波動還是異常波動

4. 如果上一步的數據指標是異常波動，則可以對關聯指標進行分析，舉例：我們發現研發交付周期數據發生異動，同時發現與它相關的需求變更率、缺陷引入率指標都發生了異動，此時可以通過相關過程指標進行下一步分析

5. 通過具有相關性的過程指標來分析主要影響因素，最終定位指標異動的根因。

至此，我們成功定位了指標異常波動的根因，這也預示著第二步的完成。在實際分析的過程中，此階段往往是最為耗時的階段，值得注意的是，我們通常不會將整個分析的過程體現到最終的分析報告中，雖然其復雜耗時，但對大多數用戶來說，更加關注的是結論而不是過程。

第三層：價值

可干預：通過適當的方法來改進我們歸因發現的問題。辛苦了半天，定位到了數據指標異動的根因，但是這并不意味著結束，接下來還有更重要的一步，這一步能體現你對業務的思考，體現你這份分析報告的真正價值，剛剛讓我們辛苦了半天的分析過程，也要靠它贏回票價。

• 首先，需要評估指標異常波動帶來的影響，以及關聯指標異常波動帶來的影響，整體是正向影響還是負向影響，如果影響程度可接受，不需要干預，那到這里就結束了
• 其次，結合該指標的歷史數據趨勢以及其他相關指標情況，嘗試對未來做預測，評估指標再次劣化的可能性
• 隨后，針對不同的場景及關聯指標情況，提供可改進該數據指標的措施，并評估預期效果（注意預期效果和實際執行落地的效果相比可能會打折）
• 最后，評估改進措施所需要的投入，結合ROI來輔助你做出最終的業務決策。

經過這一波分析可能得出一條結論：指標異常波動，相比基線低XX%，經過分析發現本季度遇到了A、B、C問題，歸因是X、Y、Z原因，負向影響顯著。結合歷史趨勢綜合評估未來發生的可能性約XX%。建議通過1、2、3等方式來做改進，分別預期投入XXX，能夠解決XXX問題，并帶來XXX額外效果。

結論是分析數據指標得到的產物，它遠比冷冰冰的數字有價值。從管理者及普通用戶的視角來看，給我一堆數字我也不知道要從哪下手分析，不如你直接告訴我現在的問題是什么，是否需要改進，要怎么做才能改進，改進后能拿到什么結果。

5、結語

在項目管理和度量領域，基礎的數據分析能力是從業者們必備技能，你可以不精通，但需要掌握入門技巧，同時必須要有專業領域的業務思考，一旦脫離了業務，數據指標也就變成了純純的“數字游戲”。

縱觀整個數據分析過程，從取數、分析，到得出結論并給出改進建議，最終形成一份分析報告，哪怕看起來不算特別復雜的一份報告，實際上都包含著編寫者們的一把心酸一把淚。

在實際工作中，受惠于系統工具的不斷迭代，已經逐漸向系統化的取數和分析過程過渡，大大簡化了數據分析的困難和復雜度。在結合人工分析過程中，也在逐步摸索更加高效的方法，快速得出結論和建議。未來也希望能通過系統化、智能化的方式，讓大多數人能夠看懂數據指標，能夠直接利用有效的建議來實施改進，解決望指標興嘆的問題。