作者 | 泥洹
來源 | 阿裡技術公衆号
一 背景
項目管理的理論有很多，但大多是從理念和方法論的角度出發。當在一個團隊推行項目管理的某種實踐的時候，不免被挑戰的一個問題：“如何衡量技術團隊的效能”。于是不得不試圖去把邏輯題轉成數學題，用數字名額去證明一些“不證自明”的方法論。
但如果我們隻是擺出一些名額，不可避免地會陷入“上有政策、下有對策”的循環（隻要不加其他限制，數字還不是想怎麼優化怎麼優化）。我們也應該能看到這些數字背後，需要堅持的一些原則，和需要遵守的一些硬性标準。
假設目标是提高技術團隊的效能，會得到如下OKR（Objectives and Key Results，目标與關鍵成果法）：
O：
- 提高技術團隊的效能
KR：
- 增加總的價值傳遞率和傳遞品質
- 增加機關研發成本的平均傳遞價值
- 降低機關價值的平均傳遞時長
本篇側重點在如何量化，而不是如何提高。是以接下來繼續分解，我們要做的事情就是：
- 定義、衡量傳遞價值
- 定義、衡量研發成本
- 定義、衡量傳遞時長
- 細化名額
二 如何定義傳遞價值？
1 這裡可能會存在兩個誤區
誤區1：傳遞的價值就是産出的方案、代碼的數量和品質
這樣衡量傳遞價值，就很少有人願意建設公共設施了（因為品質好不好很難量化，建設公共設施初期的耗時往往明顯大于直接完成業務需求），也很少有人願意使用公共設施（因為用别人的，不如自己建，還能拿個結果）。而對于技術團隊，長期創造價值的能力，離不開公共設施的完備和對公共設施的使用。
誤區2：傳遞的價值就是業務KPI中名額的增量
有很多功能并不帶來直接的增量，或者比較難以衡量，但可能帶來公司的競争壁壘，如産品的體驗。這樣衡量傳遞價值，帶來的問題就是，大家都隻關注短平快的增量功能（比如營銷），最終産品的競争力下降。
2 我目前的答案：傳遞價值是需求背後的客戶價值
不完全是技術方案、代碼的數量和品質，也不完全是KPI名額的增量。傳遞價值就是按照使用者的需要，對使用者提供的整個産品、服務的數量和品質。這個定義幾乎是不證自明的，但是把傳遞價值定義為客戶價值，會不會讓這件事情更加複雜，變得更加不可能量化？這就需要我們轉變一下思路，通過按照優先級權重的需求的工作量來衡量。
按照優先級權重的需求的工作量代表着客戶價值，這裡做一些基本假設（假設不成立的場景可以作為另外的問題解決）。
假設1：技術的上遊（一般是業務、産品）對于客戶價值的判斷是基本準确的
我們知道業務是會試錯的，給業務小成本試錯的機會、在業務試錯的過程中沉澱一些通用的産品技術能力，往往不是局部最優，但是全局最優。
假設2：技術的上遊會按照客戶價值推演出優先級然後給技術提需求
假設3：技術的上遊提給技術的需求是充分的（不存在業務産品人員配置的缺失而導緻需求品質數量不足的情況）
基于這幾個假設，上遊提出的需求可能就很大程度上代表着客戶價值，研發在非功能性需求方面對上遊的需求做補充。
三 衡量傳遞價值
傳遞價值有個非常主觀但有效的衡量方式，是上遊（一般是産品業務）的滿意度。背後的邏輯是，傳遞價值（背後代表的客戶價值）往往很難量化，而産品業務的滿意度，展現了技術與業務是否很好的協同，也反映了技術是否很好的傳遞價值。
需求的工作量不應該通過人日來評估，因為不同團隊，對于相同功能點的開發時長是不同的。需求的工作量的機關應該是分解到最後的功能點數量。再細化一些，對于服務端是領域模型、領域服務數量，流程分支節點數量，對于前端、互動我不是很了解，但偏展示層可能更多的是頁面區塊、互動流程、行動點的數量。這些已經有量化的可能性了。
四 定義、衡量研發成本
研發成本，在一般的工程效能裡面有時候會被簡單的了解為人日，單純的傳遞人日的衡量，其實比較簡單，整個團隊的 人數*工作天數。但容易被流程設計者忽視的是，站在企業成本的視角，傳遞人日，可能還要按照開發人員的收入進行權重。從這個角度來看，技術團隊效能裡面的研發成本，準确的來說就是公司對于研發的金錢投入，包括購買伺服器、雲服務、教育訓練、行政投入。
這部分對于提升效能的啟發是：
- 哪些功能自研、哪些功能靠購買，有時候真的得算一筆帳。
- 軟體開發是一個邊際成本遞減的行業，如何讓功能更簡單的得到複用，可能是對效能提升最有幫助的部分之一（複用50個人日的功能子產品，就幾乎等于省了50人日的研發成本。當然也可能存在複用及後期維護的成本大于建立成本的情況，需要有良好的設計去規避）。
五 定義傳遞時長
我自己之前曾經陷入一個誤區，認為傳遞時長就是從開始開發，到完成上線，這個就是傳遞時長。但是回到客戶價值這個次元來思考，技術團隊傳遞時長（這個時候可能說産研團隊更合适一些），應該是從業務的一個想法，到驗證、立項、完成釋出、灰階，到最終使用者可以真正使用的時長。
于是機關價值的平均傳遞時長，就變成了以下公式：
六 如何衡量傳遞時長
衡量傳遞時長其實也比較簡單，記錄下業務提出該功能的時間以及功能開發的時間。難點可能是整個價值流傳遞過程中細化的名額，而細化的名額更能幫助我們發現問題。于是我們可以從一般項目的生命周期來看，哪些節點的時長會影響我們的傳遞：
- 需求立項到評審的時長
- 需求評審到技術方案評審的時長（如果項目很大可能會有多個層次的設計方案）
- 技術方案評審完成到開發完成自測的時長
- 自測的時長
- 多端聯調的時長
- 測試的時長
- bug驗證的時長，bug的數量（reopen可以數量+1）
- 環境部署等待的時長
- 代碼合并的時長（主幹釋出的情況下）
- 回歸的時長
- 釋出的時長
- 灰階的時長
這部分對于提升效能容易忽視或有啟發的點是：
- 需求的拆分成基本的功能閉環進行疊代（以不引入或少引入測試的重複回歸為标準），或許能比較有效的降低需求價值量的平均傳遞時長。
- 自測充分、減少bug數量，最終減少聯調、測試回歸的次數和時長，在一定的單測覆寫率要求以前，是收益大于成本的。
- 代碼合并有時候沖突解決很麻煩，會導緻一次部署的時間很長，且代碼合并引入了更多次的測試回歸工作（這可能是某些BU往主幹開發分支釋出走的原因之一）。是以基于業務的了解，進行應用的拆分，減少單個應用的并發數量，也可以提升研發效能。
- 在缺乏有效的項目管理的情況下，資源的互相等待可能是項目延期的一大因素，有時候某端開發完了，另一端資源沒到位，一直不能聯調提測。項目管理的同學對于資源目前的分工和瓶頸應該給上遊及時的回報。
容易陷入誤區的點是：
- 技術方案（架構、詳細設計）的評審既然是很大的一塊耗時，是不是可以直接寫代碼，少寫方案。我了解在技術方案寫不熟練的情況下，寫技術方案确實比較耗時。但是技術方案展現的是分析設計的過程和結果，這部分如果不寫出來，增加的是大量的溝通成本。而分析設計就算不寫出來，這部分工作量在編寫代碼的時候也是沒辦法省略掉的，隻是變成了在大腦中進行（也許在大腦中真的不如在紙上寫出來來的快和清晰，真的省略了設計，最終就會成為技術負債）。我個人感覺對于多大的需求需要技術方案評審的比較好的實踐，是以Code Review能否不基于技術方案直接閱讀代碼為準。
七 最後
但我仍然認為，好的量化的名額往往是好的結果的必要不充分條件。簡單粗暴的優化某項名額往往會因為兩個問題而使得最終的結果背道而馳：
- 某項名額變好，帶來的是其他名額的降低，局部最優并非全局最優（如：取消技術方案的編寫和評審，造成的是編碼時間或者後期維護時間的增加）。
- 效能是多個變量共同作用的結果，缺乏理論基礎和方法論的情況下，很可能在短期優化名額的時候，忽略了長期的團隊成長、系統能力沉澱等因素；或是忽視了業務方滿意度等難以量化的因素。
是以，效能的優化，不止應該有名額，還應該有路徑，而路徑往往是最難的部分。