大家好，我是李倩，來自上海，是 KodeRover 的創始人 & TGO 鲲鵬會會員。很高興能跟大家聊聊關于研發效能的話題，尤其是效能的量化和度量。通過度量認清短闆固然重要，但靠度量提升效能卻很難，特别是在工程能力不足的情況下做度量，甚至依賴度量制訂績效，都很容易出現問題。
既然提升效能如此困難，我們就來探讨一下，如何分步驟、階段性地真正提升效能。
一、提升軟體傳遞效能的關鍵之處
所謂技術研發，就是通過開發軟體為企業帶來業務價值。那麼軟體傳遞效能是什麼？它指代生産軟體持續為使用者産生有效價值的效率，可以了解為三個關鍵詞：有效性、效率、可持續性。
一、有效性：關注産品是否能為客戶、公司帶來價值；
二、效率：關注團隊能否快速生産和釋出産品、快速應對市場需求變化和企業業務目标；
三、可持續性：小團隊做小業務，可能沒問題；随着業務規模和團隊規模的成倍增長，還能有效控制研發效能嗎？這就是可持續性探究的問題，也是很容易忽略的一點。
為什麼要提升軟體傳遞效能？這主要為了企業長遠發展和讓企業有持久競争力。
如何提高軟體傳遞效能？首要任務，就是改善研發人力投入結構，動态平衡時間、成本、品質三者之間的關系。
常有人問，研發團隊到底應該怎麼搭建，或者說，成熟團隊的結構是什麼樣的？其實沒有标準答案，一切取決于業務形态，組織結構要圍繞業務或企業成本來規劃建設。舉個例子，如果企業要推出一款産品，就應該圍繞産品建立傳遞架構，如常見的 PO(Product Owner) 模式，産品負責人為産品的 ROI 負責。如果預算是 1000 萬，就要用 1000 萬 去搭建一個可以完成産品商業目标的團隊。團隊角色可能隻有開發人員，也可能包含産品經理、QA、開發人員，甚至可以招募營運人員。
一個商業單元，一切要以價值為導向改善人力投入，沒有固定的崗位比例建議。以完成确定的商業目标為依據，制造所有可能的、必要的資源和崗位。
軟體傳遞效能不是技術團隊可以單獨決定的，尤其在涉及到 ToB 環節時，鍊路很長。分析一下鍊路中的利益相關方就會發現，CPO 對企業生存發展負責，通過識别商業價值，使産品經理能夠完成實際的需求定義；接下來，技術團隊才能推進實作和研發傳遞；最後，市場和銷售觀測、驗證市場回報，服務團隊進行客戶支援和響應，接着開始新的一輪軟體傳遞周期。
是以，軟體傳遞管理的過程，要從商業識别到客戶服務的端到端開始管理，是端到端的價值流動和需求響應，既不是從産品經理拿到需求的那一刻開始，也不是到代碼上線就結束了。
在研發傳遞環節，最大的痛點是如何在保證研發速度的情況下，兼顧品質。一個相對完整的産品上線之前需要大量的驗證與運維工作，開發完成後有很多工作要做，比如部署測試驗證時間經常會超過代碼編寫時間，環境和建構問題也是團隊消耗大量精力的地方。
代碼品質差，導緻測試人員投入大量精力用來驗證和返工；傳遞流程管理不規範、不合理，導緻從上遊傳遞下來的資訊缺失，讓運維非常痛苦，承擔了很大的上線風險。
綜合看來，效能低的外在表現就是需求響應慢、傳遞周期長、事故多、服務能力下降，進而導緻企業無法快速進行創新創造。
如何解決傳遞困境，大家也想了很多辦法，比如說有些企業通過規範一整套流程來限制每個階段的産出規範，也有團隊為了驗證業務隔離環境，實作了七、八套測試環境，但這樣真的能提高效率嗎？
二、傳遞的挑戰和變革
做軟體研發的核心是處理人、技術、流程之間的關系，目标是在三者間建立良好的關系與合理的機制。
其中包含四個關鍵點：
1、人的服務化：建立面向開發者的服務體系，将支撐部門 BP 化；
2、組織效能的數字化：面向流程、工程、業務名額、技術建立多層次的效能度量體系；
3、技術的雲原生化：充分運用雲技術提升 IT / Infra 使用效率與開發人員生産力；
4、流程的工程化：簡化流程體系，用工程代替流程，流程越精簡越好。
最終四個關鍵點回歸一個最簡單的邏輯：幫助開發者生産高品質的代碼，上線到生産環境，并為客戶提供服務。大家對 HRBP(HR BUSINESS PARTNER) 的概念耳熟能詳，其實研發内部也一樣。開發者是主體，其他都是 BP，隻要能幫助優質代碼上線，無論怎樣為開發者提供服務都不為過。
按照這樣的思路，所有面向業務傳遞的部門都應該是一個單元。也就是說，QA、SRE 都應該下沉到業務，而不是業務方層層審批獲得資源。當某個部門、組織不是面向業務傳遞時，它就隻是一種職能化的存在，無法很好地展現價值。
支撐部門 BP 化以後服務目标如何定，核心價值又如何展現呢？這裡效能度量體系提供了一種思路。通過建立度量，整個過程清晰可見，知道到底發生了什麼，比如說效率和品質怎麼樣，中間協作過程是否順利，哪些因素有利于開發者上線，哪些因素是瓶頸？支撐部門也逐漸從成本中心轉向服務中心，與業務建立關聯，展現核心價值。
我們回到本質，提升研發效能要解決的是開發者的問題，而不是管理者的問題。大部分技術管理者，很容易從自己的角度出發，思考應該怎麼去管理研發。實際上恰恰相反，開發者才是主體，管理者應該思考如何将他們的價值發揮到最大。所謂的“996”，隻是一種形式而已。
面向開發者建立服務體系的思路，在國外已經非常成熟，Facebook 的持續開發過程聚焦的正是讓開發者毫不費力地完成代碼的送出和驗證過程。
Facebook 的持續開發過程大體如下：
1、開發人員負責 UT 和 IT，在本地開發機器上進行開發、包括本地的編碼、調測、單元測試等；送出 PR(Pull Request)，雲端執行完整的測試過程，并行運作包含靜态檢查、單元測試、內建測試、安全測試，以及性能測試等；
2、測試通過後，是 Phabricator 的機器 CR(Code Review) 和人工 CR 環節，人工 CR 選擇性的觸發端到端的系統測試、調測，并具有一票通過和否決權，通過後入庫；
3、入庫後進行持續傳遞的自動化測試驗證、灰階上線驗證，目前已經能支援到 CR 級别的持續部署能力。
我們可以看到代碼入庫前經過的本地、雲端、機器自動化測試案例和實時品質檢測及基礎設施都是以服務化的形式提供，可以靈活的調用。入庫後的運維過程也是高度自動化的。
可見，矽谷頂尖網際網路企業的流程非常輕量、靈活，而國内很多公司則設定了大量的流程架構，看上去好像是在幫助管理者明确工程師的工作内容和開發進度，實際則不然。提升效能的根源在于開發者能否順暢的寫完代碼并上線。
又有些人質疑說國内外工程師有差異。那麼國内外工程師水準真的相差很大嗎？我不這麼認為，我們中國工程師非常聰明，這種差别其實源于工程傳遞思維的不同。在國内，一些發展迅猛的網際網路公司流程也逐漸開始采用矽谷研發方式，完成從“寫完代碼就完事” 到 “代碼上線服務客戶了才算成功” 的意識轉變。工程師為自己的代碼負責，沒有人為其擔保和托底。就像 Facebook 擁有 一萬多名開發人員，卻隻有為數不多的産品工程師，寥寥幾名運維，沒有 QA，更沒有繁重的流程。
三、軟體傳遞效能演進
讓我們看看，目前有哪些影響傳遞的因素呢？上圖展示的是從想法到使用者之間的距離，也展示了我們技術團隊日常工作各個環節的内容。持續內建是指代碼的內建，驗證代碼邏輯沒問題。持續傳遞是做業務的內建，驗證代碼傳遞了正确的業務，重點關注業務的內建成功率和驗證效率，目标是持續驗證業務價值。
很多團隊在持續內建工程實踐上做的很好了，但有相當一部分團隊測試或部署過程是人工的、非連續的。實作全流程的自動化是軟體持續傳遞、效率提升的關鍵。
業務團隊可以通過業務拆分、采用微服務架構進行并行開發，但不能連續測試、持續部署到環境中。建立持續傳遞能力幫助 QA 不間斷地進行業務校驗，提供環境或者業務驗證機制，或幫助開發自主驗證。優秀的工程實踐是把共性的部分，即每個人都要花大量時間的部分自動化掉。
我在長期做一個“工程師自己認為時間花在何處”的調查。統計結果顯示，仍然有 55% 的工程師認為自己在做雜事，很少有時間安心寫業務相關的代碼。這很奇怪，作為工程師大部分時間卻不在寫代碼。如果我們能将沒有時間寫代碼的問題解決掉，效率就能提升。
上圖展示的是持續傳遞的演進階段。這裡非常有必要提一下分支管理，分支管理與工程成熟度密切相關，比如 Facebook 是主幹分支模式，合并負擔和流程都非常輕量，可以把持續內建和持續傳遞做到極緻，頻繁入主倉內建檢驗，而大部分公司采用主幹分支加功能分支或者 Git Flow。
根據圖示大家可以對比下，目前很多公司還處在第二、第三階段，有一定的自動部署能力，但沒有持續傳遞能力。到智能部署階段，基本具備了全面的管理能力。至于混沌工程，如果沒有全量的監控能力和對整體變更的管控能力，混沌工程也很難采用。隻有基礎設施相對完善的情況下，混沌工程才可以常态化的實施，每個季度或者每個月提升一次系統健壯性，比如模拟炸機房故障演練等。
四、效能度量建議
我從事品質或效率工程很多年，一直在尋找一個答案：有沒有一種基于名額的度量模型可以準确衡量一家公司的軟體傳遞效能 。通過這麼多年的探索，發現代碼量、PR 量、覆寫率、需求數量、缺陷數量等名額都不合适，無法提升效能甚至帶來副作用。那麼什麼樣的名額更有價值？我發現基于不同的改進目标，面向人、流程、技術建立多視角的度量，根據成熟度選擇适合自己企業特性和現階段發展的名額，不僅可以提升效能還可以增進工程文化。
首先要面向過程改進，也就是流程改進，尤其需要注意打回率和各種測試的平均耗時。QA 的高打回率名額可以推動研發自測，減少返工情況。各種測試的平均耗時則顯示了你花費了多少時間在驗證，比如花了很長時間在 UT 上，一個同學提了一個 PR，運作了 20 分鐘，如果每個人都耗 20 分鐘，那其他人等這個代碼內建，時間損耗就很大了，這是特别容易忽略的效率。
我很推崇從工程技術角度度量，首先這些名額最能代表核心效能，比如 CI/CD 是傳遞核心的效率，覆寫率是傳遞核心的品質名額。另外，對于工程師而言，客觀邏輯至上。相比”寫了多少代碼，解決了多少個缺陷，完成了多少個需求“這些名額，客觀技術名額非但不會損傷開發者的尊嚴，反而給大家更強的目标感，完全可以用于關鍵績效的依據。
同時，每個企業都應該有核心的 North Star（北極星）名額，這是可以建立績效的點，是老闆關注的點，也是員工可以努力的方向。比如雲服務核心服務 SLA 承諾名額，可以用做績效考量。
當然，還要考慮事故處理能力。事故就是針對企業内在流程機制的考驗，故障恢複時間可以作為核心内部作為績效名額。
其他的名額在這裡就不詳細闡述了。如何選擇度量名額，要取決于企業階段性的研發營運目标是什麼。比如最近對外缺陷很高，可以拿缺陷性名額去度量。另外，想要建立這樣的度量體系，還需要注重自動化體系的搭建，需要有自動化能力，并且可以持續收集資料。
但請注意，不要陷入一個誤區：在自動化能力不強的情況下，就去統計名額，指望通過 1-2 個月去收集到全團隊名額來度量團隊效能和評比，真正的度量和優化需要長久的營運。
随着時間的推移，問題驅動轉向資料驅動，團隊通過資料可以清楚短闆在哪裡，就可以定向解決這個短闆，最終讓研發團隊從軟體生産過程的資料中成長獲益。