「技術人生」第10篇：如何做研發效能提升（即指標體系建設過程回顧）

背景

縱觀軟件研發的發展歷程，如果說“業務需求開發”是核心主線的話，那麼研發效能建設就是這一核心主線之外最大的一條支線。每個歷史階段的研發效能所面對的主要矛盾次要矛盾都不一樣，因此大家可以看到，在不同的歷史階段產生了不同的“研發效能提升產品”：從文本編輯器到帶有各種功能的 IDE（Integrated Develop Environment），從單一的命令行腳本到覆蓋代碼發佈全生命週期的 CI/CD 系統，從各種“上古時代”的協作表格或文檔到目前已經發展出的橫跨軟件研發生命週期、覆蓋軟件開發關鍵維度的在線協作系統，似乎你能想到的降本提效的方法和途徑，都有人幫你做了專業的產品用來滿足你的各種要求和與衆不同的偏好。

可是實際上從真實的體驗來看，“研發效能”的大山彷彿從未被撼動過，讓決策者和執行者經歷着種種怪現象：

一方面，儘管從一線 leader 到一線研發同學都被各種工具全副武裝到牙齒，日會連着週會，週會連着覆盤會，但是研發效能建設取得的結果似乎很難讓決策者滿意：看不到投入的人力物力在短期內給業務發展帶來的積極影響，只能在“堅信大方向正確”的基礎上懷疑研發效能建設的執行過程有問題。

另外一方面反觀研發效能建設過程的一線親歷者們，除了業務需求的 deadline 之外，所有人還要遵守領導劃下的 guideline，去關心月度編碼量的 redline，以及年度需求交付數量的 bottomline。最終所有人的實際體感就是：會沒少開、代碼沒少寫、事情反而變多了，最終整體效率變低了：白天開會晚上編碼，寫出來的 BUG 可以繞地球 365 天（實際可以繞幾圈不知道，但是幾乎天天要解 BUG 是肯定的）。

從決策者的維度來看，看不到研發效能建設一段時間後的積極影響，一般原因有兩方面，一方面是實際上已經產生了積極影響卻不感知、更有甚者無法感知。這種情況的根源就在於決心要做研發效能建設的人，沒有明確的短期目標，也沒有明確的中長期目標，所以事情做了，但不知道做到了什麼程度，更不知道怎麼衡量做到了什麼程度。另外一方面是做了很多事情花費了很多人力同時也激起了很多矛盾衝突，但是確實沒有對業務發展產生積極影響。決策者的信心也在隨之動搖，猶豫之中還得繼續堅持那些自己都在懷疑是不是樣子工程的各種措施。這些“爲了效能而最終卻不怎麼效能”的情況，則在於決策者沒有搞明白研發效能要解決的問題究竟是什麼、怎麼執行才能得到所有人的行之有效的支持，只是“別人做了我也要做，別管我做的怎麼樣，就看我做的跟XX團隊像不像”。

從執行者的維度來看，大家感覺事情變多了效率變低了，主要是因爲真正“喫效率”的怪獸似乎一直是藏在屋子裏的大象（比喻顯而易見的事物卻被人視而不見），所有人都視而不見，不但決策者假裝它不存在，上下游協作者也假裝它不存在，甚至連我們一線研發團隊自己也感覺不到它的存在，這也是爲什麼產品經理常常問你：“我這個月不就是提了這麼幾個需求麼，你怎麼會又雙叒叕（you、shuang、ruo、zhuo）延期呢”，而你只能回之以滿臉的迷茫和後知後覺的憤怒，因爲你既不知道自己的時間去哪了，也不願意在自己已經努力得要死的情況下還得背一個不能按時交付需求的黑鍋。沒錯，你在日常工作中用各種工具、各種快捷鍵、各種飛花摘葉信手拈來的代碼片段節省出來的 10 分鐘，抵不過一場 15 分鐘都沒把問題聚焦起來的對焦大會；你用 git + docker + CI/CD 系統+藍綠髮布偶爾還來下金絲雀發佈一整套雲原生豪華大禮包跑完全部流程節省下來的 60 分鐘，也抵不過產品經理路過你工位時輕飄飄的給你來一句“需求要改了，晚上加個班”；當然，你用 teambition + 甘特圖 + 項目任務燃盡圖費勁腦汁地做多項目並行排班併發推進多條任務線最後節省出來的 10 天，也抵不過 leader 拉你進入緊急處置羣，裏面看到的第一句話就是“老闆改想法了”。

從決策者到執行者，但凡是在研發效能建設的過程中雞飛狗跳的，無一不是因爲認不清研發效能的本質所以只能邯鄲學步隨大流，重視它卻又不是那麼真正地關心，不願真正投入精力所以只會機械應付考覈指標從而自欺欺人。在失敗的研發效能建設實踐過程中，從業務方到產研團隊，從決策者到執行者，所有人都是受害者。

爲了早日擺脫研發效能建設方面的一些誤區，走出盲區，能與大家一起變成研發效能建設的受益者，本文會從以下幾個方面展開：

1. 先按常規講清楚研發效能的本質。

2. 結合作者目前正在進行的研發效能建設來拋磚引玉，給面臨同類問題的讀者提供一個參考；

3. 最後結合上一篇《技術一號位的方法論【業務篇】——如何設定業務目標》中講的一些方法，給出作者在研發效能方面的定製的目標體系，向讀者提供“如何定製業務目標體系”的參考樣例。

本文內容一如既往非常長，文章最開始提供目錄，方便大家挑選感興趣的內容閱讀：

一、背景

二、“效能”的定義

2.1 什麼是效能

2.2 什麼是研發效能

2.3 研發過程的分層模型

2.4 研發效能建設是過程管理、結果衡量、效果評估體系的綜合體

2.5 研發效能在業務效能建設中的位置

2.6 研發效能建設與業務生命週期的辯證關係

2.7 研發效能建設與研發團隊類型的辯證關係

三、全面構建綜合性研發效能提升體系

四、實踐案例介紹

4.1 背景情況介紹

4.1.1 業務方面

4.1.2 技術方面

4.1.3 團隊方面

4.2 效能建設原則確定

4.3 效能建設實踐過程

4.3.1 研發日常工作版塊梳理

4.3.2 研發日常工作流程梳理

4.3.3 研發日常工作任務數字化

4.3.4 研發效能目標體系建設

4.3.5 研發產出效果度量體系建設

4.4 實踐案例總結

五 研發效能到底應該怎麼做

5.1 從最抽象的層面看工作的本質

5.2. 分析你的工作信息流和決策流是什麼樣的，構建出整個團隊的工作版塊大圖

5.3. 根據工作版塊大圖和各種“流”，尋找讓信息流轉出現問題的點。

5.4. 結合指標體系，針對性的做改

“效能”的定義

研發效能建設是目前研發技術體系內非常重要的一個分支，已經逐步變成各大公司重要的研發基礎支撐領域，都在投入大量人力在這方面進行着不斷地投入，期望改善整個研發羣體的效能現狀。對於非研發效能建設領域的一線業務開發者而言，“研發效能”是一個天天聽天天做，但是沒有過多深入研究的領域，我們期望拋開各種眼花繚亂的產品概念包裝，從最原始的定義來讓讀者深入瞭解研究什麼是效能，什麼是“研發”，什麼是研發效能，研發效能和業務、和團隊有什麼樣的關係，從而讓大家對研發效能建設構建起全維度的認知。

什麼是效能

1. 效能，是指使用行爲目的和手段方面的正確性與效果方面的有利性。
https://wiki.mbalib.com/wiki/效能
2. 效能是指有效的、集體的效應，即人們在有目的、有組織的活動中所表現出來的效率和效果，它反映了所開展活動目標選擇的正確性及其實現的程度。效能是衡量工作成果的尺度，效率、效果、效益是衡量效能的依據。
https://www.zdic.net/hans/效能

