作者簡介：張迎輝(問菊)，阿里敏捷教練，先后支持淘寶直播、優酷、智能營銷平臺等團隊的，輔導敏捷理論在阿里巴巴各個部門及RDC研發協同平臺的實踐落地。

[[194180]] 

一、 背景和目標

2016年12月，我和手機淘寶PMO一起投入到風林火山項目中，幫助優酷迅速融合到阿里研發體系。我主要負責需求分析流程的優化。本文簡述在此過程中，如何通過調研分析、設計方案、落地實施、評估效果和持續優化的閉環幫助優酷同學解決問題。

為熟悉優酷情況，我和PMO同學訪談了優酷主客團隊的產品、設計、開發、測試、項目經理等角色，大家反饋需求分析階段的主要痛點有：

針對這些痛點，需求分析流程優化的目標設定為：

提供一套輕流程、重標準、數據驅動的需求管理方案，以數據化方式驅動團隊改進，提供需求從創建到發布的全流程透明化管理。

二、設計方案和落地實施

優酷主客團隊此前已有一套需求分析流程，建立了需求優先級PK和需求評審等機制。針對大家反饋的問題和優酷移動App的特點，并借鑒手淘的經驗，我設計了一套改進的需求管理方案：

雙周迭代的時序圖：

(注：本圖僅適用常規迭代，特殊項目不在此列)

與已有方案相比：

1. 增加了產品規劃環節：每季度開產品規劃會，業務負責人參加。主要議程包括：回顧上季度業務數據及業務目標達成情況;規劃下季度業務目標和業務打法。接下來三個月的核心需求要圍繞業務目標和業務打法來規劃和設計。

主要目的是解決“規劃不清晰”的痛點，自上而下形成合力，聚焦業務目標。

2. 在需求梳理環節要提供有交互草圖的需求概要。各角色TL和重要干系人參加需求梳理會。會前，產品同學把需求錄入阿里云RDC并提供需求概要設計，產品團隊內部對需求優先級達成一致。會上，產品同學按優先級順序串講需求，聽眾提問澄清需求。需求概要至少要明確需求價值，技術上可行，主流程交互清晰。主要目的是希望產品同學往前走，早投入早溝通早設計，避免一句話需求或口頭需求占位。

3. 從只有TL參加的集中式需求評審變為一線同學參加的分散式需求評審。需求梳理會后，TL們商定交付范圍并為范圍內的需求分配人手，分工信息更新到阿里云RDC中。產品同學拉上相關的一線同學和重要干系人自行組織需求評審。TL參加重點需求評審，一線同學參加與自己相關的需求評審。

優酷主客按職能組織團隊，產品、設計、開發、測試合計102人。以前一線同學不參與需求評審，由TL代為傳遞需求。從開大會到拉小會，讓一線同學參與需求設計和討論，更了解需求，有問題和風險及時提出解決。同時也可以解放TL，不需要關心每個需求，只需關注重點需求。

4. 需求符合開工標準才能進入開發環節。開工標準由優酷主客產品團隊同學起草，TL評審通過。開工標準已配置到阿里云RDC需求模板中，新創建的需求只需按模板填空即可。

5. 需求統一進阿里云RDC。需求從創建到發布的全部環節都在阿里云RDC上跟蹤，是數據化管理的前提。統一工具，也可以加強協作，降低溝通成本。

三、效果評估

2017年1月方案落地實施后，我訪談了優酷主客團隊的2名產品同學、1名設計同學和1名開發同學。并于2017年1月20日組織了版本總結會，主客團隊TL和一線同學代表參加。

綜合訪談和總結會的反饋，總結要點如下：

1. 節奏感提升：時間點清晰，每個階段的產出物也很明確。

2. 流程簡單清晰，避開了冗余低效的環節：一線人員更了解需求，及時發現問題;需求分開評審效率明顯提升，不會大面積占用其他同學的時間;產品往前走了，也帶動其他同學早啟動了，需求積壓的情況有所改善。

3. 工具引入提升了效率：RDC方便，信息同步更好了;需求管理工具統一，提升了效率;需求與bug關聯，便于定位問題。

四、持續優化

需求流程優化方案在優酷主客團隊落地后，其它團隊和部門也紛紛希望幫忙優化需求流程。2017年2月至3月，通過與業務接口人合作，我幫助優酷產品技術部其他團隊和優酷廣告落地了新的需求分析流程：需求統一進阿里云RDC，實現了需求從創建到發布的全流程透明化管理。

以優酷產品技術平臺主要業務線為例，研發過程全流程的核心指標報表如下：

(注：為保護優酷數據安全，此處未提供清晰版本)

以上是按照業務線(項目)維度生成的4張報表，分別對應3月1日到3月31日期間各業務線完成的需求數量、需求從創建到發布的總時長及分階段時長、新創建的缺陷數量、已關閉缺陷的平均關閉時長。這4個核心指標反映了業務線的質量、效率和響應力。報表產出后，業務團隊分析報表找問題，并采取了改進行動。

此處舉兩例：

1. 某團隊發現需求分析階段特別長

• 調研發現有些需求準備好了，但是開發團隊容量滿了;
•  需求要等待排期，而排期時長都記入分析時長了;
• 團隊決定改造工作流，在需求分析后增加了排期狀態;
• 工作流改造后更能反映團隊的實際工作情況，有助于發現瓶頸。

2. 某業務線2017年3月交付了16個需求，新增了1030個缺陷，缺陷需求比較高。

團隊總結反思后發現主要有兩方面原因：一是需求的粒度比較大;二是測試和產品、開發同學對需求的理解不一致。改進行動包括需求拆分為合適的粒度，測試同學參加需求評審，保證大家對需求的理解是一致的。

五、總結

作為敏捷教練團隊的一員，我嘗試把團隊的使命落地到行動中：“引入業界的優秀實踐，探索適合阿里巴巴的研發模式，在研發團隊落地，幫助團隊提升質量效率，沉淀成功案例并落實到工具平臺中”。

在敏捷理念的指引下，幫助團隊建立穩定的迭代節奏，再通過直觀透明的研發過程數據引導團隊持續改進。在優酷主客按職能組織團隊的情況下，不拘泥于條條框框，因地制宜優先實現了拆產品和拆時間。在雙周迭代穩定運轉3個月后，優酷主客團隊涌現出了比較穩定的產品、設計、開發、測試組合。可以說是出現了跨職能特性團隊的雛形，為向特性團隊轉型奠定了良好的基礎。

此外，我與RDC產品團隊密切協作，持續優化和完善RDC的報表功能。這些通用功能也為其他團隊的持續改進提供了便利。

由阿里云研發協同RDC、阿里云云效、阿里云云棲社區共同發起的“首屆阿里巴巴研發效能嘉年華”技術峰會將于6月29日在線直播，如有興趣，歡迎報名：

http://click.aliyun.com/m/23155/