1. 滴滴工程效能的演進
在大家的印象裏，工程效能就是基於工具本身的工程項目建設，簡單地說就是爲研發團隊鑄劍——提供所需的各類生產力工具。相信大家對下面這張圖中的企業都非常熟悉，國內及國際高科技頭部公司在 R&D 方面的投入佔比通常能達到公司營收的10%～20%，這足以說明研發本身對於科技企業的重要性。另一方面，隨着公司產品多元化，產研規模不斷擴大，工程效能就成爲了決定研發能力的關鍵因素之一。
滴滴工程效能團隊成立於 2015 年，滴滴的工程效能建設先後經歷了以下幾個階段：
-
第一階段：
公司處於早期，研發工具團隊採用一些外採和開源的方案，實現基礎功能，滿足業務研發的需要。
-
第二階段：
隨着公司人力的增多、業務的複雜，我們嘗試在一些特定領域做自研工具，以彌補開源工具的不足，主要是解決一些當時的特定問題。
-
第三階段：
開始做平臺化，當然這些平臺都是針對特定的領域，像項目管理平臺、代碼管理平臺、持續交付平臺、效果驗證平臺等。
現階段，工程效能團隊主要聚焦在一站式研發平臺的建設，完善研發的整體體驗和效率的同時，也有效的形成了研發與業務的功能聯通和數據關聯 。對於這一點我自己感受比較深，研發狀況的好與不好，不僅要讓研發同學們能看到，同樣要使得讓業務同學們有感知。這裏解釋一下爲什麼要去做工程效能數據建設。
2. 滴滴爲什麼要做工程效能數據
這裏解釋一下爲什麼要去做工程效能數據建設。
看清研發成本
在研發過程中，企業的人、財、物到底如何使用，應該是清晰可見的。滴滴目前不到2萬的員工裏有大幾千的研發人員，研發在成本上確實是一個大頭，業務需要看清楚人財物是怎麼分配的。
看清研發水平
業務本身在多元化，需求越來越多、產品也越來越多，此外還有一些國際化的市場場景。我們需要在工程效能的維度上讓大家清楚產研到底做的怎麼樣。
另外，我們可以通過分析數據化的效能狀況來提高研發水平，輔助研發決策。 ——屆時，我們不但能爲研發團隊鑄劍，我們還能指導研發團隊提高其御劍術。
3. 工程效能數據建設的總體思路
結合着滴滴的研發現狀，我們的數據建設主要從研發工具層面和數據產品兩個方面去努力。
工具層面
- 一是打通研發階段和非研發階段的工具，形成可以延伸到業務視角的全流程工具規劃。我們希望需求側、項目側和一些偏產品側的同事能直接感知到研發整體進度及關鍵的狀態進展。
- 二是研發工具鏈本身形成標準化的一站式工具體驗。通過這種方式，我們可以把研發最佳研發實踐低成本的從一個業務線推廣到其他更多的業務線，另外，一站式研發工具也使得工程效能數據本身更加統一和規範。
數據產品
滴滴的工程效能平臺共分三層：第一層是數據層，第二層是計算層，第三層是應用層
-
數據層
主要目標是獲得跟工程效能相關的數據，核心是數據收集的自動化和準確性。如果通過人工去收集原始數據，由於大家對數據的解讀並不統一，會產生更大的歧義。因此必須通過自動化工具實現，最終形成準確和統一的數據。
-
計算層
計算層就是生成工程效能的指標。我們根據工程效能的關注點，通過建模加工處理數據，然後展示這些特徵即可。
-
應用層
這裏考慮的是如何把計算層的指標展示出來。簡單的一、兩個指標並不能說明問題，我們希望數據的呈現不僅要具備工程效能專家視角，它同樣要滿足不同角色，不同業務特徵的個性化視角。
4. 工程效能體系的挑戰與對策
滴滴的工程效能數據建設在這三層上的挑戰類似於金字塔，數據層的挑戰是最大的。這主要源於我們工具鏈的演進過程，首先，原有的工具比較聚焦功能而非數據體現，數據能力有所確實；其次當前的工具比較聚焦特定的領域而非整體，數據缺乏一致的標準和關聯思路；最後，不同業務線在使用中也沒有形成統一的規範，數據的準確性不足。因此底層的數據治理工作非常繁雜，是最難的一層，計算層和應用層也有各自的難點，但相比數據層還是相對容易一些。下面分別講一下這三層的應對思路。
數據層的挑戰與應對
數據層的問題上面已經簡單的介紹了，歸納一下，首先是數據不完整；其次數據標準不統一；最後，數據不具備明確的關聯信息。
相應的，我們按照場景明確了數據要求，而非工具現有的數據作爲標準。以我們的代碼評審工具爲例，它的數據應該能直接反映代碼審計領域的問題，而非體現工具實現的特徵。基於這個標準，我們對數據結構進行了梳理和標準化，最後進行相應的進行工具本身數據能力的改造，補齊欠缺的部分。
此外，數據關聯還存在問題，由於用戶習慣的已經形成，我們沒有選取在各個能力工具層面分別進行改造，而是通過一站式工具平臺來統一解決，這個在計算層部分有詳細描述
計算層的挑戰與應對
計算層首要的難點是數據解讀的成本高，很多工具的數據通常需要我們找到具體負責該工具研發的同學去問，有些數據經歷過多次版本更迭之後，其含義變得模糊。其次是上面說到的數據之間缺乏關聯性，在跨工具的場景這個問題尤爲突出。最後是缺少指標體系，這個對於我們從海量的無序數據中梳理出有意義的指標至關重要。
爲此我們從後往前，從指標體系的梳理入手，以團隊（人）的視角爲核心，通過統一工程效能的解讀方式來降低數據的解讀成本。同時，依據統一的指標體系，發現現有數據中關鍵的主體關聯及屬性缺失，通過一站式平臺的能力逐步把這部分彌補上。
這張圖比較直觀地呈現了數據梳理和關聯的過程。我們把所有工具的數據表都彙集到工程效能的數倉之後，通過這個平臺在各個工具之間做索引和關聯，最終形成具備整體解讀效果的指標體系。當然，這個過程是一步步沉澱出來的，在這個過程中計算某個效能指標的最合理路徑逐漸清晰，工程效能的主體（通常是部門或產品）數據和關聯關係也更加豐富和詳細。
應用層的挑戰與對策
應用層的主要問題是展示，我們的平臺需要找到用戶最關心的效能指標數據並將它友好地展示出來。用戶的使用目標不一致、解讀標準也不一致，標準怎麼定、邏輯怎麼算，非常考驗平臺的能力。
首先，我們先完善指標本身，平臺不能只反映階段性的問題要反映全貌。第二，指標的呈現有不同角色的視角。第三，指標本身可擴展性。最後，工程效能數據能支撐或佐證大多數用戶的主觀認知，這也是指標體系迭代的方向。
5. 工程效能的數據體系建設
國內的國內做工程效能的主要分以下兩種思路：
- 一類注重交付效率、交付質量和交付能力等業務支撐的指標；
- 一類更關注持續發佈能力、需求響應、交付吞吐率、交付過程質量和交付質量等非常關鍵的頭部指標。這是國內企業做工程效能體系的現狀，下面介紹滴滴的工程指標是怎麼做的。
滴滴的工程效能核心指標分爲兩類：一類是偏交付指標，是給業務或者給非工程團隊的參考；一類是特徵指標，體現的是工具本身的狀態，在特徵指標方面我們比較關注有效行爲和可持續性。另外還有研發過程指標，我們會比較關注研發過程的需求響應、研發過程質量、持續集成能力這幾個比較突出的維度。這些效能指標，從完備性、多視角、可擴展性，以及支持主觀判斷等方面做到了全覆蓋。
回到數據應用的視角，當我們看工程效能的時候，我們的主視角到底是什麼？從一個比較自洽邏輯來講其實有三點：第一，看主體，主體就是團隊或者人；第二，看客體，就是看產品，看項目和需求；第三，看使用工具的過程。
以滴滴現在狀況，我們首先選擇了組織管理的視角，因此更多是從主體視角看問題。因此我們工程效能平臺選擇主體視角作爲第一視角，當然不同公司有不一樣的視角，這取決於場景。滴滴選擇了主體視角，主體視角關注兩大類指標：一類是團隊效能，一類是團隊產出。團隊效能主要看團隊的工程能力和水平，通常是定期的、變化頻次比較低且容易量化的指標。團隊產出更關注輸出物、工作量，以及進度。團隊產出的變化頻次比較高、也會經常被查看，這方面主要呈現的都是能反映事實和狀態的原始數據。
當前滴滴的工程效能數據平臺還處於初級階段。效能指標數據越來越統一和標準化，同時也支持數據的下鑽；產出指標主要展示效率、質量、成本這三個維度的原始數據。另外有的團隊想看一些更細緻和個性化的指標，我們基於各個工具裏特別細粒度的數據、打上歸屬標籤，讓用戶能快速查找和訂閱、放在自己的看板上，滿足這部分個性化的需求。通過工程效能數據平臺，我們可以輔助業務團隊提效降本，同時也可以促進我們的工具生態和研發方式不斷迭代，這正是我們的價值。
Q&A 如何度量DevOps的研發數據
前文內容裏也給到一部分答案。從DevOps角度看，這個數據可能更多是集中在研發過程指標裏，我們會比較關注，第一，響應能力，第二，研發過程的質量指標。第三，持續集成能力，持續集成能力可能更多關注的是CI、CD裏的頻率、平均時長等。如果我們希望在DevOps過程中能夠看到一些結論，可能還需要通過像具體時間的分佈、協作能力數據來定位問題。
關於指標，需要先想清楚，每個工具包括它所應用的領域應該有哪些非常關鍵的特質，它的目標是爲了快還是爲了好？當我們想把結論性的指標給人看的時候，我們要能找支撐它的指標數據。
在企業做大的過程中，有很多問題我們是能夠感知到的，但是我們確實缺少一個量化的方式去改善它，我們需要一把尺子使團隊裏的人都能夠感受到變化，以及這種變化到底是不是我們希望的趨勢。
作者介紹：
周凡，弟弟研發工具負責人
2007年碩士畢業於北京郵電大學，同年加入谷歌北京工程團隊，先後參與谷歌內部系統，全球數據中心以及谷歌雲的研發和測試工作。2018年加入滴滴出行擔任研發工具團隊的負責人。
本文轉載自公衆號滴滴技術（ID：didi_tech）。
原文鏈接：