從以上對效能的定義和解釋來看，我們可以得知，效能是指做一件事情是否達成了目標，達成目標的過程是否高效，達成目標後所帶來的實際效果，以及最終效果所帶來的效益如何的整體評判，它是對做事過程全生命週期的各個關鍵環節的評估的總體衡量。

什麼是研發效能

結合上面“效能的定義”，我們很容易得出：研發效能，就是採用信息技術作爲主要交付手段，將客戶業務需求轉換爲信息化系統這一事情在過程的效率、目標的達成、結果的效果、效果的效益幾方面的綜合評判。其中，過程管理、結果評估、效果評估是研發效能建設的幾個關鍵維度，如下圖所示：

圖1 研發效能的關鍵維度

在效能的定義和幾個關鍵維度的拆解基礎之上，我們再來看下業內幾個經典的研發效能定義是什麼樣的：

“研發效能”就是更高效、更高質量、更可靠、可持續地交付更優的業務價值的能力。
張樂 騰訊 DevOps 與研發效能資深技術專家

本文作者對該定義的解讀如下：

• 更高效：形容的是研發過程
• 更高質量：是形容研發過程產出的結果
• 更可靠：是形容研發體系及其產出，包括團隊、技術體系、產出共同構成的實際屬性和對客體感
• 可持續：是形容研發過程產物的交付生命週期和方式
• 更優的業務價值：是形容研發結果對業務的積極影響以及所帶來的收益。

 

持續順暢地高質量交付有效價值
張剛 阿里巴巴-雲研發 《ALPD 技術實踐 雲原生時代的架構方法》

本文作者對該定義的解讀如下：

• 持續：研發過程產出物的交付方式和研發過程的生命週期
• 順暢：形容研發過程的協作效率
• 高質量：形容研發過程產出的結果
• 有效價值：形容產出結果對業務的積極影響以及所帶來的收益

由上面的分析可以看到，研發效能領域的頂級專家們對研發效能的定義或描述，都涵蓋到了“過程管理”、“結果評估”、“效果評估”這幾個關鍵維度，並且在關鍵維度上有類似的期望和衡量指標。

研發過程的分層模型

上個小節講解了研發效能的定義，但是光有定義卻不能在“如何進行研發效能建設”方面做出有效的指引，因此我們接下來就對 “研發效能”做進一步地拆解分析：首先徹底弄明白效能提升的對象——“研發”是什麼 ，拆解分析研發過程，構建出“研發過程”的分層模型圖，對“研發”形成全面多維度的認知之後，一線業務研發人員就能看到自己每天都在進行的研發過程的全貌是什麼，從而讓大家瞭解整個研發過程中，哪些層面、分別容易出現什麼問題、會導致團隊效能下降；也能讓大家看到日常使用的效能工具分別在“什麼層次”解決了“研發過程中存在的哪些問題”。同時也希望能夠通過研發過程分層模型圖，給業務研發團隊 Leader 提供一個查漏補缺的視角，讓大家知道爲什麼在使用了各種“效率神器”、各種“全生命週期價值交付”的方法論以後，團隊效能看起來還是沒有太大改觀：問題很可能就在於之前的做法僅僅是參照了各種最佳實踐來使用各種工具，卻沒有把方法論和自己團隊的實際情況結合起來進行實踐——真正地分析團隊目前在做什麼事情，哪裏有影響研發效能的問題，如何切實地與團隊成員一步一步通過執行完成問題的解決，從而把效能提升起來。

分層模型的科學性來源於哲學層面的“事物的共性與個性的辯證關係”——世界上任何一個事物都是共性和個性的對立統一體，因此世界上任何一個事物都是可以按照從共性到個性來進行分層描述的。我們日常生活中最常見的分層描述方式就是生物界的“界門綱目科屬種”體系，通過這樣的分層體系，我們既能瞭解某物種與其他物種的共性，又能瞭解該物種有別於其他物種的個性部分，這對於我們深刻研究某個事物而言是非常有幫助的。

參考本文作者在《技術一號位的方法論【業務篇】—— 信息技術與業務的關係》一文中提到的，某事物與其他事物相比具有共性和個性，因此可以這個視角來完成研發過程分層模型的建設，我們把共性的內容放在最下面，個性的內容放在最上面，因此一般的業務研發過程分層模型具體如下圖所示：

圖2 研發過程的分層模型

由上圖可知，

1. 實踐過程是一切人類活動的共性、基礎過程
2. 生產過程是一種專業的、在人員、過程、結果方面都有一定要求的實踐過程。
3. 信息系統研發過程，是信息產業中軟件研發領域的生產過程，具備生產過程的共性，同時也具備信息技術的個性。
4. 業務系統研發過程，是信息系統研發過程的一個子集，與之相對的是技術系統研發過程
5. 在具體到某個業務的情況下，隨着業務生命週期的變化，與之對應的同階段的研發過程也存在着差異

在分層模型的各個層次中，每個層次的核心要素和關鍵維度不一樣，由下至上來看，上層是下層的特殊子集，具備着下層的共性的同時，存在着自身的個性，從而使之與其他過程有所區分。我們用一個常見的某某公司電商\廣告\社交等業務研發過程來看，它具備下層所有的共性，同時也有它自己的個性。在使用分層模型來剖析研發過程的時候，就會發現我們常常使用的各種 CI\CD 工具，解決的是 “信息系統研發過程” 層面中的共性的問題：代碼如何不斷多週期持續性迭代，如何持續性交付，如何無損地進行持續性的部署；我們經常使用的需求管理工具，解決的也是“信息系統研發過程”層面中的共性問題，如下圖所示：

圖3 常見的研發效能工具解決的是哪些層面的問題

從上面的圖我們可以看到，從這些常見的解決效能問題的技術產品的視角來看，因爲技術產品本身要回答 “做產品”還是“做項目” 的問題，因此選擇“做產品”的一定瞄準儘可能多的客戶的共性問題，在此基礎上再解決定製化的問題，即提出各種架構、模式、機制來支持未來可能的定製化，因此它對更上層的、更具體的效能問題其實不解決的，或者說，從投入產出比的角度來看，產品型效能工具在誕生之初就無法做特例情況的支持，只能通過後期的基於各個團隊實際情況的自定義開發來解決。所以這就是爲什麼用了效能工具還有效能問題的根本原因：它只解決了它要解決的效能問題，但是它沒有解決你所面臨的全部的效能問題。作爲研發團隊的 Leader，要非常清晰地看到哪些產品解決哪些問題，更要非常清晰地知道自己的團隊目前面臨的效能問題究竟是什麼，怎麼形成的，如何解決，事實上就是分析清楚當前團隊在研發效能建設領域面臨的主要矛盾次要矛盾是什麼，這個分析可以參考文章：《技術一號位的方法論【理論篇】—— 分析事物本質的必要性及事物本質分析的操作步驟》中提到的方法來進行分析。當然我們也看到很多方法論，也是需要注意方法論背後的本質或者背後意味着需要做哪些事情，如果只是單純地模仿，也無法解決團隊現狀中面對的困境。

通過研發過程的分層模型，我們瞭解了自己參與的研發過程的個性和共性，也爲我們做效能提升時建立指標體系提供了最重要的參考。接下來我們就繼續拆解對於一個研發團隊而言，研發效能建設究竟是什麼樣的——肯定不是隻使用某個產品或工具就萬事大吉了。

研發效能建設是過程管理、結果衡量、效果評估體系的綜合體

