優酷的敏捷實踐：如何做需求分析

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

一、背景和目標 

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/23158/