越來越多的企業(yè)開始重視組織中臺的建設(shè)，而效能又是未來數(shù)年內(nèi)企業(yè)不得不面臨的難題：如何評價組織的績效？如何對比技能的差距？如何衡量協(xié)同的效率？如何遠(yuǎn)程化地跟蹤日常進(jìn)度？

研發(fā)效能數(shù)據(jù)中臺，將是未來技術(shù)組織重要的數(shù)據(jù)資產(chǎn)，用于快速盤點現(xiàn)狀、趨勢、目標(biāo)差距并共享基于數(shù)據(jù)的共識。本文總結(jié)近年來構(gòu)建研發(fā)效能數(shù)據(jù)平臺的實踐思想，以供參考。

01 研發(fā)效能數(shù)據(jù)中臺的定義？與DevOps平臺有何不同？

眼下，眾多與研發(fā)相關(guān)的平臺都被冠以“效能平臺”，包括項目管理類、研發(fā)管理類、測試集成類、構(gòu)建部署類……也有一些全包含的大而全的“研發(fā)效能”平臺，以阿里云DevOps企業(yè)研發(fā)效能整體架構(gòu)圖為例：

效能的定義到底是什么？我們看看管理效能：管理效率、效果、效益的綜合反映；工業(yè)中的能效管理：對用能系統(tǒng)的采集、顯示、分析、診斷、控制和優(yōu)化管理。效能，是作為某種結(jié)果的衡量尺度。而以上眾多的“研發(fā)效能平臺”，更準(zhǔn)確地說，是研發(fā)基礎(chǔ)設(shè)施平臺

DevOps平臺是持續(xù)集成、持續(xù)測試面向持續(xù)部署的延伸，它意在平滑開發(fā)面向生產(chǎn)部署的環(huán)節(jié)，縮短部署前置時間，也并非衡量研發(fā)產(chǎn)出結(jié)果的”效能平臺“。

02 搭建研發(fā)效能數(shù)據(jù)中臺，需要解決哪些挑戰(zhàn)？

當(dāng)技術(shù)組織有了“衡量尺度”的需求時，效能平臺就應(yīng)運(yùn)而生。但是，每個團(tuán)隊、產(chǎn)品都有其特點，很難用統(tǒng)一的評價標(biāo)準(zhǔn)說服團(tuán)隊接受。以持續(xù)集成成熟度為例，自動化測試評分一項，打出來后就有很多團(tuán)隊表示“不服”：

• 比如有的團(tuán)隊說，我們的測試執(zhí)行時長是高了些，但那是因為我們測試做的充分，測試覆蓋率高啊，能和那些只有少量自動化測試的團(tuán)隊比？
• 還有的團(tuán)隊說，我們的測試失敗率是很高，但是我們是掛在流水線上跑的啊，如果我們也像別的團(tuán)隊一樣，每次檢查就先在本地跑通了再掛上去，為了評分而測試有意義嗎？

對效能本身而言，應(yīng)用開發(fā)型團(tuán)隊，和數(shù)據(jù)類團(tuán)隊也不一樣。應(yīng)用開發(fā)追求的是盡可能及時、快速地發(fā)布上線，而數(shù)據(jù)類團(tuán)隊需要對上下游進(jìn)行精細(xì)的接口設(shè)計、驗證和業(yè)務(wù)確認(rèn)，重在數(shù)據(jù)的準(zhǔn)確性和可靠性，如都采用流動效率進(jìn)行評估，數(shù)據(jù)類團(tuán)隊在效率上就比較吃虧。

這些問題就在于衡量尺度，即評價標(biāo)準(zhǔn)的不充分。背后的思想是，到底要做中臺服務(wù)化，還是中臺管控化？

服務(wù)化，就是向使用者提供服務(wù)，甚至由消費(fèi)者驅(qū)動，中臺響應(yīng)支持。

管控化，就是向使用者透明規(guī)則，使其遵循要求，否則就無法使用。

而作為數(shù)據(jù)中臺，應(yīng)該如何作出技術(shù)決策？一種好的技術(shù)思想就是分層。

03 設(shè)計研發(fā)效能數(shù)據(jù)中臺的策略

分層策略幫助你將基礎(chǔ)數(shù)據(jù)、分析模型與評估決策分開：