從研發效能的幾個要素來看，我們可以把研發效能建設過程拆分爲幾個大的體系，首先就是過程管理，然後是結果衡量，最後是效果評估，如下圖所示（注意，營銷線和銷售線沒有做細粒度的展開，同時幾條線的並行時間對應關係也是示意圖，實際情況既不一定要並行或串行，更多是整體並行但是不同線上的階段會相互銜接）：

圖4 研發效能建設體系與研發過程生命週期對應關係圖

過程管理，是從業務戰略到落地執行的全階段管理，以技術能力保障需求交付爲基礎，囊括業務維度的各項事情，也涉及到了團隊管理的各項事情。只做技術能力的建設，或只使用各種效能產品來圍繞技術維度做提升，只是把效能提升的基礎層面覆蓋到了，而沒有覆蓋到業務和團隊層面。這是很多研發團隊 Leader 非常容易漏掉的一個方面，而繼續提升團隊效能的空間往往就暗含在這個方面中。

結果衡量，是執行結果的評估體系——用簡單通俗的話來講，就是確定“做事情做到什麼程度了、有沒有做完”。目標和指標體系的構建，是結果衡量的基礎。從 KPI 到 OKR，目標是所有業務的啓動原點，也是所有業務的執行終點，而這個過程中需要以指標體系來讓業務各方感知到執行過程究竟怎麼樣，具體到研發團隊來說，就是要知道研發本身的目標是什麼，在整個落地過程中，哪些指標可以告訴我們目前的研發情況怎麼樣，要不要做調整，離達成結果還有多遠。一般情況下都是以產品功能上線作爲事情的結果，作爲研發過程的目標，但是實際上應該以業務目標的達成作爲研發過程的結果來衡量，而產品功能上線只是關鍵里程碑之一。一般業務研發團隊沒有和業務團隊形成背靠背的關係，覺得我的產品功能交付了就 OK 了，事實上產品功能 OK 不 OK 得看這樣的功能上線以後，對外部客戶而言，C 端的用戶是不是有了更好的體驗，B 端的用戶開展業務時是否更順暢更高效更安全；對內部客戶而言，特別是對業務團隊來講，是否爲業務團隊進行產品商業化的業務運營過程中提供了積極的影響，在營銷、銷售方面是否形成了更好的助力，而不是對業務團隊開展後續業務製造了麻煩甚至是阻力。

效果評估，是執行結果在業務上帶來的效果、對業務收益的影響的評估體系——用簡單的話來講，就是判斷執行目標達成後，拿到的結果，對業務發展趨勢有什麼影響，對業務收入有什麼影響，影響是積極的還是消極的，具體影響的指標情況是什麼樣的。對研發團隊執行結果的效果評估，實際上就是從研發過程的視角過度到了業務發展的視角，需要一套業務洞察系統，從而能讓團隊 Leader 或者業務方看到研發對業務發展的影響。

看到這裏，有些讀者肯定會發現效果評估這個維度有些問題：影響業務發展的因素是多方面的，如何確定某個階段業務指標的下降是由於研發團隊的執行結果引起的？爲什麼不說是由產品引起的，或者是由運營引起的？想要把這個問題回答清楚，就需要我們先把最基礎的實際情況分析清楚：

• 研發過程在業務開展過程中的站位是什麼樣的？
• 研發過程在業務發展過程中和其他過程的關係是什麼樣的？
• 研發過程在什麼情況下能推動業務發展，什麼情況下會阻礙業務發展？

因此接下來的幾個小節，我們會繼續進一步在理論上把研發效能這個命題分析清楚，讓大家對研發效能建設有一個完整的認知，避免被各種大廠出廠的各種 “效能”工具或者業內各大牛分享的各類最佳實踐侷限住自己的思維，以爲只要把工具用起來，把代碼行數統計起來，團隊的效能就會好。還是要回歸最根本的實際情況，在理論的指引下實事求是地解決效能卡點問題，合理使用各種效能產品和工具，把效能建設紮實地覆蓋到幾個關鍵的維度，才能讓研發團隊的效能朝着好的方向發展。

研發效能在業務效能建設中的位置

前面幾個小節從研發效能的定義作爲切入點講解了研發效能的概念和一些重要的維度，在認清其內涵之後，就要從整體視角來分析，從宏觀的視角看到研發效能在日常工作中的版塊位置。作爲軟件開發的一員，我們目前做的業務都是基於信息系統來完成價值創造的。信息行業的業務建設過程，包含有多個維度，如技術、運營、營銷、財稅法合規風控等，這些維度共同構成了一個業務價值鏈條，分別處於不同的環節，共同協作確保業務價值鏈條的持續循環運轉，如下圖所示（某個業務的鏈條還會和其他業務、企業外部協作夥伴構成更大的價值鏈條，即爲產業鏈，繼而與產業鏈上的上下游企業或價值鍊形成業務生態，因爲與文章主題關係不大，這裏就不再繼續展開了）：

圖5 研發過程在價值鏈中的位置

由上圖可知，在信息產業業務中，信息系統研發過程主要橫跨業務的價值創造、業務價值交付兩個大的環節，同時也以支撐的形態存在於其他幾個環節中。研發過程和其他幾個核心業務環節共同決定着業務的發展形式，而每個環節發揮的作用不同，對業務的影響也不同，所以業務洞察系統的構建和使用，就能讓業務決策者看到不同的環節在業務不同的生命週期中的影響是什麼，看到研發過程的效能對整體業務效能的影響，從而可以更合理地定製執行策略，調整組織關係，確保業務發展方向與團隊使命願景和長期價值規劃不發生偏離。

所以我們可以從研發過程在業務價值鏈條的位置得出研發效能在業務效能建設中的版塊位置如下：

圖6 研發效能建設在業務效能中的版塊位置

研發效能直接關係到價值創造的結果，因此處於整個業務的基礎版塊，沒有價值創造就無所謂後續整個鏈條；業務運營效能板塊包含了對客相關的事務、商業化相關的事情，是產品與客戶的連接器，也是產品價值的放大器，在產品價值創造完成後，它是最日常、最核心的部分；組織效能則是與人相關的事物的彙總，貫穿於所有的板塊中，大的方面包括着單一團隊使命履行的整體效能，也包括着多個不同團隊之間協作效能，同時團隊效能也與個人效能有着直接的相關性。

看清研發效能所處的版塊之後，結合研發過程在價值鏈中的位置，就知道：

1. 在業務啓動或新的產品功能創建階段，研發效能對業務結果的影響比重最大；
2. 在業務功能上線後，業務運營效能對業務結果的影響比重上升，研發效能對業務結果的影響比重降低，但是仍然不可忽略；
3. 在業務進入商業化階段後，業務的交付模式決定了研發效能對業務結果的影響比重：標準的產品型交付模式下，研發效能對業務結果影響比重不大；定製型的項目型交付模式，研發效能對業務結果影響比重提升。

基於這樣的大規律，我們可以根據實際情況合理地得到研發效能的效果評估模型。

研發效能建設與業務生命週期的辯證關係

除了研發過程在價值鏈中所處的環節不同，會給業務帶來不同的影響之外，在業務的生命週期中，不同階段，研發過程所起到的作用也不一樣，因此其效能建設的重點也不同，具體爲：

1. 在業務啓動階段，研發效能建設的重點是如何確保研發團隊能夠進行大量、高質量、快速完成業務需求的交付。
2. 在業務發展階段，研發效能建設的重點是如何通過效能指標倒逼團隊構建標準化的產品功能，沉澱業務能力，爲規模化複製做準備
3. 在業務成熟階段，研發效能建設的重點是則是提升穩定性和效率，降低各維度的成本，促使研發團隊在業務增量有限的情況下利用技術的創新帶來新的機會，使技術成爲業務的增長源之一。
4. 在業務消亡階段，研發效能建設的重點是資產沉澱複用，從而讓業務消亡但是組織的長期投入不會跟着消失，而是讓過去的成本價值沉澱在技術體系內變爲其他業務複用的資產。

