作者简介：张迎辉(问菊)，阿里敏捷教练，先后支持淘宝直播、优酷、智能营销平台等团队的，辅导敏捷理论在阿里巴巴各个部门及RDC研发协同平台的实践落地。

---

背景和目标

2016年12月，我和手机淘宝PMO一起投入到风林火山项目中，帮助优酷迅速融合到阿里研发体系，我主要负责需求分析流程的优化。本文简述在此过程中，如何通过调研分析、设计方案、落地实施、评估效果和持续优化的闭环帮助优酷同学解决问题。

为熟悉优酷情况，我和PMO同学访谈了优酷主客团队的产品、设计、开发、测试、项目经理等角色，大家反馈需求分析阶段的主要痛点有：

针对这些痛点，需求分析流程优化的目标设定为：

提供一套轻流程、重标准、数据驱动的需求管理方案，以数据化方式驱动团队改进，提供需求从创建到发布的全流程透明化管理。

设计方案和落地实施

优酷主客团队此前已有一套需求分析流程，建立了需求优先级PK和需求评审等机制。针对大家反馈的问题和优酷移动App的特点，并借鉴手淘的经验，我设计了一套改进的需求管理方案

《双周迭代的时序图》
（注：本图仅适用常规迭代，特殊项目不在此列）

与已有方案相比的几个不同点

• 增加了产品规划环节

每季度开产品规划会，业务负责人参加。主要议程包括：回顾上季度业务数据及业务目标达成情况；规划下季度业务目标和业务打法。接下来三个月的核心需求要围绕业务目标和业务打法来规划和设计。

主要目的是解决“规划不清晰”的痛点，自上而下形成合力，聚焦业务目标。

在需求梳理环节要提供有交互草图的需求概要。各角色TL和重要干系人参加需求梳理会。会前，产品同学把需求录入阿里云RDC并提供需求概要设计，产品团队内部对需求优先级达成一致。会上，产品同学按优先级顺序串讲需求，听众提问澄清需求。需求概要至少要明确需求价值，技术上可行，主流程交互清晰。

主要目的是希望产品同学往前走，早投入早沟通早设计，避免一句话需求或口头需求占位。

• 从只有TL参加的集中式需求评审变为一线同学参加的分散式需求评审
  需求梳理会后，TL们商定交付范围并为范围内的需求分配人手，分工信息更新到阿里云RDC中。产品同学拉上相关的一线同学和重要干系人自行组织需求评审。TL参加重点需求评审，一线同学参加与自己相关的需求评审。

优酷主客按职能组织团队，产品、设计、开发、测试合计102人。以前一线同学不参与需求评审，由TL代为传递需求。从开大会到拉小会，让一线同学参与需求设计和讨论，更了解需求，有问题和风险及时提出解决。同时也可以解放TL，不需要关心每个需求，只需关注重点需求。

• 需求符合开工标准才能进入开发环节

开工标准由优酷主客产品团队同学起草，TL评审通过。开工标准已配置到阿里云RDC需求模板中，新创建的需求只需按模板填空即可。

• 需求统一进阿里云RDC

需求从创建到发布的全部环节都在阿里云RDC上跟踪，是数据化管理的前提。统一工具，也可以加强协作，降低沟通成本。

效果评估

2017年1月方案落地实施后，我访谈了优酷主客团队的2名产品同学、1名设计同学和1名开发同学。并于2017年1月20日组织了版本总结会，主客团队TL和一线同学代表参加。

综合访谈和总结会的反馈，总结要点如下：

• 节奏感提升

时间点清晰，每个阶段的产出物也很明确。

• 流程简单清晰，避开了冗余低效的环节

一线人员更了解需求，及时发现问题；

需求分开评审效率明显提升，不会大面积占用其他同学的时间；

产品往前走了，也带动其他同学早启动了，需求积压的情况有所改善。

• 工具引入提升了效率

RDC方便，信息同步更好了；

需求管理工具统一，提升了效率；

需求与bug关联，便于定位问题。

持续优化

需求流程优化方案在优酷主客团队落地后，其它团队和部门也纷纷希望帮忙优化需求流程。2017年2月至3月，通过与业务接口人合作，我帮助优酷产品技术部其他团队和优酷广告落地了新的需求分析流程：需求统一进阿里云RDC，实现了需求从创建到发布的全流程透明化管理。

以优酷产品技术平台主要业务线为例，研发过程全流程的核心指标报表如下：

（注：为保护优酷数据安全，此处未提供清晰版本）

以上是按照业务线（项目）维度生成的4张报表，分别对应3月1日到3月31日期间各业务线完成的需求数量、需求从创建到发布的总时长及分阶段时长、新创建的缺陷数量、已关闭缺陷的平均关闭时长。这4个核心指标反映了业务线的质量、效率和响应力。报表产出后，业务团队分析报表找问题，并采取了改进行动。

此处举两例：

• 案例一

某团队发现需求分析阶段特别长

调研发现有些需求准备好了，但是开发团队容量满了；

需求要等待排期，而排期时长都记入分析时长了；

团队决定改造工作流，在需求分析后增加了排期状态；

工作流改造后更能反映团队的实际工作情况，有助于发现瓶颈。

• 案例二

某业务线2017年3月交付了16个需求，新增了1030个缺陷，缺陷需求比较高。

团队总结反思后发现主要有两方面原因：

一是需求的粒度比较大；二是测试和产品、开发同学对需求的理解不一致；

改进行动包括需求拆分为合适的粒度，测试同学参加需求评审，保证大家对需求的理解是一致的。

总结

作为敏捷教练团队的一员，我尝试把团队的使命落地到行动中：“引入业界的优秀实践，探索适合阿里巴巴的研发模式，在研发团队落地，帮助团队提升质量效率，沉淀成功案例并落实到工具平台中”。

在敏捷理念的指引下，帮助团队建立稳定的迭代节奏，再通过直观透明的研发过程数据引导团队持续改进。在优酷主客按职能组织团队的情况下，不拘泥于条条框框，因地制宜优先实现了拆产品和拆时间。在双周迭代稳定运转3个月后，优酷主客团队涌现出了比较稳定的产品、设计、开发、测试组合。可以说是出现了跨职能特性团队的雏形，为向特性团队转型奠定了良好的基础。

此外，我与RDC产品团队密切协作，持续优化和完善RDC的报表功能。这些通用功能也为其他团队的持续改进提供了便利。