DOD-知乎研發效能提升實踐-艾輝.pdf

《DOD-知乎研發效能提升實踐-艾輝.pdf》由會員分享，可在線閱讀，更多相關《DOD-知乎研發效能提升實踐-艾輝.pdf（38頁珍藏版）》請在三個皮匠報告上搜索。

1、知乎研發效能提升實踐艾輝承辦方：主辦方：自我介紹艾輝艾輝 知乎研發效能負責人，負責知乎一站式效能平臺的建設及研效提升的運營落地。大數據測試技術與實踐與機器學習測試入門與實踐作者。在質量保障體系、穩定性建設、AI 大數據測試、研發效能等領域有豐富積淀。目錄背景：背景：知乎的研發效能起源整體策略：整體策略：數據驅動的全面提效運營：運營：效能運營的技巧平臺能力：平臺能力：一站式效能平臺收益：收益：研發效能提升帶來的變化產品視角：產品視角：產品能力怎么做？總結：總結：提升研發效能最重要的是什么？背景：知乎的研效能起源背景：知乎的研效能起源行業環境研發效能一直是各大互聯網和傳統企業高度重視的領域，尤其是

2、2020 年下半年開始，各行各業開始不斷提及數字化經營和管理，各大中型互聯網公司紛紛加大在研發效能領域的投入。市場變革階段，toC市場飽和，產品的重大變革已經完成，留存甚至比拉新更重要。市場給企業的容錯機會越來越少，在外部環境的擠兌下，企業會越來越注重如何平衡成本、時間和收益。持續不斷的裁員、業務線整合/拆分。增長乏力，降本增效增長乏力，降本增效知乎內部一線員工和管理者的“工作體感”變差產品需求變更多需求質量差研發自測不足、提測質量差需求交付周期長怎么能最快看到效果？跨部門需求合作難產品總是抱怨研發人力不足開不完的復盤會組織規模增長帶來的壓力整體策略：數據驅動的全面提效整體策略：數據驅動的全面

3、提效建設以數據驅動為核心的研發效能模型組織架構效能文化項目流程管理下沉最佳實踐一站式效能平臺科學的度量體系工具工具人人制度制度效能模型：效能運營+管理實踐+工程實踐+Z-one工具平臺。歸根結底：涉及到人、制度、工具三個方面。挖掘數據價值高效的數據分析平臺+敏捷實踐思路，快速洞察團隊研發效能。實踐實踐思路思路項目節奏問題：需求太大、工期偏長、緊急臨時需求插入太多、需求依賴需求質量：PRD 交互圖不完整、需求不完備就開始需求評審其他管理類和工具類問題運營：效能運營的技巧運營：效能運營的技巧找對項目負責人是誰研發團隊的技術負責人為研效提升的直接負責人，是研效提升的受益方，提升技術管理者的參與感。生

4、產關系生產關系找對研效提升負責人是誰研發團隊的技術負責人為研效提升的直接負責人，是研效提升的受益方。并非研發效能組。CTOCTO技術負責人技術負責人業務業務 QAQA效能平臺工具產研團隊效能平臺工具產研團隊敏捷教練敏捷教練CTOCTO技術團隊技術團隊QA QA 團隊團隊研發效能團隊研發效能團隊橫向支持產品化工作、敏捷方案制定及實施縱向支持各團隊技術負責人遇到的問題、數據分析研發效能提升項目直接負直接負責人、受益方責人、受益方研發效能提升項目整體負整體負責人責人大張旗鼓的官宣啟動營造效能提升氛圍，制造話題。為后續效能提升文化建設預熱。管理政策必須要落地從上至下的管理政策要落地：研發資源分配制度、

5、需求的技術負責人治理等。不在 Z-one 上創建的項目，研發角色不介入不排期只有已完成的需求 PRD 才允許被分發等等研發資源研發資源分配制度分配制度需求分發需求評審技術評審需求排期需求站會可視化管理進度跟進里程碑操作代碼評審參與用例評審整體自測缺陷分析所有項目的排期和狀態的準確性由項目內的技術負責人負責技術負責技術負責人治理人治理精細化運營，提供可用性高的數據塑造效能激勵體系宣傳宣傳、宣傳宣傳研發效能評比、最佳研發效能提升團隊等激勵激勵激勵激勵新員工培訓、研發效能專項講座、對內的全員海報、每周郵件推廣、企業服務號宣傳等平臺能力：一站式效能平臺平臺能力：一站式效能平臺一站式效能平臺建設一站式不