由上可知，研發效能建設在業務不同期間的建設重點是什麼，常規的做法就是隨着業務的變化做研發效能建設的側重點的調整。而在團隊人員充足的情況下，可以適當地多維度展開研發效能的建設工作，不需要被業務生命週期束縛，也就是說，完全可以通過效能建設的超前性來避免下一個階段可能出現的問題，從而做到“治未病”，也就達到了“善戰者無赫赫之功”的境界（這一境界對業務是有利的，對個人而言則要看上層管理者的感知力和偏好了，不展開討論了）。

研發效能建設與研發團隊類型的辯證關係

研發效能建設除了和它自身站位、和它所對應的業務生命週期有關以外，也和研發團隊的生命週期有關。人作爲實踐的主體，團隊作爲研發過程執行的主體，恰恰是對研發效能影響最大的一個方面，也是最富有變化、最需要實事求是進行鍼對性的分析和調整的一個維度。

對於小型團隊而言，團隊特徵是小而精，聚焦的業務領域單一，效能建設最重要的是研發過程的效率的提升，而不是需求的交付量。向 5 個人的團隊要產出，不如向 5 個人的團隊要效率，效率高了，產出和質量都不會差——很多質量問題都是在高壓環境下對“某些影響產出質量的關鍵要素”執行缺失或檢查遺漏導致的。如果向小型團隊要產量，把需求交付數量作爲研發效能建設的考覈指標，那麼在高壓環境（高壓環境=需求並行+時間倒排）下只有加班這一個途徑能在短期內讓“效能指標”看起來達標了，但是實際情況卻是：5 個人即便是通宵加班，排除在產出質量方面帶來的負面影響不談，實際按照 50%的加班產出率來算，也只多出來 2.5 個人的產量，可是這卻是燃燒團隊生命力和未來潛力實現的，綜合收益極差。小型團隊適合使用效率指標來約束，強調日常工作中所有影響業務產出的工作都儘量工具化、系統化、自動化，降低在非業務產出板塊中投入的精力，給業務產出留出更多的時間和精力，那麼產量、質量自然會上來。

中型團隊的特點是承接比較複雜的整塊業務，和不同的業務方進行比較密切的配合，需要把研發效能的建設聚焦到流程和標準的完善上。從而讓協同更簡單流暢，讓關鍵環節的產出符合質量要求，同樣對業務產出和結果有積極影響。

大型團隊的特點是綜合程度高，往往會承接多個不同的、但是卻又緊密相關的業務線，彼此相互獨立發展卻又相互支撐配合。這樣的團隊，研發效能建設的重點也不是需求的交付量，而是多個不同團隊的產出是否能夠相互配合支持，形成合力，在宏觀層面對業務形成積極影響。這就需要把研發效能的建設聚焦在結果的評估和效果的衡量上。大型團隊是由中型團隊組成的，中型團隊是由小型團隊組成的，對不同類型的團隊，結合它們各自的特徵，對不同的層面分層次進行建設和約束引導，自然能覆蓋到很多重要的效能指標。

很多團隊的效能指標會停留在編碼量、需求交付量，實際上只是照顧到了最基礎的效能指標，卻沒有分團隊類型、分業務階段做動態調整，自然很難發揮出指標的牽引作用，原因就在於不夠實事求是，對團隊和業務的個性考慮不足。

全面構建綜合性研發效能提升體系

結合第二章各小節的分析結論，我們可以形成一個綜合性的研發效能提升體系。

研發效能建設的內涵

研發效能建設是過程管理、結果衡量、效果評估的綜合體系建設，整個體系除了研發自身的成本、效率、質量問題之外，還涉及到全業務價值鏈路、研發組織管理、多業務角色團隊協同等大的綜合維度。在整個研發效能建設過程中，各類型的研發效率提升工具的使用是基礎，目標、指標體系系統是關鍵，業務洞察系統是核心。同時在研發效能建設過程中，要充分考慮到研發效能和業務生命週期的關係，和團隊生命週期、團隊規模的關係，在不同的階段和不同團隊規模的情況下，進行有針對性、有側重點的提升，避免只做常規的效能建設。

研發效能建設的使命

研發效能建設的使命是提升研發過程的效率，降低研發過程的成本，確保研發過程執行的結果能夠達到預期的目標，並且通過全業務環節的評估、反饋和調節來提升研發結果對業務發展的積極影響，提升業務結果的經濟效益。

研發效能的指標體系

按照圖2 研發過程的分層模型來看，研發效能建設也需要針對每個層次做針對性的提升，具體如下：

1. 在實踐過程這個層面，要做好最宏觀的“過程的效率、過程的成本、結果的效益” 三個方面的考量，這個考量是宏觀層面的，適用一切實踐過程，自然也就是信息系統研發效能建設的宏觀綜合指標。如下圖所示：

圖7 實踐過程的效能指標

1. 在生產過程這個層面，要分別從“生產團隊、生產過程、生產系統、生產結果評判”幾個維度來感知生產過程的情況，例如團隊人員是否具備從事生產活動的基本資格、生產過程是否有流程、有標準、生產系統的產能和先進性、生產結果的收益等等，形成如下圖所示的生產過程效能指標：

圖8 生產過程的效能指標

2.在信息化系統建設過程這個層面，從團隊、業務、技術、技術產出幾個維度來感知研發過程和結果的情況，例如研發團隊成員技能和素質是否滿足信息系統研發要求；業務需求是否合理，是否能夠有合理的技術方案實現；技術方面系統和架構設計是否與業務特徵匹配等等，具體如下圖所示：

圖9 信息系統研發過程的效能指標

3.在業務系統研發過程這個層面，維度相同，但是側重點已經和信息化系統建設存在一定的差異，特別是技術方面的要求，會具體到是否能支撐業務發展，是否能保障業務發展，是否能驅動業務發展，其他維度不再展開討論，具體如下圖所示：

圖10 業務系統研發過程的效能指標

4.在成熟業務的研發過程中，業務階段特徵非常明顯，對研發團隊、研發工作的要求也和業務特徵息息相關，總體而言是 業務上“求穩、求變、求生”，團隊梯隊配置上也是“梯隊求穩”、“穩中求變”、“變中求生”，而研發工作上也是“求穩”、“求新”、“求沉澱”，具體如下圖所示：

圖11 成熟業務系統研發過程的效能指標

5.在具體的自己負責的業務研發過程中，則需要結合當前的團隊、業務階段等特徵，來確定指標了，這裏就不給出具體的信息了，讀者可以根據自己團隊的實際情況，從團隊、業務、技術、產出結果評價四個維度分別構建出你自己業務的效能指標。

結合研發過程的分層模型，分別把不同層面涉及到效能的指標分析清楚，這樣就完成了整個研發效能的指標體系的梳理，結合上一篇文章《技術一號位的方法論【業務篇】——如何設定業務目標》我們可以知道，指標體系的使命是讓我們感知到做的事情目前實際情況是怎麼樣的，讓我們能夠通過可感知的指標來發現目前事物發展過程中存在的問題。

同時大家可以發現，“研發需求交付數量”在衆多指標中只是很不起眼的一個，幾乎難以發現。可實際工作中，很多團隊喜歡看這個指標，我們拋開傳統軟件公司不談，以大家對互聯網大廠的瞭解（不論是親身經歷還是有所耳聞），會有研發團隊的工作量是不飽和的嗎？作爲管理者要思考，是不是存在一種可能性，既在團隊現有“需求交付數量”的基線上有所提升，所有人的工作量又有所降低，整體工作負擔同時有所下降呢？頂層決策者們想要提升整個團隊的產出，下面的管理者們就會要求團隊加班，這個對策簡單、直接、粗暴、最重要的是見效快，見效快意味着好用而無心理負擔，所以頂層老闆不細看真的會覺得這個 Leader 執行力強，可是長期來看，卻是在飲鴆止渴，這就要求頂層決策者們多些思考，在執行的引導上多些智慧，使用合理的指標、恰當的方式來促進團隊產出的提升。

