纯干货分享 | 研发效能提升——敏捷需求篇-而敏捷需求是提升效能的方式中不可或缺的模块之一。 云智慧的敏捷教练——Iris Xu近期在公司做了一场分享，主题为「敏捷需求挖掘和组织方法，交付更高业务价值的产品」。Iris具有丰富的团队敏捷转型实施经验，完成了企业多个团队从传统模式到敏捷转型的落地和实施，积淀了很多的经验。 这次分享主要包含以下2个部分： 第一部分是用户影响地图 第二部分是事件驱动的业务分析Event driven business analysis（以下简称EDBA） 用户影响地图，是一种从业务目标到产品需求映射的需求挖掘和组织的方法。 在软件开发过程中可能会遇到一些问题，比如大家使用不同的业务语言、技术语言，造成角色间的沟通阻碍，还会导致一些问题，比如需求误解、需求传递错误等；这会直接导致产品的功能需求和要实现的业务目标不是映射关系。 但在交付期间，研发人员必须要将这些需求实现交付，他们实则并不清楚这些功能需求产生的原因是什么、要解决客户的哪些痛

在分析目标的时候，要更关注于目的，而不是要构建一个产品。

在分析角色的时候，要着重去考虑业务活动，不仅考虑产品要有哪些功能，要分析哪些角色会给我们带来影响，能帮助我们去实现目标，同时要划定这个用户角色的优先级。

在what 环节，需要强调迭代着去做，而不是一次性细化。一个非常大的 roadmap，如果团队的资源很难短周期内实现， roadmap 里所有的功能，往往像给我们画了一个大饼。

在用户影响地图还要非常注意的一个思维——从发散到收敛。开始是发散的，让用户印象地图包含很多的内容、很多选项，到达一定程度之后，我们要去做收敛。我们要在地图上划定目标的优先级。

好，以上就是用户影响地图的应用法则以及一些方法论。接着，我们来看一下这个事件驱动的业务分析（EDBA)，这种方法是如何应用的。 

先介绍一个理念。GIGO： garbag in and garbage out ，如果我们的输入是垃圾话，那我们的产出也是垃圾，非常充分的说明需求分析的重要性。为了解决这种困局，我们的思维首先要做一个转换，转换到以终为始。

现在在很多领域都有这种理念思想的提出，包括 DevOps 里一本非常畅销的书《高效能人士的7个习惯》也提到了以终为始。作者写道：如果有一天在我的葬礼上，我希望说这个牧师要念怎样的悼词总结我这个人的一生，明确了这个目标之后我反观我们的人生。那在我们活着的时候，我应该去做哪些事情，让人们对我有一个最终的这样的总结。那在软件开发中，我们也是首先要找到我们最终的目标是什么，以这个作为起点去做我们的整个软件的一个交付过程。

首先要做业务分析，明确业务目标和流程，再做产品的设计，去明确我们产品的功能和验收标准。映射到需求结构上话，首先要明确业务需求，然后再去分解到产品的需求。

那这个整个的一个流程也是总共分为四步，如上图所示，我们以一个例子去看一下如何去实施这几个步骤。

这是一个给卡车司机推销信用卡的业务产品。目标是希望开卡的流程更加顺畅，提高次月开卡的成功率。最终指标是实现账户开通，如果说我们的开卡率想达到50%。确定了这个之后，可以做下一步的梳理——构建完整的时间流。

构建每一个环节一个成功的流程。它是有一个时间线的，从左到右。如果有任何一个环节没有成功，这个流程就会被打断，无法进行下去。

那么第三个环节，挑战和调整事件流并补充分支流程，有一些环节可能会出现这个不成功的情况，比如申请没有通过的时候，那需要客户做进一步的更新/处理，然后才能走回到这个审核通过的一个环节。

明确了完整的事件流以及分支和异常的流程之后，需要在每一个节点上 actor 和操作。举个例子：我们可以看到在审核已通过这个环节要做操作式审核，那审核 actor 是运营角色，那就需要在流程图上标记哪些角色在支持的什么业务活动。

梳理完整个所有的工作流之后，会有一个 MVP 版本的概念，这个和用户故事地图里也是一样的，称之为最小可行性产品。对假设做一个最小的发布，验证一下我们现在的假设是否可行。如果可行的话，再去规划下一步；如果不可行，及时调整发布的内容。

根据刚才讲的需求分析结构，可以看到在这个图里有一些是业务的需求是映射到产品需求的。那现在假设一种场景，这个产品已经上线了，最终希望开卡率需希望是达到50%。

实际验证一下，开卡率其实只有35%，这个时候其实是我们要再去思考一下我们的整个流程应该怎么去优化？

整个的事件最终目标是希望司机拿到这个卡并且进行充值。所以我们对整个的事件流进行了调整，把一些实体卡片的工作逻辑节点放到后面。

触达-录入-充值其实已经达到了我们最终目标。那实体卡片的寄出，签收、开卡都会是一个比较长时间的流程。对这个工作流进行调整之后，整个流程时间的实现是会变得非常短的，用户会比较快的到达我们这个终态事件，把一些后续的环节放在之后去实现。

  

所以就有一个非常重要的概念，我们在整个需求规划的时候，要考虑优化局部的流程，也要考虑去重构流程。局部优化可能只是较小范围内有一些提升。如果考虑全局优化话，需要在更多地方说深入的思考优化，进一步提高我们的整个业务价值的实现。

相关阅读：https://my.oschina.net/u/5459109/blog/5286932