阿里敏捷教練如何優化優酷需求分析流程？

摘要： 如何幫助優酷迅速融合到阿里研發體系？如何優化優酷的需求分析流程？針對需求信息不明確，開發出來的功能不是產品想要的痛點如何解決？

點此查看原文：http://click.aliyun.com/m/41381/

導讀：如何幫助優酷迅速融合到阿里研發體系？如何優化優酷的需求分析流程？針對需求信息不明確，開發出來的功能不是產品想要的痛點如何解決？本文由阿里巴巴敏捷教練張迎輝（花名問菊），詳述如何經過調研分析、設計方案、落地實施、評估效果和持續優化的閉環幫助優酷同窗解決問題。

1、背景和目標

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

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

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

2、設計方案和落地實施

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

雙週迭代的時序圖：

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

與已有方案相比：

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

主要目的是解決「規劃不清晰」的痛點，自上而下造成協力，聚焦業務目標。

2.在需求梳理環節要提供有交互草圖的需求概要。各角色TL和重要干係人蔘加需求梳理會。會前，產品同窗把需求錄入阿里云云效並提供需求概要設計，產品團隊內部對需求優先級達成一致。會上，產品同窗按優先級順序串講需求，聽衆提問澄清需求。需求概要至少要明確需求價值，技術上可行，主流程交互清晰。

主要目的是但願產品同窗往前走，早投入早溝通早設計，避免一句話需求或口頭需求佔位。

1. 從只有TL參加的集中式需求評審變爲一線同窗參加的分散式需求評審。需求梳理會後，TL們商定交付範圍併爲範圍內的需求分配人手，分工信息更新到阿里云云效中。產品同窗拉上相關的一線同窗和重要干係人自行組織需求評審。TL參加劇點需求評審，一線同窗參加與本身相關的需求評審。

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

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

5.需求統一進阿里云云效。需求從建立到發佈的所有環節都在阿里云云效上跟蹤，是數據化管理的前提。統一工具，也能夠增強協做，下降溝通成本。

3、效果評估

2017年1月方案落地實施後，我訪談了優酷主客團隊的2名產品同窗、1名設計同窗和1名開發同窗。並於2017年1月20日組織了版本總結會，主客團隊TL和一線同窗表明參加。
綜合訪談和總結會的反饋，總結要點以下：

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

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

3.工具引入提高了效率：雲效操做方便，信息同步更好了；需求管理工具統一，提高了效率；需求與bug關聯，便於定位問題。

4、持續優化

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

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

（注：爲保護優酷數據安全，此處未提供清晰版本）

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

此處舉兩例：

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

調研發現有些需求準備好了，可是開發團隊容量滿了；

需求要等待排期，而排期時長都記入分析時長了；

團隊決定改造工做流，在需求分析後增長了排期狀態；

工做流改造後更能反映團隊的實際工做狀況，有助於發現瓶頸。

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

團隊總結反思後發現主要有兩方面緣由：

一是需求的粒度比較大；二是測試和產品、開發同窗對需求的理解不一致；

改進行動包括需求拆分爲合適的粒度，測試同窗參加需求評審，保證你們對需求的理解是一致的。

5、總結

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

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

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

做者介紹：張迎輝（花名問菊），阿里巴巴敏捷教練，羅漢堂講師，開發和講授多門敏捷課程，前後支持手機淘寶、優酷、移動事業羣等多個部門的團隊敏捷轉型。2011年開始接觸敏捷開發，是認證的CSM、CSD、CSPO。親身感覺到敏捷給團隊帶來的改變，立志成爲敏捷踐行者。PS：關注雲效（ali_yunxiao）微信號，對話框回覆研發效能，下載企業效能升級合集材料。