不同階段研發效能的考覈目標

指標體系建立以後，我們可以通過指標體系的反饋來看到當前的研發過程中存在哪些問題，能通過各種現象來分析背後的問題是什麼，從而確定近期的主要矛盾次要矛盾，於是就得出了當前研發效能建設的短期目標；宏觀層面的指標需要經過較長時間的持續努力和改進，因此我們也能從指標體系裏面可以得到中長期的目標，於是可以得出整個研發效能建設的目標體系。階段性的目標和指標體系的對應關係如下圖所示。需要注意的是，該示意圖只展示了普遍的、普適的情況，沒有畫出特殊情況，因爲特殊情況千變萬化：比如有的團隊就是把“成本下降”當做短期目標，想要在短期內看到成效，這種情況就是根據其團隊的實際情況得出的特殊情況，看起來是和下圖的關係不相符的。但是事實上從更大的更宏觀的尺度來看，成本降低是一個全生命週期的長期的事情，近期成本壓下去了就不做長期的治理，那麼成本問題依然會在某個階段跳出來需要“再治理一次”，所以最終來看還是符合下圖所示的對應關係的：

圖12 階段性目標與指標體系的對應關係

實踐案例介紹

背景情況介紹

4.1.1 業務方面

1.現狀

• • 成熟電商平臺業務，核心業務模式已經趨於穩定，受客戶羣體特徵和規模限制，已經進入平臺期
  • 業務領域複雜，多達 8 個核心域，分別爲商品域、管控域、交易域、訂單域、支付域、優惠域、結算域、商業化域，也包括 8+支撐業務域，如權限域、合同域、租戶域、用戶域、積分域、互動任務域、流量變現、風控等
  • 爲了避免可預料到的業務規模見頂帶來的業務目標增長停滯，需要嘗試新的業務模式帶來增量，整體提升業務規模。

2.特徵

• • 業務模式爲 B2B2C，即服務企業客戶，同時服務企業客戶的 C 端用戶。
  • 現有業務模式進入成熟期
  • 成熟業務模式存在數以百計的企業客戶
  • 需要探索新的業務模式和客戶羣體，尋找業務增量

3.面對的挑戰

• • 需要保障成熟業務模式穩定發展
  • 需要探索新的業務模式

4.1.2 技術方面

1.現狀

• • 分佈式技術體系+複雜業務數字化
  • 經過 4 年的建設，技術系統衆多，除了業務領域對應的微服務之外，還有衆多的“業務中間件”，包括事件服務、mock 系統、分佈式鎖、元數據服務、異步任務服務、文件服務、網關服務、業務配置服務等等

2.特徵

• • 受業務特徵的影響，技術體系特徵也劃分爲 ToB 和 ToC 兩類
  • ToB 業務模式下，多租戶、基於標準業務能力的定製化、複雜業務建模是主要的技術命題
  • ToC 業務模式下，大流量、高併發、高可用、跨業務方的數據一致性、分佈式業務系統的最終一致性等是主要的技術命題
  • 高度複雜、流量巨大、業務數據體量巨大的情況下，整體系統的正確性、穩定性提升、成本控制、效率提升

3.面臨的挑戰

• • 架構設計的演進和分佈式技術體系的落地
  • 分佈式技術系統的穩定性建設
  • 技術領域和業務領域建設的相互促進
  • 受業務形態影響，技術團隊承載着對外技術服務的職責

4.1.3 團隊方面

1. 現狀

• 技術團隊：12 服務端（1 主管 + 3 正式員工 + 8 外包員工）+ 2 數據 + 3 測試 + 3 前端
• 團隊屬於綜合型團隊，承載着：業務需求、研發效能、運營效能、客戶技術服務、穩定性建設等幾大板塊的工作內容。

2.特徵

• • 團隊規模小，業務領域衆多，日常工作版塊衆多
  • 綜合型技術團隊

3.面臨的挑戰

• • 小微型團隊支撐大型業務，單迭代需求多，臨時緊急性任務多，人爲因素引起的研發交付過程管理困難
  • 團隊梯隊亟需優化補充
  • 團隊涉及的工作板塊多，人員日常工作負載較高

整體總結下來，以團隊的視角來看，挑戰主要集中在如何以小微型團隊支撐大型業務，在成熟型業務日常迭代的過程中，還需要服務客戶、保障系統穩定、同時需要提升研發、業務運營的工作效能，同時還要肩負着重要的業務模式探索的任務，充分體現了既要又要還要。同時因爲團隊組成複雜，人員培養也是重中之重，在這種情況下，作爲團隊 Leader，應該如何提升研發效能？

效能建設原則確定

根據 2.7 小節內容可以知道，小型研發團隊的研發效能側重點不在於需求交付數量，而是在於日常工作效率和質量方面。因此在大團隊的效能指標的基礎之上（代碼量、單測覆蓋率），我們結合自己團隊的情況，確認團隊的研發效能建設圍繞着 “保業務需求，提工作效率，降工作負擔，數字化清晰化精細化”展開，具體而言：

1. 實事求是地解決團隊效能問題，既不是簡單地使用某個工具某套系統就覺得萬事大吉，也不是簡單地考覈諸如代碼量、需求量、需求交付週期等片面的單一維度的指標。
2. 業務需求的完成和交付是團隊工作的第一優先級，所有的效能建設都圍繞保障業務輸出來進行，確保小型團隊日常工作對業務仍然具有推動能力，而不是讓生產力被巨大的業務規模、複雜的業務模式、衆多的客戶服務工作消耗在巨量的瑣碎的事務中。
3. 向過程要質量，而不是向結果要質量。這一個原則，針對的是團隊日常交付物的質量保障和整個技術體系的穩定保障工作而言的。在團隊成員水平參差不齊的情況下，如何確保產出物的質量穩定地處於較高水平的質量基線之上，只有提升過程管理才能達到要求，而在結果上設置再多的卡點，都沒有太好的效果，因爲結果的卡點是最後一環，單純追求結果卡點指標不能解決問題，因此需要以過程指標來牽引日常工作，從而確保結果卡點指標的達成。同時由於現有團隊規模明顯無法按照普通的方式保障大型分佈式技術系統的穩定性。一些大型的百人級別的業務團隊可以有一定的資源餘量來專門做橫向的穩定性建設工作，專門去做應急保障，故障出現了做應急、做止血、做恢復、做覆盤，小型團隊不能學習大型團隊的“最佳實踐”，只能別開生路、創造性地使用不同的方式完成穩定性的建設工作。
4. 工作流程的健全和充分執行，是現階段團隊研發效能建設的主要矛盾。很多小型團隊因爲人少、事多，因此爲了追求“所謂的快”而沒有工作協作流程，或者有了流程也打着“敏捷”、“高效”的幌子跳過流程的一些環節，對已經經過實踐檢驗的流程不做充分執行。還有一些團隊依靠行政命令所有人嚴格執行各種流程，但是卻對流程每個環節的產出物不設標準、不做檢查，這樣也只能積累一些流程執行數據而無法真正地解決過程管理要解決的問題。我們的思路不是砍掉流程、或者跳過流程的環節，而是降低研發同學執行流程的成本。讓大家花費更低的成本把流程跑完，在自己負責的環節產出符合標準的產出物傳遞到協作下游，通過流程完成各項工作中和其他角色的高質量協作，讓大家既能享受到流程帶來的好處，也能節省出更多的時間。所以效能建設的重點就是健全工作協作流程，完善標準定義，降低所有人爲了執行流程而投入的精力和成本，其中最後一點也是重中之重，是確保流程可以被所有人接受的前提條件。
5. 所有的效能建設都要基於數字化的方式來完成，讓所有人既能看得見研發團隊的整體負載情況，也能看到各個角色的研發人員日常工作版塊，每個版塊投入的精力情況，最終能夠針對不同的角色和羣體進行鍼對性地效能提升，同時也方便決策者們基於團隊當前的負載做出合理的決策，數字化讓研發效能建設從簡單指標考覈過渡到精細化過程管理、體系化地結果評估成爲可能。

