過程中持續(xù)回望，以確保方向正確。我常常在諸如此類的困局該如何突破？行業(yè)中其實已經(jīng)讓我們有了繼續(xù)的底氣。在新一期中《研發(fā)效能紅寶的實戰(zhàn)經(jīng)驗。書里沒什么高深的理論，都是真問題和核心內(nèi)容·做正確的事：確保研發(fā)方向與業(yè)務(wù)戰(zhàn)略一致·正確地做事：精益思想、敏捷原則和DevOps實踐的落地·構(gòu)建高效協(xié)同的組織結(jié)構(gòu)和文化氛圍·研發(fā)效能度量的核心原則和常見誤區(qū)·如何構(gòu)建自動化數(shù)據(jù)采集分析平臺·如何將數(shù)據(jù)洞察轉(zhuǎn)化為可執(zhí)行改進措施·云原生、低代碼等新興技術(shù)對效能的影響·組織如何為技術(shù)變革做好準備·實用工具與方法：本書提供經(jīng)實踐驗證的可操作方法、明確的度量指標和流程優(yōu)化框架，幫助你·前沿視野：匯聚十余位專家的洞察，讓你把握行業(yè)趨勢，了解·思考與變革動力：幫助你診斷團隊效能瓶頸，根據(jù)北京思碼逸科技有限公司任晶磊、李旺、關(guān)欽杰、吳衡林、姬俊鵬、陳靖賢劉剛、高明國、徐陳飛、王歡、張樂0202最佳實踐03AI時代的研發(fā)效能錄為什么技術(shù)高管匯報一定要用數(shù)據(jù)說話？正確做事一直以來，“做正確的事，比正確地做事更重要”似乎成了某種政被業(yè)務(wù)PUA時的常用話術(shù)—當我們在管理會上興奮地講述產(chǎn)研團隊通過各項舉措把需求吞吐量“做正確的事更重要”隱含著一個假設(shè)：我們能明確知道什么是“正確的事”。但實際上，有幾個人能做到呢？反正我不能。作為CEO，帶著思碼逸確”的，而是要在實際場景中和大量種子用戶反復(fù)迭代驗證。最終，這個項目被我們掛起了。從產(chǎn)正確做事軟件工程幾十年發(fā)展正體現(xiàn)了這種理念。從瀑布模型承認軟件項目很難從一開始就明確所有正確的需求。而只有采用正確的做事方法，在持續(xù)交付的過共贏的合作模式，而不是錯誤地認定哪一方該為“正確的事”負全責。雙方應(yīng)該共同以“正確的事”“正確地做事”舉例：需求價值評分·在一個需求創(chuàng)立之初或者進行需求評審時·在一個需求創(chuàng)立之初或者進行需求評審時，業(yè)務(wù)方和產(chǎn)研應(yīng)共同設(shè)立需求要達成·對于可量化的目標（如點擊率建議設(shè)定具體的目標值；如果不能量化，可以主研共同回顧需求價值目標。如果有量化指標，可按實際值除以目標值計算評分，比為2；如果只有主觀評級，按實際達成的正確做事我們還可以通過數(shù)據(jù)度量幫助團隊不斷精進，基于某幾個迭代或周期內(nèi)需求價值評分的統(tǒng)計，可其實需求價值評分也可以“豐儉由人”，通過需求分層分類。以敏捷項目為例，可以自然按epic所以盡量能夠做到評價和回顧。實際當中，只有一部分userstory設(shè)置了目標除了需求分層，還可以通過分類劃定需要價值評分的范圍或者排除不必要的類型。例如，我們一個客戶將業(yè)務(wù)需求分為目標型、風控型、合作方要求等。目標型需要走需求價值評分的流程，但合作方要求就跳過，這種需求……懂得都懂。有了分類，很多企業(yè)還會看每個迭代各類需求做了進一步地，單純看需求數(shù)量仍存在不足，因為需求的顆粒度不一致，導(dǎo)致統(tǒng)計結(jié)果不能準確反映正確做事我們不妨類比制造業(yè)，在國產(chǎn)車崛起之前，豐田的生產(chǎn)實踐。數(shù)據(jù)在這個過程中起到了不可或缺的作用，它不僅是洞察問題的關(guān)鍵，更是持續(xù)改進的基礎(chǔ)。類似地，做好軟件工程，也同樣需要數(shù)據(jù)驅(qū)動。簡單認為靠自己和團隊交流就能掌控局面，就像認為單靠“人治”能高效管理大規(guī)模工業(yè)一種落后的思維方式。軟件研發(fā)是一項極為龐雜的系統(tǒng)性工程，哪怕管理能力再卓越、記憶力再超群，也沒有人能事無巨細地看到每一個細節(jié)。這些都需要依賴成熟的研發(fā)數(shù)據(jù)分析工具，下圖是思正確做事管理動作“知易行難”，沒有數(shù)據(jù)抓手難以貫徹執(zhí)行我們服務(wù)的一家傳媒集團，正在進行數(shù)字化轉(zhuǎn)型，研發(fā)部門花了一年多、大幾百萬上了一系列戶通過數(shù)據(jù)看板追蹤全集團各個項目的DevOps成熟度，實現(xiàn)了正確做事下圖展示了思碼逸DevInsight中CI/CD指標的看板，評級按照信通院《研發(fā)運營一體化(DevOps）能力成熟度模型》標準劃分-說起來，很多評級企業(yè)就是用我們的產(chǎn)品達到標準在度數(shù)據(jù)乃技術(shù)高管的“生存之道”最后，講數(shù)也是技術(shù)高管“生存”的需要。想象你的下一個管理層年終總結(jié)會，技術(shù)團隊不能干-正確做事某證券度量方案某證券度量方案當然，整研發(fā)數(shù)據(jù)并沒想象中的那么簡單，很多管理者還停留在“安排個人把各工具里的數(shù)導(dǎo)出來看看”的誤解中-讓我來猜下你會看到什么：各路數(shù)字或有或無、忽高忽低，項目團隊一鍋粥，理解；一線開發(fā)行為飄逸，指標異常多，看哪都不靠譜，看誰都有問題……哎，路上的確坑不少，最佳實踐從0到1搭建研發(fā)效能建設(shè)體系持續(xù)改進：數(shù)據(jù)驅(qū)動的指標體系演化之路吳衡林I某軟件研發(fā)科技公司研發(fā)效能負責人PMO視角下的研發(fā)體系建設(shè)六步法京東科技研發(fā)效能度量的大體系與小實踐哈啰一站式業(yè)產(chǎn)研協(xié)同平臺的建設(shè)與實踐08最佳實踐研發(fā)效能核心03組織效能評估潛能。實現(xiàn)研發(fā)效能提升的手段涵蓋工具搭建·高管層能夠洞察研發(fā)全過程和成果產(chǎn)出，拓寬管理半徑；借助研發(fā)數(shù)據(jù)的反饋，從全局視角審視·項目經(jīng)理可以實時跟進項目研發(fā)的過程，充分了解項目各個環(huán)節(jié)·開發(fā)者可以量化自身表現(xiàn)，正確識別自己的優(yōu)勢與不足，更有針對性最佳實踐1.效能問題說不清：研發(fā)效能的量化評估方法尚不清晰，難以確定公司當前的研發(fā)效能表現(xiàn)處于何這些難題的根源在于缺乏系統(tǒng)性的效能建設(shè)閉環(huán)思路。無效的度量可能源于選用的指標不夠精確，導(dǎo)致無法揭示存在的問題；而即使執(zhí)行了多項改進措施卻收效甚微，往往是因為未能從源頭找準問效能建設(shè)方法論并借助量化指標對問題進行精準評估；而MARI則專注于通過建立研發(fā)效能數(shù)字化體系，利用數(shù)據(jù)最佳實踐從全局來看，首先需要構(gòu)建研發(fā)效能度量平臺，以反映組織效能的現(xiàn)狀和薄弱環(huán)節(jié)。通過運用GQM方法搭建度量體系，衡量效能是否具和代碼質(zhì)量規(guī)范三大方面的改進需求。隨后，針對發(fā)現(xiàn)的問題采取相應(yīng)改進措施，并通過度量準確的度量指標對于反映研發(fā)效能問題至關(guān)重要。以往常用代碼行數(shù)、故事點和工時等衡量開發(fā)人員的代碼產(chǎn)出，但這種方式存在固有缺陷，如代碼行數(shù)統(tǒng)計易受空行、注釋等因素影響，故事為此，推薦采用思碼逸的“代碼當量”這一核心度量指標。代碼當量基于語法樹解析，直接量化代碼復(fù)雜度變化，剔除了代碼風格、換行和注釋等干擾因素。同時，它還根據(jù)代碼操作類型和難度動態(tài)調(diào)整權(quán)重，比如重視新增和邏輯類代碼，以此促進編碼中的高質(zhì)量、創(chuàng)新性工作。目前，最佳實踐擁有客觀的底層指標后，不僅能統(tǒng)一研發(fā)各角色對代碼工作的認識，還可利用當量與其他領(lǐng)域指標結(jié)合，進行跨域分析。例如，代碼當量的穩(wěn)定性可以作為需求顆粒度的校準單位，估算研發(fā)產(chǎn)案例分析：全面認知組織研發(fā)效能數(shù)據(jù)顯示—企業(yè)交付效率下滑（需求交付數(shù)量同比下降20%，交付時間延長30%代碼質(zhì)量問1.任務(wù)流轉(zhuǎn)效率低：漫長的等待狀態(tài)占據(jù)了任務(wù)流轉(zhuǎn)的主要時間，表明團隊協(xié)作可能存在障礙，最佳實踐交付效果。改進策略包括合理拆分任務(wù)顆粒度，標準化拆分流程，這不僅可以積累拆分經(jīng)驗，也3.可維護性較差：代碼的注釋和單元測試覆蓋率均低于行業(yè)平均水平（僅達到30%尤其是部分復(fù)雜且頻繁調(diào)用的函數(shù)未得到有效覆蓋。提高覆蓋率有助于團隊成員更好地理解和協(xié)同工作，而提升單測覆蓋率則有利于在開發(fā)早期即發(fā)現(xiàn)并解決問題，從而降低信息傳遞誤解造成的不良影設(shè)定提升目標，驗證提效成果思碼逸提供了公司內(nèi)部基線數(shù)據(jù)和開源項目極限數(shù)據(jù)作參考，向內(nèi)可借鑒公司歷史數(shù)據(jù)，按同期效能水平設(shè)定提升目標；外部則以開源項目數(shù)據(jù)和行業(yè)基線為基礎(chǔ)，助力各團隊與同類型、同行至于提效成果的驗證，則需通過追蹤問題項目的數(shù)據(jù)變化，獲得實時反饋，及時調(diào)整或強化提效最佳實踐對企業(yè)客戶來講，年終效能盤點對開展第二年工作規(guī)劃和設(shè)定目標具有推動作用。在業(yè)務(wù)快速發(fā)展難以進行全面細致的盤點。在盤點實踐中，通過研發(fā)效能平臺構(gòu)建數(shù)據(jù)抓手，能夠助力團隊完成高年終盤點三要素，聚焦“人、事、錢”在此種情況下，年終盤點應(yīng)聚焦“人、事、錢”三大核心資產(chǎn)，確保關(guān)鍵內(nèi)容有效梳理與評估，最佳實踐兩個方法，高效搞定年終盤點第三，“墻即是門”原則啟示我們：在遭遇困難時要學會轉(zhuǎn)換視角，視挑戰(zhàn)為最后，“魚不論水”智慧提倡：要充分利用已有的資源來解決問題，而不是一味地尋求更多資源。在盤點過程中，高效利用數(shù)據(jù)作為溝通工具至關(guān)重要。數(shù)據(jù)如同通用語言，壁壘，解決諸如需求補量不足、頻繁變更導(dǎo)致的研發(fā)返工等問題。運用數(shù)據(jù)數(shù)據(jù)不僅是爭取資源、調(diào)整人員配置及管理預(yù)期的重要依據(jù)。在上下游溝通中，關(guān)注關(guān)鍵指標數(shù)據(jù)至關(guān)重要。這些數(shù)據(jù)如同團隊間交流的通用語言，有助于我們深入理解團隊表現(xiàn)與狀態(tài)。通過挖掘最佳實踐客戶應(yīng)用案例針對這兩個問題，該客戶期望引入一個能有效衡量需求顆粒度和復(fù)雜度的指標和一個更客觀、去除與事務(wù)分析結(jié)合，重點度量分析產(chǎn)出和效率；引入價值度量、當量流分布指標，了解研發(fā)實際工作織整體指標、各部門橫向?qū)Ρ戎笜说龋员銖牟煌S度和顆粒度來觀察數(shù)據(jù)，了解自身在行業(yè)中的度量體系落地：面向中高層管理者，聚焦精力管理·面向價值，判斷投入與產(chǎn)出是否合理·了解團隊水平在行業(yè)中的位置，評價整體效能在構(gòu)建金融價值需求指標的過程中，量化需求價值是最大難題。在客戶與思碼逸充分討論后，明確具體做法是：在產(chǎn)品經(jīng)理提出需求時，要設(shè)定明最佳實踐在需求實現(xiàn)過程中，通過度量需求上線后的日活、月活響應(yīng)時間等來監(jiān)測需求是否達成預(yù)期目標。此外，通過關(guān)聯(lián)每個代碼提交（commit）與需求的關(guān)系，獲取每項需求的實際開發(fā)工作量數(shù)據(jù)，分析工作量與需求轉(zhuǎn)化率之間的相關(guān)性。由此，識別出哪些需求的工作量較小但轉(zhuǎn)化率高，哪些工作量大而轉(zhuǎn)化率低，并分析此類需求的特征，從效率和質(zhì)量角度挖掘優(yōu)化空間，將未來工作聚焦于在部門效率方面，除了關(guān)注歷史同比外，也要橫向比較。管理者需要關(guān)注到，各部門效率排序情況開發(fā)階段造成效率水平差異的情況？在這類指標設(shè)定中，由于各部門業(yè)務(wù)存在明顯差異，需要對各度量體系落地：面向“一線管理者”，識別具體問題·識別產(chǎn)出、效率和資源問題·管理研發(fā)團隊成員效能最佳實踐可以評估在一個迭代周期內(nèi)，工作量是否主要集中在產(chǎn)生價值的新需求上，還是更多用于變更和返最佳實踐某客戶內(nèi)勤與外包比例為1:2，需要每季度對外包供應(yīng)商進行考核評價。思碼逸為該客戶提供了一外包績效現(xiàn)狀外包績效評價體系位數(shù)區(qū)間法以區(qū)分細微差異。選取8-9個核心指標，根據(jù)外包人員在各指標中的相對位置打分—最佳實踐利用數(shù)據(jù)抓手，輔助資源決策此時應(yīng)優(yōu)先關(guān)注提高團隊的貢獻均衡度。通過優(yōu)化任務(wù)分配，使團隊成員更均衡地分配到任務(wù)，從在許多企業(yè)中，項目和團隊是兩個維度，每個新項目啟動時，需要從不同這意味著人員可能在不同項目中被復(fù)用。這種復(fù)用影響了人員的專注度，進而影響其效率。通過相關(guān)性的分析，發(fā)現(xiàn)當一個人專注于一個項目執(zhí)行同類型任務(wù)時，其專注度較高；而當其需要在兩個可以量化團隊的工作飽和度，并根據(jù)需要合理調(diào)配資源或增加人手。在向領(lǐng)導(dǎo)提出訴求時，可以基通過思碼逸產(chǎn)品中的技能標簽功能，企業(yè)能夠依據(jù)外包人員在代碼貢獻中實際使用的開發(fā)語言、庫和第三方庫情況，精確評估供應(yīng)商的技術(shù)實力與特定領(lǐng)域?qū)ｉL，并據(jù)此匹配符合最佳實踐之路研發(fā)效能意味著團隊能夠持續(xù)地為用戶產(chǎn)生有效價值的效率，通常包括有效性（效率（E?ciency）和可持續(xù)性（Sustainability）三個方面。簡單來說，就是能否長期、高效地開發(fā)出有價值的產(chǎn)品。本文，將圍繞研發(fā)效能體系建設(shè)這一核心主題，詳細分享在建立研發(fā)效能體研發(fā)現(xiàn)狀與研發(fā)效能實施的核心需求解讀……·制定研發(fā)效能指標，進行數(shù)字化管理。公司可以根據(jù)各自的規(guī)模、發(fā)展程度，選取研發(fā)關(guān)鍵節(jié)點最佳實踐整體來看，公司要想實現(xiàn)研發(fā)效能實施的高效建設(shè)，需要持續(xù)探索行業(yè)最佳效能實踐，走在行業(yè)前研發(fā)效能實施過程拆解及成果展示階段一：建立研發(fā)效能體系。收集數(shù)據(jù)時側(cè)重質(zhì)量方面的數(shù)據(jù)，但該階段收集的數(shù)據(jù)相對分散，未階段三：通過內(nèi)部總結(jié)和外部溝通學習，提取北極星指標，優(yōu)化效能報告碼逸代碼當量指標，如累積代碼當量、月人均代碼當量、千隊效率。此外，通過分析投入產(chǎn)出比指標，評估團隊成員貢獻均衡度及工作飽和度，判斷當前團隊調(diào)整，進一步提升實用和有效性。具體而言，團隊從最初的按月收集各指標數(shù)據(jù)的簡單分析，升級為度量數(shù)據(jù)總表統(tǒng)一管理的模式，分別從需求、開發(fā)、測試、質(zhì)量幾方面開展分析總結(jié)，并組織研最佳實踐蓋率、代碼注釋率、模塊性、資源分配等數(shù)據(jù)。歷經(jīng)多年探索，團隊研發(fā)效能實施成效顯著，表代碼深度分析技術(shù)的應(yīng)用實踐總結(jié)第二，先從全局找瓶頸，再深入細節(jié)。先進行全局整體的分析，定位瓶頸，再進入需要詳細分析第三，通過主觀的方式來評價、提高效能。實際工作中，因開發(fā)工具和語言的區(qū)別，我們可能無法對個人的效能以某一個具體的數(shù)據(jù)進行評價，那就盡量公平地主觀測量它。盡管主觀評價難以第四，關(guān)注個人維度的指標。提高效能。關(guān)注開發(fā)人員的高頻活動，為其提供自動化支持，通過最佳實踐預(yù)置高頻使用指標，驅(qū)動項目交付成本與能力維度上。比如，公司在發(fā)布/交付項目時，通常比較關(guān)注交付的效率該階段的高頻使用指標，包括缺陷相應(yīng)時間、部署失敗率、服務(wù)恢復(fù)時長、部署頻率等，以實現(xiàn)最佳實踐單純的主觀回答通常很難說服團隊，因此我們可以用數(shù)據(jù)說話?？陀^、理性的數(shù)據(jù)資料，能夠幫助我們充分驗證策略和結(jié)論的有效性，爭取到更多角色和資源的支持，進而推進項目實施進度。此外，每一個項目都是團隊共同參與和努力的結(jié)果，因此在面臨困難時，需要及時根據(jù)問題制定改進措施，并不斷優(yōu)化。其中，為了提升效率，我們也可以引入適用的工具，比如思碼逸的研發(fā)效能的改進提升是一個持續(xù)性工作，執(zhí)行過程中需要形成閉環(huán)，不斷優(yōu)化進而穩(wěn)步提升。下研發(fā)效能的提高，需要整個公司在研發(fā)流程、工程方法、個人效能和文化管理等方面進行精心設(shè)對于開發(fā)團隊來說，可以從優(yōu)化開發(fā)編碼規(guī)范、開展業(yè)務(wù)培訓(xùn)、開展團隊技能分享、引入適用的代碼質(zhì)量監(jiān)測工具、利用思碼逸系統(tǒng)監(jiān)測研發(fā)效能情況并及時進行問題修復(fù)等方面入手。測試團最佳實踐基于此，提升研發(fā)效能的核心思路在于實現(xiàn)收益最大化。實現(xiàn)這一思路的前提是對公司戰(zhàn)略具備深從PMO角度拆解度量體系搭建全過程最佳實踐分工有清晰的認識，這種確定性為項目經(jīng)理提供了穩(wěn)定的基礎(chǔ)，降低了因規(guī)劃模糊或頻繁變動導(dǎo)致敏捷開發(fā)方法的基礎(chǔ)。這樣的項目有助于項目經(jīng)理了解每個團隊成員的性格特點，建立流暢的溝通臨較高的關(guān)注與期望，但只要具備科學的方法論和明確的改進計劃，實際上更易獲得高層認可與資事本和看板流轉(zhuǎn)工具，未能充分發(fā)揮其項目管理功能。這導(dǎo)致研發(fā)過程缺乏有效的組織與監(jiān)控，難3.需求變更頻繁：項目存在大量需求變更，且未能遵循敏捷原則-不得隨意變更。這導(dǎo)致燃盡圖呈現(xiàn)直線狀，無法準確反映團隊實際工作進度，違背了敏捷開發(fā)的核針對以上問題，我們聚焦于實施真正的敏捷開發(fā)，并取得了顯著成效。以下是我們改進試點項目的最佳實踐得以清晰洞察項目A在敏捷實踐深化前后在代碼當量等方面的顯著差異，有力證明了敏捷實踐對提4.完善敏捷流程與任務(wù)類型管理：隨著敏捷實踐的深入深入探討工具使用、項目管理等方面的改進建議。這些溝通機制的強化不僅促進了團隊成員間的理在推廣樣板至更多項目時，需要深度思考自己所在的組織環(huán)境，深入分析組織文化、可關(guān)鍵角色特點。例如，詳細分析并深入考慮領(lǐng)導(dǎo)層、項目團隊成員及關(guān)鍵干系人的性格、擅長領(lǐng)域首先，擴大項目規(guī)模：由單一的項目A擴展至涵的主要挑戰(zhàn)是如何贏得新試點團隊的信任。為此，我們采取了以下兩個關(guān)鍵措施：并跟隨新的工作思路。第二，引入思碼逸平臺提供的度量數(shù)據(jù)（如代碼缺陷、代碼當量等通過其次，兼容不同項目組與擴充方法論：在推廣過程中，我們不斷調(diào)整和完善敏捷框架，以適應(yīng)不同項目組的特性和需求。具體做法包括：第一，增加新任務(wù)類型：在典型敏捷任務(wù)類型的基礎(chǔ)上，根據(jù)項目特殊性引入提測單、測試計劃、測試用例等新任務(wù)類型，以增強方法論的適用性。第二，形成通用方法論：通過收集和整合各種實踐案例，提煉出一套通用的敏捷流程方案，如在項目管理平臺中的work?owschema，可應(yīng)用于多個項目中，標志著方法論的通用化與標準化。隨著項目規(guī)游環(huán)節(jié)涉及更廣泛的維度，敏捷開發(fā)方法論顯現(xiàn)出瓶頸。因此，我們決定引入瀑布式最佳實踐國內(nèi)市場環(huán)境下，敏捷開發(fā)在解決端到端交付問題上存在局限性。針對toB定制化項目，因其上型需求。我們創(chuàng)造性地將所有項目的需求轉(zhuǎn)化為Epic（針對大型需求使其既滿足瀑布式開發(fā)中當研發(fā)規(guī)范流程比較穩(wěn)定、形成一套方法論后，需要縱廣泛借鑒并采用市場上的成熟度量方法論。然而，面對海量數(shù)據(jù)與眾多指標，我們意識到需要篩選1.降低客觀指標權(quán)重：在績效考核中，即使所有指標加起來，在整體評分中的比例仍保持較低，2.賦予領(lǐng)導(dǎo)充分解釋權(quán)：指標本身是冰冷的，當某項指標不佳時，并不一定是團隊自身的問題，最佳實踐度量專業(yè)（如前后端開發(fā)、測試、運維）相對容易，但過分關(guān)注個體度量并不能從組織層面提升研發(fā)效能。妙盈當前處于轉(zhuǎn)型的第六階段，認識到過度關(guān)注個人或單一專業(yè)指標并不足以準確反映端到端交付成果，因為結(jié)果往往是組織整體協(xié)作的產(chǎn)物，且單個專業(yè)指標的表現(xiàn)可能受多影響。例如，開發(fā)任務(wù)的延遲（delay）往往并非僅由開發(fā)者個體責任造成，可能是需求變更、依多種開發(fā)模式共存的挑戰(zhàn)，但通過前期形成的兼容各類項目的方法在過去兩年間，妙盈經(jīng)歷了團隊規(guī)模與業(yè)務(wù)范圍的大幅擴張，應(yīng)用開發(fā)團隊百人左右，業(yè)務(wù)覆蓋領(lǐng)域從單一方向擴展至全產(chǎn)業(yè)鏈。隨著團隊與業(yè)務(wù)復(fù)雜度的目情況日益多元化。在此過程中，我們逐步構(gòu)建起一套更為復(fù)雜、全面的度量框架總結(jié)PMO在負責研發(fā)度量時，項目無疑是重要的切入點，但由于不并非唯一的關(guān)注焦點。研發(fā)效能的衡量遠不止于度量本身，更要包含最佳實踐為什么要進行研發(fā)數(shù)字化·全面了解研發(fā)現(xiàn)狀·獲得技術(shù)團隊管理的數(shù)據(jù)抓手·具備進行重大決策的數(shù)據(jù)依據(jù)通過量化度量這五要素，實現(xiàn)數(shù)據(jù)可觀測、決策有據(jù)可依、改進有抓手、結(jié)果可控的目標，從而最佳實踐最佳實踐在研發(fā)過程中，主要聚焦于三大關(guān)鍵要素：需求、應(yīng)用和人。需求是產(chǎn)品價有價值均通過需求的形式得以實現(xiàn)和交付。應(yīng)用則是承載這些價值的具體在線服務(wù)，任何價值的變更都將體現(xiàn)在服務(wù)的更新和優(yōu)化上，最終通過服務(wù)提供給用戶。此外，“人”作為研發(fā)過程中不可或缺的組成部分，扮演著至關(guān)重要的角色。研發(fā)團隊和組織由人構(gòu)成，他們在整個在實施過程中，各個角色的關(guān)注點各不相同：高層管理者著重于公司的整體表現(xiàn)、團隊間現(xiàn)狀、發(fā)展趨勢及共性問題；一線團隊負責人更關(guān)注其團隊與其他團隊的橫向?qū)Ρ龋约皥F隊內(nèi)部的狀態(tài)和確定了度量什么、為誰度量，接下來就需要制定數(shù)字化度量實施舉措。度量對象涵蓋了需求、應(yīng)用針對不同角色的需求，我們需要合理選擇和設(shè)計各種數(shù)字化度量指標，并進行有效的分級和結(jié)構(gòu)化將指標劃分為三個層次，從而全面反映不同層面的情況，不斷下最佳實踐樣性和異構(gòu)性，涵蓋了生產(chǎn)流程各個環(huán)節(jié)所產(chǎn)生的各類信息。由于這些數(shù)據(jù)在結(jié)構(gòu)、格式以及關(guān)聯(lián)首先會被導(dǎo)入至數(shù)據(jù)湖這一中間環(huán)節(jié)，在此階段對數(shù)據(jù)進行深度清洗和整合，確保數(shù)據(jù)質(zhì)量和一致接著，基于預(yù)先設(shè)計和定義好的一套科學嚴謹?shù)闹笜四Ｐ?，從?shù)據(jù)湖中提取所需數(shù)據(jù)進行復(fù)雜計算與分析，進而提煉出能夠反映實際業(yè)務(wù)狀況的關(guān)鍵指標值。隨后，這些經(jīng)過計算得出的指標會進一步被整合并聚合到不同的業(yè)務(wù)層次，如應(yīng)用層面、項目層面乃至團隊層面，形成多維度、多層次的管理層、項目經(jīng)理或是具體執(zhí)行團隊成員等。最后，模型將為每個特定角色提供與其職責相關(guān)的趨勢分析圖表，通過對相關(guān)指標的歷史變化和未來走勢進行可視化展現(xiàn)，從而輔助決策者做出更為精多維度度量實踐在模型構(gòu)建中，針對效率、質(zhì)量、用戶體驗、成本和技術(shù)先進性五大技術(shù)要素，我們實現(xiàn)了多角度最佳實踐第一步是指標定義階段，由各領(lǐng)域的專家共同參與，結(jié)合技術(shù)五要素全面考慮，制定出符合現(xiàn)狀并針對度量反映出的問題進行深度挖掘，并制定相應(yīng)的專項治理策略。治理并非一次性工作，而是需要持續(xù)運營和提升。為此，我們構(gòu)建了常態(tài)化的運營機制，包括運營雙周報、月度和季度匯報，以我們期望通過建立一套有效的效率度量體系，使管理者能夠全局掌握組織運行效率最佳實踐在效率度量方面，我們關(guān)注組織整體、各團隊乃至各個角色的工作效率。針對研發(fā)流程中不同階段的關(guān)鍵活動進行梳理，提煉出一些結(jié)果指標和過程指標，將這些度量維度劃分為“交付資源效率”最佳實踐對于產(chǎn)品輸出的價值衡量，我們在過程指標中引入OKR中的重為參照系，通過計算實際表現(xiàn)與基準之間的差距（gap來進行度量和提升工作的展開。通過這交付效率主要關(guān)注的是產(chǎn)品設(shè)計及研發(fā)交付的時效性。核心結(jié)果指標包含兩大部分：一是產(chǎn)品設(shè)計針對排期中需求堆積率的問題進行了專項治理。通通過對整體流程進行規(guī)范化梳理，并在需求狀態(tài)流轉(zhuǎn)階段引入研發(fā)最佳實踐在質(zhì)量管理方面，管理層、一線團隊負責人（TL）、質(zhì)量保證（QA）部上故障問題。以往在缺乏數(shù)字化度量手段時，頻繁遭遇上級對于故障頻發(fā)現(xiàn)象的質(zhì)疑。面對管理針對這些問題，我們以數(shù)字化手段為核心，旨在讓各層級角色全面了解組織的整體質(zhì)量狀況，最終降低線上故障率，并確保日常治理效果可量化評估。為此，我們著眼于交付結(jié)果的質(zhì)量和關(guān)注質(zhì)量度量模型在構(gòu)建質(zhì)量度量模型時，我們綜合考量了團隊、應(yīng)用和項目三個層面，形成多維度的質(zhì)量視圖?！ぴ趹?yīng)用維度，聚焦于團隊所負責的所有應(yīng)用集在應(yīng)用層面的質(zhì)量表現(xiàn)。單個應(yīng)用質(zhì)量細分為穩(wěn)定性、健康度和風險指數(shù)三個方面，每個維度下最佳實踐通過這種逐層細化、逐級抽象的方式，如同金字塔結(jié)構(gòu)一樣，我們整合了大量的具體質(zhì)量指標，將它們歸類并上升至更高層次的維度，最終形成了一個多視角、多層次的質(zhì)量度量模型。這一模型與先前所介紹的度量框架緊密呼應(yīng)，旨在提供一套完整且有針對性的質(zhì)量評估體系，以利于持質(zhì)量指標梳理接下來，我們對各項指標的系統(tǒng)梳理，對各個維度指標的重要性及其對最終結(jié)果的影響程度進行等級劃分，明確每個指標的統(tǒng)計口徑、評級標準以及數(shù)據(jù)來源，并制定對應(yīng)的改進策略。收集數(shù)據(jù)后，將在平臺上直觀展示各團隊的變化趨勢及不同維度指標的表現(xiàn)情況。若某個團隊或業(yè)務(wù)線出現(xiàn)異常，圖表將快速凸顯。針對下降趨勢，我們運用數(shù)據(jù)洞察功能深度分析原因，并提出具體此外，我們設(shè)立了整體指標排行榜，根據(jù)評分標準對比公司內(nèi)部各項指標優(yōu)劣，以便重點提升較差的指標。同時，平臺也展示了應(yīng)用級別的排行，便于識別和深入分析存在問題的應(yīng)用，并進行在質(zhì)量度量領(lǐng)域，亮點在于我們建立了一套全面的定量評價體系，能從多維度洞悉并定位質(zhì)量薄然而，難點在于歷史技術(shù)債務(wù)對度量過程造成影響。對此，我們采取的做法是設(shè)定基準，側(cè)重關(guān)注后續(xù)質(zhì)量增長趨勢而非過度回溯治理歷史債務(wù)。去年，通過瘦身項目，我們精簡代碼、降低業(yè)統(tǒng)一規(guī)則與流程的100%落地執(zhí)行，這些規(guī)范的有效執(zhí)行使得治理效果具有可觀測性，從各項指作為互聯(lián)網(wǎng)公司，用戶體驗成為決定用戶留存的重要因素，因此我們著力于構(gòu)建用戶體驗度量體通過用戶體驗度量，我們能精準評估用戶感受，找準優(yōu)化治理的方向。不同于基于應(yīng)用的質(zhì)量度量，用戶體驗度量聚焦于用戶感知最直接的頁面維度，以頁面為基本單位進行精細化評估，從而最佳實踐用戶體驗度量模型精心選取和定義了相關(guān)度量指標。在實際度量過程中，最具挑戰(zhàn)性的任務(wù)之一是如何確立統(tǒng)計口徑最佳實踐40然后線上埋點實時追蹤。評價標準制定上，借鑒業(yè)界同類產(chǎn)品指標，結(jié)合自家實際情況，制定了合理的治理及優(yōu)化目標。度量和優(yōu)化工作已取得良好成效，有效降低了因體驗問題導(dǎo)致的用這一指標主要面向技術(shù)團隊管理者、基礎(chǔ)平臺部門和研發(fā)團隊，著重解決新技術(shù)、新架構(gòu)在實際應(yīng)用中的落地難、推廣難問題。在確保業(yè)務(wù)正常運行的同時，力求最大化資源利用率，避免不同團隊“重復(fù)造輪子”現(xiàn)象。為此，我們集中收集并確立技術(shù)先進性核心指標，作為內(nèi)部技技術(shù)先進性度量模型在公司內(nèi)部，針對不同的技術(shù)棧，我們構(gòu)建了技術(shù)先進性度量模型，按框架先進性、質(zhì)量保障先進性、效率保障先進性、運維保障先進性四個維度細分度量對象，并在各維度下識別和添加了相應(yīng)的衡量指標。這一過程并非單方面決策，而是通過與數(shù)字化委員會、各個領(lǐng)域?qū)＜乙约芭e例來說，在框架先進性維度，我們推廣如TCDv這類內(nèi)部公共包和中間件的集中管理技術(shù)，此外，技術(shù)先進性中最突出的是壓測和混沌工程的推廣，越來越多的業(yè)務(wù)線接入后，提高了系技術(shù)先進性度量體系的亮點在于構(gòu)建了定量化評價標準，從多維度評估和指導(dǎo)業(yè)務(wù)線引入先進我們設(shè)立數(shù)字化委員會，聯(lián)合各團隊專家代表共同探討，并通過試點驗證效果，以達成廣泛接最佳實踐此度量體系的收益頗豐：首先，增強了技術(shù)團隊追求技術(shù)領(lǐng)先的動力，通過團隊間的定期排名與總結(jié)通過落地研發(fā)技術(shù)五要素，我們實現(xiàn)了研發(fā)過程的數(shù)字化管理，確保日常服務(wù)穩(wěn)定運行，并對各要素進行全面監(jiān)控和持續(xù)治理。數(shù)字化管理意識的導(dǎo)入促進了組織升級，管理層擁有了結(jié)構(gòu)化、數(shù)字化手段發(fā)現(xiàn)問題并加以解決，治理效果可通過度量結(jié)果反饋。在此過程中，我們積累了寶貴然而，局部效率的提升仍有不足，我們需要緊跟業(yè)界趨勢，從DevOps實踐出模式-由項目導(dǎo)向轉(zhuǎn)向產(chǎn)品導(dǎo)向，借鑒價值流交付理念，實現(xiàn)業(yè)務(wù)與研發(fā)的深度融合，確保與價最佳實踐旦建立就始終保持不變。本文將分享如何以集團的研發(fā)效能度量體系作為指引，在所屬部門落地適04集團研發(fā)效能度量體系京東研發(fā)效能建設(shè)旨在將產(chǎn)研團隊緊密對接業(yè)務(wù)目標，體現(xiàn)其對業(yè)務(wù)價值的貢獻。為此，京東建立了以收入、成本、效率、體驗為四大維度的研發(fā)效能度量體系，通過價值導(dǎo)向量化評估，結(jié)合管理機制準確衡量研發(fā)效能，確保產(chǎn)研活動始終以創(chuàng)造業(yè)務(wù)價值為核心驅(qū)動力，引導(dǎo)產(chǎn)研活動緊·產(chǎn)研資源如何分配·投入產(chǎn)出是否合理·產(chǎn)研資源如何有效調(diào)配最佳實踐項目的交付收入。而技術(shù)布局與基礎(chǔ)支撐團隊·首要原則是關(guān)注價值流的整體優(yōu)化，而非孤立地優(yōu)化單個環(huán)節(jié)。這意味著在提升效率·其次，聚焦最終成果，而非僅看某個階段的工作輸出。即使團隊短時間內(nèi)產(chǎn)出最佳實踐小需要根據(jù)團隊實際情況深入分析，不可單純依據(jù)數(shù)值高低評判優(yōu)劣。值得應(yīng)被忽視或剔除，它們往往是發(fā)現(xiàn)問題的關(guān)鍵線索。例如在分析需求吞吐量研發(fā)效能小實踐前置動作在實施研發(fā)效能實踐時，通常涉及的角色多元，尤其是項目經(jīng)理和QA（質(zhì)量保證）人員在推動研發(fā)全流程的深入理解和對效能變化的敏銳感知，可以有效扮演效能驅(qū)動者的角色。QA不再局限于在著手實踐前，建議充分研究行業(yè)內(nèi)的書籍、文章和方法論，了解潛在的挑戰(zhàn)與已有實踐，以建立并以此為基礎(chǔ)選取相關(guān)指標進行量化衡量。初期可通過低成本手段，如Excel記錄數(shù)據(jù)、手動收集信息，制作簡易圖表展示現(xiàn)狀。隨著團隊對研發(fā)效能度量價值的認可加深，可逐步升級至利用低代最佳實踐定制化度量體系北極星指標如同團隊方向標，涵蓋產(chǎn)能、效率、質(zhì)量等多個維度，選取每個維度中最關(guān)鍵的一兩個指標，直觀反映團隊的整體表現(xiàn)和目標方向。例如，產(chǎn)研交付周期作為整體效能的代表性指標，可景下，快速響應(yīng)和交付客戶需求至關(guān)重要。遵循GSM方法論，我們提煉了四個關(guān)鍵信號來衡量該·各個環(huán)節(jié)間無等待時間，項目流程無縫銜接，節(jié)奏緊湊，顯示團隊資源得以充分利用，從而有效最佳實踐·在追求產(chǎn)能提升的同時，產(chǎn)品用戶滿意度必須保持高位，確保產(chǎn)能增長不是通過犧牲質(zhì)量或過度·團隊產(chǎn)出應(yīng)能有效支撐業(yè)務(wù)發(fā)展，選擇價值高且對用戶和業(yè)務(wù)有益的需求進行開發(fā)，而非僅僅追基于以上考量，我們設(shè)定了兩項北極星指標：人均需求吞吐量和需求量有助于在同一團隊內(nèi)部以及不同團隊間進行橫向比較，通過觀察人我們關(guān)注以下兩個指標：故障新增速度和故障平均修復(fù)時長，確保在產(chǎn)能提升的情況下，確保質(zhì)量在質(zhì)量維度上，著重四個指標：故障新增數(shù)、故障修復(fù)時長、缺陷新增數(shù)和冒煙通過率持續(xù)改進與持續(xù)實踐最佳實踐4.指標體系和展示邏輯需經(jīng)多次迭代優(yōu)化，可視化的形式可以包括餅圖、趨勢圖或表格等，隨著5.效能實踐應(yīng)全員參與，涉及產(chǎn)品、研發(fā)、測試等多個角色，必要時還可聯(lián)動運營等部門，確保6.構(gòu)建開放透明的團隊文化對于成功實施效能度量極為關(guān)鍵。避免將效能度量與個人績效機械掛采用了低代碼平臺構(gòu)建數(shù)據(jù)大屏，展示規(guī)范水位、質(zhì)量、bug分析、新增代碼和項目進度等多維度盡管評分制度的引入帶來了一定壓力，但我們意識到過度依賴數(shù)據(jù)評估團隊存在局限性，因此在后行數(shù)據(jù)收集和定制分析。通過整合BI工具，我們快速定制圖表，并開放底層數(shù)據(jù)源給各個研發(fā)團最佳實踐48總結(jié)第二，學會借力，避免自行一套。公司內(nèi)部已有的指第五，建立開放透明的團隊文化和探索創(chuàng)新的改最佳實踐建設(shè)與實踐面對互聯(lián)網(wǎng)行業(yè)近年來出現(xiàn)的困境和降本增效需求，哈啰在兩年前遭遇類似問題。本次分享，將圍繞哈啰兩年前所遇困境、采取的解決方案及成效展開，通過一套體系化平臺能力建設(shè)與運營策略，結(jié)合沉淀數(shù)據(jù)驗證該方案的有效性。在這個過程中，將分別從組織層面、業(yè)務(wù)層面及研發(fā)交互層面闡述設(shè)計方案，并講解如何從眾多度量指標中篩選適合當前階段的關(guān)鍵指標，以此驅(qū)動組織持續(xù)改降本增效背景下組織面臨的困境第一，在數(shù)千人的企業(yè)中，管理層難以進行研發(fā)資源投入與業(yè)務(wù)目標達成的透明化管理（研發(fā)如何落地與支撐業(yè)務(wù)目標導(dǎo)致高層如CEO及各業(yè)務(wù)線負責人無法實時了解資源分配是否與預(yù)期第二，業(yè)務(wù)團隊面臨成本控制和預(yù)期收入匹配難題，投入產(chǎn)出比不高，導(dǎo)致項目預(yù)算與實際投入最佳實踐進而使得基于數(shù)據(jù)的度量與持續(xù)改進工作變得困難。同時，因各團隊遵循的流程差異，導(dǎo)致指標統(tǒng)高效交付體系化系統(tǒng)協(xié)同解決方案一系列后續(xù)問題。然而，僅依賴人工執(zhí)行標準化流程依然存在不確定性，因此我們進一步將研發(fā)過程數(shù)據(jù)得以標準化并有效積累。如此一來，我們就能夠基于這些標準化、結(jié)構(gòu)化的數(shù)據(jù)進行最佳實踐保從戰(zhàn)略規(guī)劃到項目管理、敏捷開發(fā)直至問題跟蹤的全流程一體化，從而實現(xiàn)了與底層工程能力的數(shù)據(jù)進行深入洞察和分析，形成有針對性的改進建議，引導(dǎo)組織各個層級和團隊進度戰(zhàn)略目標能夠被各個業(yè)務(wù)單元有效承接。然后，通過租戶管理劃分多個業(yè)務(wù)線（BU在戰(zhàn)略規(guī)劃階段，以各團隊實際投入資源為基礎(chǔ)，這些數(shù)據(jù)成為下一年度資源規(guī)劃的參照標準，比如人才激勵政策就是依據(jù)個人及團隊的產(chǎn)出數(shù)據(jù)和能力表現(xiàn)制定。整個方案致力于解決公司戰(zhàn)略目隨后各個業(yè)務(wù)團隊根據(jù)此設(shè)定各自的業(yè)務(wù)目標，技術(shù)團隊則設(shè)定與之對應(yīng)的技術(shù)目標以支持業(yè)務(wù)目在組織架構(gòu)上，運用租戶管理模式，將十幾條業(yè)務(wù)線劃分為獨立的業(yè)務(wù)單元（BU以實現(xiàn)資源與目標的隔離管理。從上至下、從左至右觀察，經(jīng)營管理團隊（OLT）負責全局戰(zhàn)略規(guī)劃，而戰(zhàn)略目標經(jīng)過細化后，層層分解至業(yè)務(wù)線（戰(zhàn)役）、子戰(zhàn)役及其對應(yīng)的目標價值，再細分為具體的項目。每個項目與相應(yīng)的業(yè)務(wù)目標掛鉤，解決了管理層如何將戰(zhàn)略目標精確傳遞至各業(yè)務(wù)和技術(shù)團隊的問在實際運作中，通過項目協(xié)同機制來確保戰(zhàn)略目標的實施。通過項目管理，我們確項目的優(yōu)先級，并評估項目風險與價值回報。為了保障這一過程的順利進行，我們采每周五，所有團隊成員會匯總本周在項目和日常工作上花費的時間，包括但不限問題修復(fù)、開發(fā)、測試等各個環(huán)節(jié)，甚至管理層在招聘、團隊規(guī)劃和管理等方面投入的時間也會被最佳實踐這種工時記錄方式不僅有助于精細化管理，更能并與技術(shù)變更關(guān)聯(lián)。當產(chǎn)品發(fā)布后出現(xiàn)生產(chǎn)問題時，我們會按照生產(chǎn)故障跟進流程進行改進，改進就被系統(tǒng)承載并在實際工作中嚴格遵循。同時，我們還會定期進行考核培訓(xùn)，讓團隊成員熟最佳實踐戰(zhàn)役是根據(jù)年度戰(zhàn)略規(guī)劃的具體要求分解而來。例如，年度目標包括實現(xiàn)一億元的營收增長和降低500萬至1000萬元的成本，那么可通過諸如中臺能力下沉、底層技術(shù)方案優(yōu)化、云計算遷移這張圖直觀呈現(xiàn)了每個戰(zhàn)役的重要性及其包含的子戰(zhàn)役數(shù)量、涉及的項目總數(shù)、當前與每月的資源投入狀況，以及與組織層面的年度OKR的關(guān)聯(lián)性。這種方式確保戰(zhàn)役、子戰(zhàn)役、項目與戰(zhàn)略目標之間的有效連接，便于識別資源投入與預(yù)期目標之間是否存在偏差。換言之，戰(zhàn)略一致性旨在1.業(yè)務(wù)分組：根據(jù)不同業(yè)務(wù)發(fā)展階段（成熟業(yè)務(wù)、發(fā)展中業(yè)務(wù)和新業(yè)務(wù)）進行分類管理，因不同業(yè)務(wù)形態(tài)對投入和產(chǎn)出有著不同要求。例如，新業(yè)務(wù)追求快速拓展，允許適度不計成本，而成熟2.戰(zhàn)略規(guī)劃：每年年底，公司會針對各業(yè)務(wù)線進行整體的戰(zhàn)略規(guī)劃，并將規(guī)劃結(jié)果在系統(tǒng)中統(tǒng)一定義為年度目標，確保目標與實際業(yè)務(wù)進程保持一致。結(jié)合每月的業(yè)產(chǎn)研拉通會議，審視實際資3.戰(zhàn)略與資源：提供了直觀的戰(zhàn)役數(shù)據(jù)視圖，展示戰(zhàn)役下所屬的子戰(zhàn)役及關(guān)聯(lián)項目，以及項4.成本控制：我們期望業(yè)務(wù)團隊在制定需求和啟動項目時，能注重開展前期的價值分析，并合理關(guān)注資源分配，而非一味追求速度而不考慮成本。鑒于研發(fā)資源的稀缺性，以及業(yè)務(wù)部門常有許多創(chuàng)新想法亟待落地實施，我們鼓勵研發(fā)團隊主動介入分析，協(xié)助業(yè)務(wù)部門篩選和提煉出最具核我們可以清晰界定每個項目的具體價值和對業(yè)務(wù)的貢獻，從而使研發(fā)人員更好地理解和專注于手頭工作，而非碎片化的日常迭代需求。以項目方式進行管理，有助于梳理和整合需求，將原本幾最佳實踐1.通過戰(zhàn)役結(jié)構(gòu)、完成對子戰(zhàn)役的拆解，關(guān)聯(lián)戰(zhàn)略目標，讓技術(shù)團隊目標更加聚焦，資源規(guī)2.采用戰(zhàn)役結(jié)構(gòu)拆解戰(zhàn)略目標，通過戰(zhàn)役項目和非戰(zhàn)役項目兩種類型進行區(qū)分。滿足哈啰業(yè)務(wù)、技術(shù)團隊的項目數(shù)字化管理，提升項目運作的效率和質(zhì)量。戰(zhàn)役項目主要由軟研團隊承擔，涵蓋大型關(guān)鍵項目和日常需求維護，非戰(zhàn)役項目則主要面向業(yè)務(wù)團隊，側(cè)重于日常的小需求迭代和問關(guān)鍵目標可落地，核心價值可實現(xiàn)。CEO等高層管理人員每兩周會組織評審，關(guān)注所有S級項目4.項目立項、結(jié)項、技術(shù)架構(gòu)方案評審以及價值回溯等環(huán)節(jié)均采用工單化線上管理，以取代原有在項目落地的過程中，我們注意到從業(yè)務(wù)需求到產(chǎn)品實現(xiàn)的環(huán)節(jié)存在脫節(jié)問題。以前，業(yè)務(wù)部門在提交需求時，往往難以找到對應(yīng)團隊的需求對接人，同時產(chǎn)品部門對業(yè)務(wù)需求的響應(yīng)較慢，業(yè)務(wù)需求的進度跟進也不到位。為解決這一困境，我們實施了一套敏捷交付的產(chǎn)品化解決方案，利最佳實踐產(chǎn)品需求，以及這些產(chǎn)品需求的當前研發(fā)進度，從開發(fā)到測試直至上線，實現(xiàn)了業(yè)務(wù)、產(chǎn)品和研在持續(xù)交付方面，我們重點關(guān)注交付流程中的細節(jié)優(yōu)化，尤其是從需求轉(zhuǎn)化到敏捷團隊backlog不過，我們在實踐中針對流程中的效率瓶頸進行了優(yōu)化。傳統(tǒng)的流程流轉(zhuǎn)依賴人工，易導(dǎo)致數(shù)據(jù)復(fù)效率和平均時長等度量指標的準確性。為此，我們通過一些方案實現(xiàn)流程自動流轉(zhuǎn)，減少人工并進行價值回溯。在迭代規(guī)劃階段，由技術(shù)負責人、產(chǎn)品經(jīng)理和技術(shù)項目經(jīng)理共同確定下一迭代將在平臺上進行代碼審核、自測和提測流程，以工單形式提交變更，便于測試團隊進行功能回歸同時，我們利用平臺聚合功能監(jiān)測所有變更是否成功上線，避免分支遺漏，并通過燃盡圖等工具在整個研發(fā)過程中，為了避免研發(fā)團隊在跟進拉分支、提測等環(huán)節(jié)耗費過多精力，我們引入了待辦功能，將所有依賴研發(fā)和測試需要完成的動作轉(zhuǎn)化為待辦子任務(wù)，集中顯示在工作臺上，簡化在研發(fā)效能指標體系建設(shè)過程中，我們從組織目標定義、戰(zhàn)役拆解、項目拆解到業(yè)產(chǎn)協(xié)同，再到敏捷交付流程，融合了產(chǎn)品化方案和研發(fā)流程沉淀至平臺的實踐。通過這一整套方案，我們期望實現(xiàn)需求從業(yè)務(wù)到線上交付全過程的數(shù)據(jù)沉淀，并基于這些數(shù)據(jù)進行深入分析和度量，從而持續(xù)最佳實踐在整個研發(fā)交付流程中，我們涵蓋了需求分析、開發(fā)、測試、發(fā)布和問題反饋等多個階段，并通過整合多種流程和工程能力，確保在每個階段采集并關(guān)聯(lián)關(guān)鍵數(shù)據(jù)，形成有價值的數(shù)據(jù)資產(chǎn)。這為了解決不同業(yè)務(wù)線敏捷流程不一致導(dǎo)致的數(shù)據(jù)口徑不統(tǒng)一問題將來自十幾個子系統(tǒng)的數(shù)據(jù)統(tǒng)一拉入數(shù)倉平臺進行清洗和關(guān)聯(lián)，形成可供分析的高質(zhì)量數(shù)據(jù)集。對于每一個指標，我們對其分子、分母和取數(shù)方法進行了統(tǒng)一定義和全員共識，確保所有角色和最佳實踐在指標體系建設(shè)過程中，我們注意到了整體與局部、節(jié)點與團隊個人之間的平衡關(guān)系，確保指標盡管我們定義的指標眾多，但在實際應(yīng)用中，會根據(jù)業(yè)務(wù)現(xiàn)狀梳理出核心指標和次核心指標，以核心指標牽引改進過程，避免過度強調(diào)非核心指標造成反效果。核心指標主要圍繞資源健康度、落地實踐針對初期面臨的種種困境，我們通過加強工程能力建設(shè)和數(shù)據(jù)驅(qū)動，揭示流程中各個環(huán)節(jié)存在的問題，并借助數(shù)據(jù)分析進行持續(xù)改進。接下來，我們將展示在實際落地實踐中的具體成效。遵循自上而下的邏輯，首先從組織戰(zhàn)略規(guī)劃層面考察實施效果。例如，在組織效能建設(shè)方面，我們通能否有效識別項目進度和潛在風險。此外，還包括了對持續(xù)交付能力、工程能力和生產(chǎn)質(zhì)量等方是否進行了年度價值回溯及其進展情況。通過這張圖表，我們可以直觀評估資源與目標規(guī)劃的匹最佳實踐借助全面線上化的項目管理系統(tǒng)，我們實時監(jiān)控項目風險。系統(tǒng)能自動識別并標記項目異常，通過個人工作臺和釘釘群組推送告警信息，通過“項目經(jīng)營駕駛艙”這一可視化工具，對所有項目關(guān)于質(zhì)量管控方面，我們專注于核心指標的監(jiān)控和提升，旨在通過質(zhì)量數(shù)據(jù)的不斷優(yōu)化促使流程和團隊協(xié)作更為順暢。2022年與2023年7月的數(shù)據(jù)對比顯示，各項關(guān)鍵指標有了顯著進步，例如按時提測率、一次提測通過率、缺陷率（尤其是千行代碼我們每月向CTO匯報影響研發(fā)效率的核心指標，并針對未達預(yù)期或行業(yè)平均標準原因，提出針對性的改進措施與方案，并在后續(xù)月份進行回顧，檢查改進措施的實際效果，以確在資源變動較大時，采用個體度量更為合理，比如研發(fā)測試投入度比、人均交付需求數(shù)以及代碼維度的參與度等。特別是在降本增效背景下，當研發(fā)資源發(fā)生變化時，僅依賴總體數(shù)據(jù)（如人數(shù)研發(fā)測試投入度比體現(xiàn)了測試成熟度、環(huán)境穩(wěn)定性和工具完善度。在研發(fā)投入相對穩(wěn)定時，測試在短期內(nèi)，如果測試參與度不高，意味著測試資源不足，有一部分需要研發(fā)自測。測試參與度越高，執(zhí)行成熟度就有可能越高，從而可以承接更多需求。但對于某些團隊如算法團隊和大數(shù)據(jù)團隊，由于研發(fā)測試比較高，所以關(guān)注點可能不僅僅是測試參與度越高越好，而是研發(fā)自測水平，研發(fā)參與度高可能意味著測試團隊提供了強大的工具支持，如自動化測試用例、數(shù)據(jù)生成工具和在測試執(zhí)行成熟度的評估方面，面對測試資源減少的情況，如何保證效率與質(zhì)量成為了關(guān)鍵。哈啰關(guān)注的核心指標包括研發(fā)測試比、人均新增及執(zhí)行用例數(shù)、人均提交缺陷數(shù)、漏測率以及S1全最佳實踐為了提升全量覆蓋率，哈啰希望結(jié)合自動化和人工測試方法，尤其是在回歸測試階段，通過自動化手段替換部分人工回歸，從而提高整體測試效率。然而，由于系統(tǒng)多年迭代后遺留的不再使用接近99%，這反映出測試環(huán)境趨于穩(wěn)定、測試數(shù)據(jù)問題得到解決，以及自動化測試運行頻繁并得52%提升至約70%，同時，測試環(huán)境的穩(wěn)定性目前保持在99%左右，通每周部署頻次數(shù)據(jù)顯示，盡管哈啰采取兩周一個迭代周期，但發(fā)布并不集中于迭代最后一周，而跟過程、抓結(jié)果、做分析、盯改進，逐步優(yōu)化發(fā)版效率。隨著規(guī)范的實施，APP發(fā)版的整體數(shù)據(jù)在生產(chǎn)環(huán)境管理方面，哈啰建立了統(tǒng)一問題上報機制，對所有生產(chǎn)變更進行嚴格管控。當發(fā)現(xiàn)問總結(jié)1.數(shù)據(jù)可信性：要確保所采集的研發(fā)過程中的各項數(shù)據(jù)精確無誤，若數(shù)據(jù)模糊不清或不夠準確，2.人才可用性：任何提效策略，特別是涉及AI、大 研發(fā)效能研發(fā)效能中的AI度量與度量AI從API測試看企業(yè)系統(tǒng)性落地AI的鴻溝大咖對談｜軟件工程3.0時代，AI落地研效成熟時AI時代的研發(fā)效能目前AI在研發(fā)領(lǐng)域最主要的應(yīng)用場景是代碼補全。那么我們首先想一個問題：識別代碼是否由AI生成，相較于識別一般文本是否由AI生成，哪個更難？每個人的語言表達習慣都存在差異，在這里面找到不同的pattern是相對容易的。而編程語言不一樣，拿Java來說，關(guān)鍵詞只有60多個，其語言組合所形成的空間相對而我們先看看一般文本上識別AIGC的實際效果。OpenAI曾經(jīng)推出過這個服務(wù)，用以識別一段文本到底是不是由人工智能生成的。但很可惜，這個服務(wù)在件工程領(lǐng)域頂級會議）上由上海交通大學主導(dǎo)的工作。他們統(tǒng)計了人寫代碼和AI生成的代碼在token多樣性、異常處理、簡潔性、AI時代的研發(fā)效能·但不論如何，我們最終是想看保留在代碼編輯窗口中的AI生成代碼有多少。我們用“采納”來AI時代的研發(fā)效能·在直接度量方面，AI在比如寫單測、接口測試等各個環(huán)節(jié)都有應(yīng)用，我們直接度度如何等等，通過這些人的反饋來了解大家使用AI的效果。另外，我們還可以通過整個組織的測試用例花費了多少成本等。比如在相同的測試人員的情況下，總結(jié)起來說：度量的方式主要分為生成時度量和生成后度量。其中，有直接度量AI行為效果的指標，也有間接的指標。間接指標可以從交付的效率、質(zhì)量、能力、成本等方面來進行AI時代的研發(fā)效能還有一個觀點想提出來。當我們統(tǒng)計了各類指標數(shù)據(jù)之后，可能會想要跟領(lǐng)導(dǎo)說，AI讓我們的研發(fā)效能整體提升了多少，比如20%—那么這個數(shù)字怎么得出來呢？各家技一些做法，偏向于通過時間估算。大概的思路雖然行業(yè)調(diào)研說程序員有30%的時間在寫代碼，但具體到每一個團隊，實際寫代碼的時間占比可在今天上午的時間里，你有百分之多少的時樣的數(shù)據(jù)，是非常困難和不準確的。但是，你今天上午你花費的成本是明確固定的，用你的月工所以相對而言，成本方面的估算會更準確一些。比如實際當中，我們可以通過一段時間測試團隊的成本和自動化用例數(shù)估算出一個用例的成本，也可以算出修復(fù)一個代碼缺陷的成本等我們再去觀察AI在這些方面是否帶來了一些變化。這些變化就能夠反映出在成本方面的作用。這效能基準數(shù)據(jù)調(diào)研。在調(diào)研過程中，我們發(fā)現(xiàn)使用AI工具和不使用AI工具在數(shù)據(jù)上會呈現(xiàn)出一些康度。以前我們在統(tǒng)計數(shù)據(jù)的時候，并沒有足夠的能力和資源去逐一檢查被度量的對象。比如對于測試的覆蓋度，我們無法一個一個地去檢查每一個用例是否可靠，有沒有只寫了一堆assert再舉另外一家客戶的實例。我們現(xiàn)在可能會使用Sonar來掃描代碼當中的缺陷，但有些漏洞的識別不一定特別有效，比如明文密碼。這算是一種比較嚴重的安全事故，但是在實際當中，由于開發(fā)“手抖”導(dǎo)致密碼明文露出的情況屢見不鮮，要通過Sonar或人工的方式篩查出各式各樣密碼的上下文和指南后，效果就非常不錯。我們一共掃描了9個代碼庫，最后交給人工審查的有140AI時代的研發(fā)效能第二個角度是，將AI應(yīng)用于度量的結(jié)果之上。在我們得到研發(fā)效能數(shù)據(jù)之后，各位可能經(jīng)常會需某段時間的代碼當量人均值（代碼當量是通過程序分析計算的代碼復(fù)雜度和規(guī)模指標灰色的曲線代表同比時段。大體上我們能夠看出一些趨勢，但如果能夠利用AI的話，就可以更加詳細地對發(fā)效能領(lǐng)域知識，可能會讓AI能夠給我們提供更多的建議，從而使得我們在撰寫報告的時候，能軟件研發(fā)效能度量與AI大模型的關(guān)系A(chǔ)I時代的研發(fā)效能每次和技術(shù)圈的朋友們聊天，AI總是在眼前；也有人焦慮，擔心自己的工作會被替代。身處一個由大模型驅(qū)動的躍遷時代，這確實是AI到底為我們的研發(fā)工作帶來了什么？它不是一個虛無縹緲的概念，而是已經(jīng)開始為我們“打工”的真實存在。今天，我想和大家分享一些我們基于真實數(shù)據(jù)和一線實踐得到的觀察與思考。我將-我們能否真正跨越自然語思碼逸從去年發(fā)起了每年一度、以客觀數(shù)據(jù)為基礎(chǔ)的研發(fā)效能基準調(diào)研，這份調(diào)研最大的特點，就是所有數(shù)據(jù)都直接從企業(yè)的研發(fā)工具里來，而不是靠大家填問卷憑“印象”說話。這樣做出來有一個核心概念叫代碼當量。簡單來說，我們不再簡單地數(shù)代碼行數(shù)，而是通過分析代碼的抽象語法樹（AST更科學地度量一次代碼變更的復(fù)雜度和規(guī)模。這讓我們的指標更加客觀，能夠穿AI時代的研發(fā)效能這樣的工具已經(jīng)非常普及，大家用得也很順手。反而是大家在各種技術(shù)大會上聽得最多的測試、運基于代碼當量統(tǒng)計的數(shù)字和我們收集到的主觀反饋高度一致—超過三分之一的企業(yè)都認為AI帶來這或許與老板們的美好想象大相徑庭，傳說實打交道的研發(fā)管理者們已經(jīng)意識到，只有拋棄幻想，才能展開有效、務(wù)實的實踐，DevData的AI時代的研發(fā)效能如果說效率的提升還算樂觀，那質(zhì)量方面的表現(xiàn)就略顯“悲觀”了。有高達4我們可以畫兩個圈來理解這件事：一個圈代表AI目前的能力、確定性和我們對研發(fā)的真實需求和想象。今天，這兩個圈的AI時代的研發(fā)效能我一直認為，研發(fā)組織應(yīng)該在企業(yè)的數(shù)智化轉(zhuǎn)型中扮演引領(lǐng)角色。而要做到這一點，首先要實現(xiàn)研發(fā)自身的智能化。我們可以把這個目標抽象成一個核心KPI，那就是AI覆蓋度□在程序員為了實現(xiàn)這個目標，我們摸索出了一個由“場景識別、目標設(shè)定、流程滲透、效能度量”構(gòu)成的這是最關(guān)鍵的執(zhí)行環(huán)節(jié)。但很快你就會發(fā)現(xiàn)一個問題：通用的AI模型，似乎并不能很好地解決我AI時代的研發(fā)效能我想用API測試這個場景作為一個例子。這個例子我們自己實踐地比較多，體驗也比較充分。非常清晰地展示出，為什么通用AI通常情況下不夠用，以及一個真正的“專家”智能API測試之所以是一個絕佳的試金石，因為它看起來簡單-不就是調(diào)用一個接口，看看返回對不AI時代的研發(fā)效能測試用例時，聰明的“專家”智能體必須有容無法理解知識點之間的深層聯(lián)系。一個真正的“專家”智能體背后，需要有一個高效構(gòu)建和分析這是“最后一公里”的問題。AI生成的測試用例和腳本，如果不能方便地提交入庫，并無縫地接AI時代的研發(fā)效能我們能推倒自然語言與編程之間的那堵墻嗎？聊完了數(shù)據(jù)和實踐，在最后，我想和大家一起做一場思想實驗，去展望一個更長遠的未來。我們所有技術(shù)人，內(nèi)心深處可能都有一個共同的夢想：有一天，我們能徹底跨越自然語言到編程語言自然語言；架構(gòu)師畫的是半結(jié)構(gòu)化的建模語言；而程序員寫的是精確無歧義的編程語言。想讓一個AI時代的研發(fā)效能我在想如何能夠構(gòu)建一種能用于描述軟件需求、設(shè)計和實現(xiàn)的“自然語言”？它雖然是自然語言，如果這個設(shè)想成立，那么從需求到設(shè)計再到實現(xiàn)的鴻溝，就可能被徹底填平。我們不再需要三種這絕不是對我們要求的降低，恰恰相反，它對我們的抽象能力、邏輯能力和表達能力，都提出了AI時代的研發(fā)效能從技術(shù)角度看，AI實踐已初見成效，可類比大數(shù)據(jù)的發(fā)展初期。普適性知識的重要性正在下降，創(chuàng)意和想法變得更為關(guān)鍵。軟件工程3.0時代，AI將作為“外骨骼”增強工程師的能力效能度量的核心在于“發(fā)現(xiàn)問題、引導(dǎo)改進”，而非淪為“績效評估”的工具。而引導(dǎo)改進作為“效能度量的最后一公里”，不能閉門造車，要通過開放合作吸納各方智慧力量，實現(xiàn)從發(fā)現(xiàn)問題到有效改進的良性循環(huán)。AI與研發(fā)效能相結(jié)合，AICoding或智能化代碼助手是非?；鸬馁惖?，成功落地需要三個層次的支撐：模型-更強的模型能處理更復(fù)雜的編程問題；工程-對私域知識及本地工程的理解等；產(chǎn)品-抓住用戶的痛點、解決實際問題。AI時代的研發(fā)效能張樂:2024年已經(jīng)去過去了，想請各位老師一起回顧一下過往。在過去一年，大家在研發(fā)效能部知識和業(yè)務(wù)邏輯，已取得不錯的效果。我們期待未來能有成為標準的AI知識工程產(chǎn)品此外，2024年，降本增效成為技術(shù)高管的核心任務(wù)。在當前形勢下，大家更關(guān)注如何提我認為去年是AI大規(guī)模發(fā)展的元年。此前，我們一直通過在工程的各個領(lǐng)域增加或減少AI時代的研發(fā)效能習才可以掌握的能力，在當下可以通過大模型加速實現(xiàn)（雖然仍然會很大程度依賴于知識庫的應(yīng)用）。在那一刻開始，我意識到普適性我們真正追求的是，在度量發(fā)現(xiàn)問題后，如何指導(dǎo)項目組進行持續(xù)改進，從而真正實現(xiàn)提例如，效能低的團隊本就處于高壓狀態(tài)，再提出改進要求容易引發(fā)他們的抵觸情緒；而效能保證效能決策的專業(yè)性，又能確保執(zhí)行落地因此，我的建議是，效能管理工作不要單打獨斗，要積極尋找合作伙伴。若AI時代的研發(fā)效能在效能提升的最后一公里，責任不應(yīng)僅由效能度量部門承擔。一線管理者的參與對于理解成為關(guān)鍵，可能需要更高層的技術(shù)領(lǐng)導(dǎo)者做出判斷。度量的目的之一是讓有決策權(quán)的人意次大規(guī)模重構(gòu)。通過數(shù)據(jù)分析揭示出需要立即關(guān)注的問題，我們可以促使領(lǐng)導(dǎo)者意識到必張樂：感謝各位老師的分享。研發(fā)效能的提升、效能度量、效能改工程層：對私域知識及本地工程的理解等。比如為了支持基于整個工程、整個倉庫的理解進行代碼解釋或代碼生成，就需要codebase能力的支持（結(jié)合語義檢索、關(guān)鍵有代碼中并以Di?方式展現(xiàn)出來，也需要在工程側(cè)做非常多的工作（如除了讓模型生成修改的代碼外，還要在很短的時間內(nèi)，找到原始代碼中正確的位置，并插入正確的）；產(chǎn)品層：我們無論從哪里切入，都要抓住用戶的痛點、解決實際問題。比如原來是一行一行補全，現(xiàn)在可以在多個地方、多點編輯，并且能預(yù)測用戶下個行為；原來是是代碼。這些體驗提升了“打工