6、是簡單的系統集成，跳轉不同系統不能稱作嚴格的一一站式不是簡單的系統集成，跳轉不同系統不能稱作嚴格的一站式，一站式應該要滿足：標準化、場景化、可視化、可度量站式，一站式應該要滿足：標準化、場景化、可視化、可度量標準化標準化理流程，定標準：支持 4 種工作，適用各種業務開發場景場景化場景化橫向以“需求”為基本數據模型進行項目協助管理?？v向以“應用”維度做研發管理。打通需求與應用可視化可視化可視化價值流動，快速發現問題，加速需求流動可度量可度量讓效能可量化、可分析、可提升，相對客觀的數據分析報告產品架構_實體關系圖實體設定：需求、需求集、任務、應用、人員，以需求為主要實體產品架構_工作流工作流：標準

7、研發工作流、極簡研發工作流，除此之外還提供職能部門工作流、管理工作流等標準研發工作流標準研發工作流極簡研發工作流極簡研發工作流標準：有 QA 參與需要測試的需求（產研類為主），務必選擇標準研發工作流極簡：不需要 QA 測試，產品或研發自測可選擇極簡（技術類為主）產品架構_項目協同項目協同：包含需求、需求集、任務、文檔等需求/項目是交付的核心產物，一些度量以“需求”為始，因此如何快速創建需求，降低需求創建成本尤為重要。我們將需求作為獨立模型，而非嵌套模型，快速創建產品 Demo 工作臺產品 Demo 項目協同-需求產品 Demo 項目協同-任務產品 Demo 研發管理產品 Demo 質量管理收益

8、：研發效能提升帶來的變化收益：研發效能提升帶來的變化關鍵成果規范落地需求、任務的創建規需求、任務的創建規范范技術負責人職能規范技術負責人職能規范需求質量管理規范需求質量管理規范研發提測流程管理規研發提測流程管理規范范吞吐率提升了 5.64 倍交付需求數提升了 6.35 倍交付周期縮短 1.7 倍效能度量體系.產品視角：產品能力怎么做？產品視角：產品能力怎么做？個性化流程太多？業務不用怎么辦？要不要關心用戶增長？怎么衡量產品價值？企業內部協作工具產品的痛點個性化需求太多，怎么處理？個性化需求是 B 端產品通用問題，尤其是隨著研發效能全量推進，用戶的訴求會越來越多，而 90%的需求都是單點需求，其

9、他的團隊并不買單。產品層面易導致系統冗余，學習成本高。如果產品經理直接拒絕需求，最終結果會導致平臺的 NPS 降低。明確 Owner、推廣方案、部門是否通過、技術委員會是否通過發郵件給一級部門、二級部門負責人需求方部門負責人郵件確認產品方案產品使用數據反饋嚴格按照模嚴格按照模板提需求板提需求產品數據反產品數據反饋饋郵件確認產郵件確認產品方案品方案郵件提報需郵件提報需求求需求管理流程業務不用怎么辦？不好用不好用不知道不知道不想用不想用優化需求每雙周的產品發布會+系統內部上線公告+每周的 changeLogKOC 用戶站臺進行產品價值宣傳如何度量工具產品的用戶體驗B 端產品和 C 端產品的用戶形態不一樣。工具產品的用戶體驗度量，主要有：NPS、一致性、性能、易用性、效率等主觀 NPS 評分 組件、框架、樣式一致性首屏渲染時長頁面請求時長API 請求響應時長WAU、PV、會話時長、功能使用率功能使用率、任務完成效率性能性能一致性一致性NPS NPS 效率效率易用性易用性總結：提升研發效能最重要的是什總結：提升研發效能最重要的是什么？么？適宜的技術“土壤”好用的效率工具上下一心，管理和運營動作才更容易貫徹和執行可以沒有一切，但不能沒有工具Q&AThanks感 謝 聆 聽承辦方：主辦方：