在這 5 個原則的指引和約束之下，幾年以來我們分階段進行了一系列的效能提升工作，具體見後續章節。

效能建設實踐過程

4.3.1 研發日常工作版塊梳理

研發效能的第一個階段始於3年前，在《技術一號位的方法論【業務篇】——如何畫業務大圖》一文中我提到過當時團隊面臨的一些情況以及通過業務大圖如何做了組織關係的設計和調整，其他方面的具體細節本文不再重複，只講一下研發效能方面做的一些事情。

1. 劃分業務領域和版塊，讓所有人，包括協作的上下游產品團隊、運營團隊都從過去雜亂的認知演變爲 “產品功能——業務領域——工作版塊”體系，並且根據團隊成員的個人特徵、主觀意願、未來期望劃分人員與工作版塊的對應關係，在研發團隊內部形成版塊 Owner 的角色。
2. 分析各個工作板塊中的關係，以 “C 端核心業務鏈路” 和 “B 端管控鏈路” 爲兩大核心板塊，以“穩定性建設、研發效能、運營效能建設” 爲橫向底層支撐性板塊，以 “業務生態建設” 爲未來發展布局版塊 組合成了目前的工作版塊，整個體系已經穩定存在了 3 年，支撐了業務各個發展階段的需求，到目前來看也不需要做大的調整。
3. 客戶技術服務工作內容多、雜、要求高、易被投訴，當時佔用大量的研發資源，非常明顯地威脅到了業務需求的交付，在無法擴張團隊規模的情況下，把技術服務體系暫時歸攏到 “穩定性建設、研發效能、運營效能建設”版塊中，構建了多級技術服務體系，分別是 “機器人+知識庫”作爲第一級， “穩定性建設、研發效能、運營效能建設”版塊的外包同學作爲技術服務的第二級，該板塊的 Owner 作爲技術服務的第三級，各個業務領域的一線研發同學作爲最後一級。

在研發效能第一階段的建設完成之後，基本上形成了一個比較好的局面，整個技術團隊的工作效能在“需求的承接和交付數量”方面，較過去有明顯的提升，同時過去一直遺漏的客戶服務方面也有了體系化的支持工作，成爲了綜合性研發團隊的重要工作版塊。

4.3.2 研發日常工作流程梳理

隨着業務的持續發展，從最開始的啓動期到後面逐步規模化起量期，業務需求也從追求數量變成追求質量。在進入這個業務階段之後，過去的大量的成塊的產品功能不再是研發工作內容的主體，變成了大量的分散的業務需求，在既有功能上適配新的業務場景、在舊的技術架構上適配新的業務需求成了主要內容。因此在代碼量上會呈現出非常明顯的下降的趨勢，而技術方案文檔、技術自測報告隨着需求變多也呈現出了上升的趨勢，一線研發同學在這個階段工作內容和重點也發生了變化。隨着迭代發佈的增多，產品功能日趨複雜，在技術團隊規模不變甚至小部分萎縮的情況下，需求交付數量提升意味着需求交付質量在不做干預的情況下必然下降。這也是研發效能建設進入第二階段以後呈現出的特徵和重點建設維度。

我們在業務起步期間也有各種各樣的研發流程，但是存在這樣的問題：

1. 研發流程覆蓋面非常窄，只涵蓋了需求研發的生命週期，而且這個涵蓋面比較窄的流程也完全是以 CI/CD 系統爲主導的，就是簡單的 “寫代碼、做部署、做測試、做發佈、做驗證”。
2. 大量的日常工作沒有協作流程，更不用提協作流程的關鍵環節的識別和標準的定製
3. 後續根據實際情況補充了一些流程，但是流程本身停留在文檔和宣貫層面，執行過程依靠相關人員人肉記憶和維護，流程執行不充分，並且新增的流程讓團隊成員覺得效率變低，投入在非研發工作方面的精力變大，存在一定的牴觸情緒，流程的執行依靠一線成員的自覺和管理者的抽查。

在團隊出現了“非技術系統 BUG 而是人員本職工作執行不到位引起線上故障的黑天鵝事件”之後，所有的矛盾終於集中爆發，大家經過覆盤第一次改變了自己的視角，從一線執行者的視角轉變爲管理者視角，看到了流程的重要性和必要性。後面作爲團隊 Lleader，我個人也有所反思，過去的流程都只停留在了文檔中，就覺得團隊已經有流程了，經過此次也感受到了從決策到執行其實存在着巨大的鴻溝，而這個鴻溝只能先由管理者做出努力想辦法填平，纔可能順利地完成決策和執行的過度。因此後面把團隊是否有工作流程的標準設定爲：

1. 是否有工作流程的說明文檔，講清楚流程參與的角色有哪些，不同的角色參與哪些環節，不同流程環節產出物的標準是什麼。
2. 團隊成員是否都知道這個流程的全部信息，如果有一個人不知道這個流程的全貌，就說明流程約等於沒有。
3. 這個流程要用公司的工作流引擎驅動，不同人在不同階段在線參與流程的推進和停退工作，如果上游的產物符合標準，則依靠上游輸入完成本環節的工作，形成標準產出物，反饋到在線的流程中，最後推進流程向下一個環節流轉。每個環節的流轉都有即時通信工具（本團隊爲釘釘）提示到相關人員，既包括執行人，也包括關心流程進展的管理者。

隨後把涉及到研發過程（網上各種文章都有，不再細聊）的幾個核心流程在線化，避免有人因爲忘記而導致關鍵流程環節被跳過。這些流程包括：

1. 產品需求開發流程
2. 產品需求提測流程
3. 產品需求發佈流程
4. 系統保障應急流程

每個流程存在很多的環節，都是用宜搭的流程設計器完成搭建和後續的運轉。從整個流程從上線到目前爲止，已經分別有 100+流程完成流轉，下一個階段的效能建設，就是基於這些流程在運轉過程中產生的各種時間數據、狀態變化數據形成團隊的效能基線，從而能讓管理者發現各個指標的變化情況，確定問題根因，進行鍼對性的改進。

4.3.3 研發日常工作任務數字化