• 基礎(chǔ)數(shù)據(jù)層：中臺管控為主，展開頂層設(shè)計，形成一系列定性與定量的描述。確保對現(xiàn)有研發(fā)過程、結(jié)果、工具鏈的采集完整性與及時性。
• 分析模型層：采用標(biāo)準(zhǔn)的統(tǒng)計分析算法對原始數(shù)據(jù)進(jìn)行處理，然后形成效能分析的維度指標(biāo)與模型。
• 評估決策層：中臺服務(wù)為主，與各技術(shù)團(tuán)隊充分討論評估的標(biāo)準(zhǔn)、細(xì)節(jié)，并根據(jù)使用的反饋，持續(xù)地迭代這些決策支持功能。

制定了設(shè)計思路之后，就可以對平臺架構(gòu)及核心流程進(jìn)行整體設(shè)計，以下是我們的產(chǎn)品參考。

04 什么是模型？如何設(shè)計出一個好的效能模型？

何為模型？在傳統(tǒng)的數(shù)據(jù)庫設(shè)計領(lǐng)域，模型通常指的是對客觀世界實體的一系列屬性關(guān)系的描述，在數(shù)據(jù)中臺時代，概念比較容易被混淆。

統(tǒng)計學(xué)上的模型，是指使用圖表、文字、數(shù)字、符號，以及數(shù)學(xué)表達(dá)式等對客觀現(xiàn)象的描述。對數(shù)據(jù)中臺而言，模型可特指對一個具體問題解決時，反映自變量與因變量之間的關(guān)系的程序算法實現(xiàn)。

比如說，代碼提交量、提交頻率與部署頻率之間是否有某種關(guān)聯(lián)？

部署頻率與客戶滿意度之間又是否存在著某種關(guān)聯(lián)？

代碼質(zhì)量的好壞與團(tuán)隊穩(wěn)定性是否存在著神秘聯(lián)系？這都是“模型”可以回答的問題。

我們的建議是：在一開始，完全基于數(shù)據(jù)而非某種管理思想進(jìn)行模型設(shè)計。

一個“好”的模型，僅需要從數(shù)據(jù)上回答其關(guān)聯(lián)影響程度，并基于更廣泛的數(shù)據(jù)進(jìn)行驗證即可。

這種設(shè)計方法的好處是，可以在數(shù)據(jù)中臺的設(shè)計期間，規(guī)避不同管理模式、思維的沖突，快速交付。

其次，模型只聚焦于描述數(shù)據(jù)變量間的關(guān)系，符合單一職責(zé)和組件化設(shè)計思想，在上層可進(jìn)行更多的組合和封裝。

這個思路和基于范式的數(shù)據(jù)庫設(shè)計異曲同工。在一開始，你只需要考慮范式要求，如果試圖用一張表解決某個具體的應(yīng)用場景的所有問題，你將會得到一張又大又丑陋又不實用的表，模型也一樣，一開始就試圖解決所有的效能問題，你也將得到一個又大又丑陋又不實用的模型。

05 持續(xù)迭代和演進(jìn)組織的決策思想

任何解決方案和決策都是基于某種場景和目的。首次發(fā)布的決策支持，可能過半年就不再適用，這會讓管理人員、質(zhì)量分析人員泄氣：效能數(shù)據(jù)中臺到底有什么用？

和自動化測試一樣，并非寫一套測試然后就一勞永逸，指望它能自動化地測試未來所有的版本。

數(shù)據(jù)，帶給我們的是一種思想，我們需要掌握這門未來的武器。

在未來，我們會越來越需要在不確定的情況下，作出有效的選擇。數(shù)據(jù)可以幫助我們發(fā)現(xiàn)事實依據(jù)，使選擇更有說服力。

在未來，組織會變得越來越復(fù)雜，我們?nèi)粘５墓ぷ?，可能僅能接觸到冰山一角。數(shù)據(jù)可以幫助我們快速縱覽全貌，避開主觀偏誤。

在未來，市場的響應(yīng)可能會越來越快，與其進(jìn)行流程的等待，數(shù)據(jù)與模型，能夠更及時地輔助系統(tǒng)主動響應(yīng)，幫助我們更靈敏地應(yīng)對變化。

未來唯一確定的，就是不確定性。

在不確定性的世界里，數(shù)據(jù)，可以讓我們做得更好，也變得更好。

免責(zé)聲明：文中阿里云效能平臺圖片來自于阿里云網(wǎng)絡(luò)公開資料，版權(quán)與著作權(quán)歸屬于原作者所有，如有侵權(quán)，請聯(lián)系后臺進(jìn)行刪除。

#專欄作家#

陳加興，微信公眾號：加興曰，人人都是產(chǎn)品經(jīng)理專欄作家。場量科技創(chuàng)始人，資深敏捷精益專家，精益企業(yè)認(rèn)證產(chǎn)品概念領(lǐng)導(dǎo)者。

本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Unsplash，基于CC0協(xié)議