1、提升研發效率的實踐過程中存在哪些痛點？
2. 提高研發效率的系統方法論：MARI方法論
看點一：研發效率提升過程中存在哪些痛點？
研發團隊面臨的績效挑戰體現在多個??方面：
1、技術團隊研發效率低，加班多，交付速度慢且質量差，業務方滿意度低；
2、協作效率低，等待返工造成浪費，工程師滿意度低；
3、研發人力資源配置困難，項目不斷延期、超預算，管理滿意度低。
因此，提升研發效率成為越來越多團隊關注的焦點，但目前還缺乏明確的實施路徑。 基于CMEA與客戶持續溝通的實踐，我們發現研發效率的實踐面臨以下痛點：
針對提升研發效率實踐中面臨的這些問題，提出了MARI方法論。
第二點：研發效率提升方法論：MARI方法論
MARI 是一套軟件開發、性能測量應用和實際實施的方法論。 其目的是建立績效衡量和改進的閉環。
研發團隊結合實際情況，定位價值流中的關鍵障礙作為改進點后，可以應用MARI方法論對問題進行定量評估、分析和拆解，獲得性能瓶頸、改進機會等洞察，然后實施他們融入到軟件工程實踐的逐步優化和效率的實際提高。 接下來我們將結合案例介紹MARI方法的應用。
?
措施
研發效率的本質是更快、更好、更低成本地交付更好的商業價值——這短短一句話包含了交付的效率、質量、成本、能力和商業價值等多個維度。
研發成效是如此多維度，全面衡量它的成本非常高，而且大廠商使用的指標可能并不適用于團隊自身的情況。 因此，在開始改進活動之前，團隊需要牢記“以終為始”，根據團隊的實際痛點確認改進目標，然后根據目標選擇衡量指標。
比如，A研發團隊最近最頭疼的就是頻繁的項目延期和業務方的投訴。 但縱觀研發的各個環節，產品、開發、測試、運維團隊卻互相指責，都說人手不夠。 問題是什么？ 在這種情況下，需求交付周期這個反映價值流轉效率、可以深入到各個環節的指標，就是一個合適的北極星指標。
分析
在有關研發有效性的討論中，我們經?？吹截S田生產方式著名創始人大野耐一的一句話：不懂數據的人都是壞人，最壞的人是只看數據的人。 人們。 僅僅停留在數據上進行衡量是一件非常危險的事情。 重要的是從數據中洞察問題并指導改進。
圖中我們列出了三種分析方法：
如果已采取措施，可用于驗證改進措施的有效性； 需要注意的是，觀察趨勢時也可以不選擇平均值。 第80個百分位值或許能夠更好地排除異常值并反映總體情況。
在深入研發流程時，建議避免使用容易受噪聲影響的指標，例如提交數、代碼行數等。 司馬邑設計的基于深度代碼分析的“代碼等效性”可以解決這個問題。 該指標也已被信通院開源生態監測平臺采用。
A團隊通過分析發現，在深入挖掘近期需求交付周期時，只有研發環節的交付時間明顯高于歷史水平。 關聯研發團隊近期代碼當量趨勢，發現研發團隊人均編碼生產力呈現明顯下降趨勢。
?
審查與改進
綜合以上分析，A團隊研發流程的效率降低很可能是導致需求交付緩慢的瓶頸。 那么設定KPI并要求所有開發人員提高效率還不夠嗎？
事情沒那么簡單。 找到關鍵瓶頸并不等于找到根本原因。 沒有進行根本原因調查和分析，任務就直接分配到一線。 開發者缺乏明確的改進方向指引，只能盲目延長工作時間、增加工作量。 即使投入資源，也很難共同提升，進而損害團隊的工作體驗。 懶惰的管理者對此負有主要責任。
以A團隊的問題為例，研發過程中效率的下降可能是由系統、流程、工具、人員等多種因素造成的，也可能受到上游需求環節的影響。 從眾多的影響因素中不斷排除并找到根本原因，是一項非常復雜的工作。 一方面，我們可以借助相關指標和數據繼續分析； 另一方面，組織專題調研，傾聽一線動態和聲音。 這部分工作是純數據分析無法替代的。
?
A團隊的一項調查發現，近期研發團隊中代碼貢獻出現了明顯的不均，團隊中25%的開發人員貢獻了83%的工作量。 由于任務拆分和調度不合理，大量工作堆積在少數開發人員身上，導致這些開發人員超負荷工作，而其他大多數開發人員則處于等待狀態，整體效率下降。
?
?
針對這一問題，A團隊一方面調配資源補充人力缺口，降低人均流量負載，減少開發者不斷切換任務造成的浪費； 另一方面效率與效能的區別與聯系，它調整任務分配以減少任務之間的耦合。 這避免了對關鍵人力的依賴和不均勻的繁忙日程。
持續改進的閉環
性能改進無法通過定期沖刺來實現。 為了實現有效和可持續的績效改進，需要將測量和改進實踐融入到日常研發流程中，并持續跟蹤和持續改進。
MARI方法強調構建研發績效管理閉環。 基于數據解讀制定改進計劃后，需要持續測量和觀察績效趨勢，進一步分析和解釋改進后的指標數據，快速反饋改進計劃的有效性。 如果持續改進一段時間，持續改進效果不明顯，邊際效應降低。 這種機制也將幫助團隊做出快速判斷，及時將資源投入到下一步的改進項目中。
實施改進后，A團隊繼續衡量北極星指標，觀察到需求交付周期比三個月前沒有改善的情況縮短了29%效率與效能的區別與聯系，需求吞吐量也有所增加。 可見，此前的改進計劃是有效的，研發資源和任務也進行了調整。 分配和性能改進之間確實存在相關性。
?
為了避免出現“以指標為導向的改進”情況，A 團隊將其他指標關聯起來作為檢查和平衡。 例如，衡量人均生產力，驗證更快的需求交付確實與研發團隊產出效率的提升有關，而不是因為需求被拆分成更精細的細節； 測量測試缺陷率和在線缺陷率，以驗證更快的需求交付與不以質量為代價。 可以根據以往改進的影響范圍來選擇制衡指標。
以上就是本次回答的全部內容。 A團隊最終撥開迷霧，找到了阻礙快速交付的關鍵瓶頸，并進行了針對性的優化。 最后用一張圖總結一下MARI方法的最佳實踐：
?