除了工作流程補充和流程的在線化之外，過去使用 AONE 來記錄業務需求和各種 BUG，整體記錄還是圍繞着業務需求來做的，而當前的業務階段對技術團隊的要求已經發生了變化，並且實際工作版塊中，業務需求研發的比例呈現一定的下降趨勢，客戶技術服務、穩定性問題的 解決、業務合規、數據安全、風控、技術方案設計等板塊工作量提升明顯，過去的工作模式和管控方法已經不能適應這一變化，除了過去管理比較好的業務需求之外，在各種事情的信息的同步、對焦、決策、跟進、解決執行方面都處於比較混亂的狀態，嚴重影響到了整個團隊的研發效能。因此在今年下半年開始構建整個團隊的綜合工作版塊大圖，使用 teambition 工具記錄、跟進研發團隊承載的所有各種任務，完成任務的信息化。具體的研發任務大類有：業務需求開發、業務風險、渠道客戶對接、客戶技術服務工單、協同任務、應急任務等。利用 teambiton 的統計功能，設定各類型任務的周、月報表，可以看到每日的任務延期情況，看到每日的業務風險增量。同時還利用“迭代”功能版塊進行過去的業務需求的管理，同時將同一時期的各種其他類型的研發任務都囊括在迭代中，解決過去迭代內容不清晰，研發人員打黑工還要背鍋的問題，徹底看到整個小微型團隊的整體負載情況。也利用“甘特圖”版塊進行整個迭代中各個任務的項目管理工作，讓工作進度看得見。同時 teambition 新出的“資源管理”功能，能夠把團隊所有人員每天的工作負載情況非常直觀地展示出來，能看到某個人某一天需要完成的任務的併發情況，讓研發人員徹底告別做了事情卻不被知道，每天併發做幾件事情的同時還需要繼續接緊急需求的問題，也讓業務各方看到單個人的工作負載，從而更好更合理地設定任務的優先級。總之，整個團隊從 9 月份開始整體工作進入了信息時代，利用各種指標和與之對應的工作流開展研發工作數字化的實踐。

以業務風險爲例，整個業務風險大類下面包括了“業務發展風險”、“客戶投訴風險”、“數據安全風險”、“業務合規風險”、“研發進度風險”、“系統穩定性風險”這些子類，每天研發團隊的“15 分鐘項目管理日會” 通過溝通對焦穫得各個小組和版塊和業務領域的各種風險問題，同時也能知道目前正在進行的工作的進展怎麼樣，是不是有新的緊急的事情要插隊支持，於是很容易就能根據甘特圖看到被緊急任務波及的相關同學是否還有餘量承接需求，該研發人員是否併發度過高，是否需要根據任務的優先級調整其他任務的計劃。一線研發同學不再需要在每個迭代覆盤時解釋爲什麼某個事情有延遲，系統內的記錄一目瞭然，這樣一來也可以讓管理者在優化過程管理時，更精準地定位某個迭代中真正導致延期的事情和原因。

再以企業客戶技術服務工單類的任務爲例，我們構建了不同類型的客戶技術服務的流程，針對普通客戶和核心大客戶提供不同的服務 SLA，在有限的人力下，分別在工單響應速度、工單結單速度、工單各級滲透率（從 L1 滲透到 L2，從 L2 滲透到 L3，從 L3 滲透到 L4）等方面都設定了不同的標準，來滿足不同客戶的要求。同時利用工單日會覆盤流程，將客戶工單中提到的到問題轉爲產品功能需求、技術系統 BUG、技術效率工具建設的源動力，通過客戶側的聲音和反饋來驅動整個業務、具體的產品、以及研發團隊自身的成長。通過任務系統完成了工單處理的基本的信息化工作，後續配合相關的指標體系來繼續指引團隊的數字化實踐。

最終，團隊整體也多加了三個大的流程，

1. “15 分鐘項目管理日會——團隊週會”流程，主要感知風險、感知研發進度、調整任務計劃和安排；
2. 客戶服務流程，包括工單處理子流程、工單日會覆盤流程、工單轉需求流程、工單轉風險流程；
3. 團隊內部運營、建設流程，主要是在其他流程的驅動和產出物的基礎上不斷完成團隊日常工作運轉，補充團隊技術能力和業務能力

這幾個流程圍繞着 4 個核心研發工作流程，共同覆蓋了研發團隊日常工作的各個板塊，使大的協作必有流程，流程關鍵環節必有產出標準，整體控制研發日常工作過程質量。因爲數據安全的關係，這裏只給出整體的項目截圖，不再給出具體的一些指標和圖表細節，如下圖：

圖13 Linkedmall 團隊研發任務項目管理

圖中頂部菜單可以看到以上文字中提到的幾個重要的信息化工具，迭代、甘特圖、統計、資源管理、研發效能流程（宜搭流程讓日常工作流程線上化）。由此也可以看出，研發團隊效能提升需要多種多樣的工具支持，是綜合的、複雜的，不是單一工具就能解決的。

4.3.4 研發效能目標體系建設

參考 3.3 研發效能的指標體系 一節中的內容可知，整個研發效能指標體系內容較多較複雜，這裏不再重複。在有了指標體系的基礎之上，我們可以結合目前團隊、業務的實際情況構建團隊研發效能建設的短期目標——隨着實踐的不斷深入，團隊在極爲有限的人力的情況下，選擇當下最影響效能的幾個方面作爲短期（一個財年）階段性的目標（更加細粒度到具體事項和時間線的目標拆解內容就不再詳細展示了，請勿認爲目標不符合 SMART 原則）：

1. 短期目標

• 團隊方面
• 提升一線研發同學的綜合能力，使全員具備複雜業務系統建模及架構設計能力，在現有業務複雜度和技術命題的場景下能夠獨擋一面。
• 降低團隊成員在日常工作中非業務研發工作投入的精力，降低團隊協作成本。
• 技術方面
• 持續通過過程管理保障業務需求交付質量和數量，確保交付能力在基線之上
• 持續通過效率工具體系的建設降低各角色員工日常工作成本，提升單人和協作工作效率
• 業務方面
• 逐步構建業務指標體系，讓研發工作結果有標準可衡量。
• 逐步嘗試業務落地過程數字化實踐，進行業務洞察體系的早期建設

2. 中長期（2-3 年）的效能建設目標如下：

• 團隊方面
• 在有條件的情況下擴大團隊規模。目標解釋說明：團隊效能工作做得再好，在對團隊需求承載能力和交付數量、質量方面，可能不如增加幾個人見效更快。但是需要注意的是，加人只在研發效能的某些維度會有很好的效果，但是加人解決不了信息傳遞不暢的問題，更解決不了決策存在缺陷偏差的問題，所以加人雖然見效快，但是仍然是簡單粗暴的，在精細化過程管理方面該做的功課還是得做。
• 構建合理的團隊梯隊，將整個效能建設做到體系化地傳承和傳遞，確保效能方面的認知始終上下一致。
• 通過合理的方式方法把科學的效能提升方法傳遞到上下游的協作團隊，統一各方認知，形成步調一致的實踐行爲，在對研發效能形成組織保障的同時，力爭對業務效能建設產生積極影響。
• 技術方面
• 對常見的研發效能指標形成準確的、自動化的衡量工具，或使用已有的效能產品工具完成研發常見效能指標的跟蹤
• 構建適用於業務研發團隊的效率工具體系，確保易擴展、易複用
• 結合團隊目前的技術體系特徵，構建對應的技術系統和工具解決穩定性、日常發佈運維過程中存在的效率問題，持續實踐業務落地過程數字化，構建相關技術能力。
• 業務方面
• 利用既有的實踐基礎，構建覆蓋面廣、複用性強的指標體系系統
• 在業務落地過程數字化實踐方面總結經驗理論，進行業務洞察體系的中長期建設

3. 效能建設的終局目標

• 利用已有的效能產品結合部分自建的工具系統，構成橫跨整個研發生命週期、覆蓋研發日常工作各個板塊的過程管理體系和系統，並且形成與之配套的工作流和方法論，建立與之對應的準確地、無干擾的、能反饋團隊效能真實情況的指標體系。
• 完成構建通用的業務洞察系統，通過工具系統、方法論來提升整體做業務的效能，降低決策成本，提升決策正確率，以科學的系統和體系保障業務發展。

4.3.5 研發產出效果度量體系建設

研發產出效果度量體系建設是一個更加長期的建設，需要的是一個業務洞察系統，能夠從完整的業務維度完成研發工作、運營工作、產品工作、商務工作等對業務發展的影響和評估，這裏就不再繼續展開了。

實踐案例總結

