敏捷产品需求管理实战篇

需求牵一发而动全身，在敏捷开发过程中，如何帮助团队梳理、规划、澄清、管理和拆分需求呢，我们是这么玩滴~

大声说出一个需求的who、what、why ，这就是用户故事，也是需求的基本单元。

整个迭代过程中，产品经理和SM牵头发起需求梳理活动

其目的是提早暴露下个迭代需求的问题。也即不希望带着问题进入下个迭代计划会，造成计划会效率低下甚至计划会失败。

在此，我们会使用DoR来梳理把控进入计划会的需求质量。

下图是一个团队的DoR示例

用户故事地图是组织和规划产品需求的神器。通过地图，可以帮助我们看到需求的整体和关联及时暴露产品设计过程中的问题。

用户故事地图保证了用户体验的完整性，呈现了用户使用我们产品方案的端到端的场景路径，打通了产品设计和开发计划。

沟通漏斗和知识诅咒会造成人们沟通的困难。

在产品开发过程中，我们要做到以终为始的沟通。开始开发前，充分澄清需求，明确其验收标准，并保证相关人员对需求的一致理解。

实例化需求方法从场景出发，以用户的操作实例来澄清需求，相比一般的规格说明，实例更加场景化。能够激发参与和深度讨论。

基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。

实例化需求的用例，可以用来分析和澄清需求，这些例子随后会转化为测试用例，最后再通过测试验证需求

敏捷开发计划扑克实践，最大的价值不是估算，而是可以帮助团队对需求的理解达成共识，是一种共识的可视化。

在整个迭代过程中，通过Scrum五会来梳理、跟踪、演示和回顾需求的相关问题。

通过Kanban方法来透明迭代需求的进展、问题和风险，以此来帮助团队更加顺畅地交付产品上线。

在管理迭代需求的过程中，团队需要重点关注一个需求满足了什么样的条件才能交付上线（DoD）这关系到需求交付的质量。

下图是一个团队的DoD示例

在很多关键产品交付过程中，我们的时间往往被承诺，人力成本是固定的，质量是底线，特性列表往往也不能协商。

所以，我们只能从细节入手，将可变性引向低成本方向，也就是去调整需求的细节。

需求拆分可以有效地帮助团队去思考需求的复杂度，找出MVS（最小可行方案）

需求拆分，我们可以从以下维度来思考：

按工作流步骤切分

按不同业务规则切分

按主要工作切分

按简答/复杂切分

按不同类型的数据切分

按不同界面切分

延迟性能优化

按操作切分

拆分出一个探针（预研）

根据随机自相似性，在任何组织，任何团队都会遇到需求不知该如何规划、梳理、澄清、管理的问题。

这里提供一套解决方法以缓解产品开发团队需求之痛。不这么玩的请开始你们的摩擦~

-----

曝个帅照：）