從團隊現狀背景信息，到研發效能建設原則的確定，再到階段性地研發效能建設實踐，拋開以往的各種最佳實踐和宣傳，就實事求是地基於現狀、結合指標體系進行鍼對性的提升，並且明確短期建設、長期建設分別要達到什麼樣的目標，這樣才能真正地、全面地解決團隊的研發效能問題。基於理論指導實踐，再基於實踐總結並完善理論，並且逐步將複雜深奧的理論簡化以後形成大多數人可以理解的、易於執行的方法論，就完成了從實踐到理論再到實踐的過程。接下來就帶着大家一起看下經過簡化的方法論是什麼樣的。

研發效能到底應該怎麼做

我們常常看到很多團隊的研發效能建設會集中在代碼量、需求交付量、需求交付時間上，可是讀者朋友們需要關注的是當前您所在的團隊的背景是否和那些常見的“最佳實踐”類似，如果類似的話，直接參考去做沒有任何問題，但是需要考慮的是：如果按照網上最佳實踐的方式做了一些調整，後面“感覺”還是覺得效能有問題，那個時候該怎麼辦呢？所以大家需要再回過頭，看一下毛主席的實踐論中寫到的實踐和理論的辯證關係，“最佳實踐” 只能是在一定條件下的、不全面的 “實踐”，雖然是最佳的，但是還是實踐的範疇；而理論是通過感性到理性、片面到全面的指導性的，來源於實踐但是超脫於實踐的，因此大家在花費力氣實踐別人的最佳實踐的時候，也別忘了提升理論，從最基礎最核心的本質來看研發效能究竟是什麼，應該怎麼提升，這樣有了理論的加持、有了某些場景的最佳實踐的指引，才能讓您的團隊真正在效能方面有提升。同時也要注意的是，談論研發效能的提升，不能只談論研發或技術，這樣得出的結論是就是局部的，不是適用於整體的，而應該也談論組織、業務，這樣纔是全面的，纔是一個團隊在研發效能領域面對的真實的情況。本文作者也給大家提供一些簡單的容易實操的方法，能夠讓所有人都知道什麼是效能的提升，如何提升個人的效能，如何提升團隊的效能。

從最抽象的層面看工作的本質

我們每天在公司工作的內容，綜合下來就是以下幾個流的不斷交互和輪轉：

1. 信息流，從信息的產生方，通過某種形式被感知，再被傳遞，到達依賴這些信息做決策的節點，這個節點可能是某個人，也可能是某幾個人，也可能是某個團隊，整個信息的傳遞過程中也存在着二次加工，傳遞的信息與原始信息相比可能附加了新的決策後的信息，或被覆蓋也可能。
2. 決策流，在某個層面的決策者拿到信息後，進行分析、決策，形成新的信息，這些信息有的會繼續傳遞下去，有的轉爲執行的指令，觸發執行流。
3. 執行流，就是在和決策者對齊決策信息後，開始進行實際執行的過程，包括了確定目標、明確策略、具體執行、反饋上報調整、最終完成執行這樣一系列的環節。
4. 價值流，就是一個或多個業務中，各種各樣的執行流所得的結果，匯聚成整體的對他人、客戶的價值流，沿着價值鏈傳遞，完成價值創造和獲利的整個鏈條的循環。
5. 利益流，就是在整個價值創建和變現週期內，參與價值創造與變現的各方所獲得的利益的過程，利益分配的形態，構成了整個利益流。這個鏈條是最隱蔽的，也是最重要的鏈條，很多局面的形成和破解，往往最終都會聚焦在利益流上面。在建設優質、積極的價值鏈條時，要關注利益流的某個環節是否可能會影響、干擾甚至阻塞了整體價值鏈的運轉；而在打破一些劣質、消極的價值鏈條時，則要關注利益流的某個環節是不是不當的、是所有問題產生的根源，從而進行鍼對性的改造，讓劣質、消極的利益鏈條發展變化，轉變爲優質、積極的利益鏈條。利益流還有很多內容可談，未來會在 《技術一號位的方法論——組織篇》中深入展開討論。

這些承載着不同的載體、扮演着不同的角色的鏈條共同推進着工作內容的向前發展，效能問題就隱藏在某些鏈條當中，想要找出所有的效能問題，就得明白你的工作中存在哪些“流”、涉及到了哪些“流”，最終如何讓他們彼此順暢地相互配合，而不是相互阻塞。

分析你的工作信息流和決策流是什麼樣的，構建出整個團隊的工作板塊大圖

以當前我所在的研發團隊爲例，如下圖所示：

圖14 研發團隊工作板塊大圖（未標出價值流和利益流）

整個團隊由“一線研發同學、領域 Owner、團隊 Leader、大團隊領導、協作方、協作方領導”構成了一個自下而上的“信息——決策”體系 和 自上而下的“決策——執行”體系，同時對 B 端客和穩定性收攏到一個團隊，所以團隊內部也存在着面向客戶的協作流。

可以看到信息的來源有以下幾種：客戶、協作團隊、團隊內部、信息系統、橫向團隊，因此這些信息的流動和流向是不一樣的，有些是一線研發同學第一感知的，有些是業務領域 Owner 首先感知的，有些是團隊 Leader 首先感知的，這些不同的信息源發出的信息會沿着不同的協作流程完成“傳遞、分析處理、決策、執行”這樣的路徑。從這個圖中可以非常清晰地看到一個團隊的 Leader 是他負責的板塊的信息匯聚點，扮演着信息上傳下達的關鍵角色，同時也是很多決策執行的發起者和責任人。由此也可以看出，一個研發團隊的 Leader 工作內容和職責，如果整個板塊梳理不清、沒有好的工作方法、沒有流程來規範協同過程，那麼基本上團隊的 Leader 本人非常容易形成瓶頸。（題外話：從圖中可以看到，團隊 Leader 本身的職責範圍和工作內容已經和一線研發人員的工作內容和職責有較大差異了，因此這個圖中的各種角色的能力模型都是不一樣的，不能對各個角色沒有標準和要求，也不能對所有的角色使用同一套標準和要求，這兩種情況都是不實事求是的）在整理出團隊工作版塊和信息流、決策流、執行流的大圖之後，就可以結合團隊的實際情況來看整個團隊是不是缺乏必要的流程，關鍵流程是否有阻塞，流程環節是否沒有產出物的標準導致協作成本高，最終哪裏需要調整。

根據工作板塊大圖和各種“流”尋找讓信息流轉出現問題的點

根據上一小節畫出的工作版塊和業務流程圖，開始結合具體的問題進行分析，分析是人的問題，則增加團隊的培養，提升團隊成員的認知，促進其實踐行爲的改善；如果是機制流程的問題，則建立健全機制流程，考慮到協作各方是誰，分別扮演什麼角色，核心利益訴求是什麼；以此類推，在信息維度關注信息的收集、存儲、傳遞，在決策維度關注信息的感知、分析、決策過程是否存在問題；在執行維度關注 目標、策略、執行、階段覆盤調整、取得結果這些方面是否存在問題，在價值方面關注價值的營銷、銷售、交付、收款等方面是否存在問題；在利益方面要看收入、利潤、利益分配是否合理等。

結合指標體系，針對性地做改進提升

在找到團隊內影響效能的點之後，利用好各種各樣的效能產品、效率工具，整體設計佈局，基於指標體系感知實際情況，分階段分目標進行調整實踐，就能知道現在效能的基線是什麼，經過實踐以後哪些有提升，最終效能改進到什麼程度，是否滿足階段性的效能建設目標，是否可以啓動下一個階段的效能改進實踐，以此循環往復，完成高效的、綜合性的團隊的建設工作，保障業務發展，完成團隊使命。

作者：賀科學（晨末）

原文鏈接

本文爲阿里雲原創內容，未經允許不得轉載。