建议阅读时长10mins随着科技的快速发展和新兴产业的兴起，各行业对研发的需求越来越大，要求也越来越高。研发效率的提升已经成为每个团队必不可少的一环，而敏捷需求是提升效率不可或缺的模块之一。CloudWisdom的敏捷教练-徐虹近日在公司分享了主题为“敏捷需求挖掘与组织方法交付具有更高商业价值的产品”。Iris在团队敏捷转型实施方面有着丰富的经验，完成了企业多个团队从传统模式到敏捷转型的落地实施，积累了大量经验。本次分享主要包括以下两部分：第一部分是用户影响图，第二部分是Eventdrivenbusinessanalysis（以下简称EDBA）用户影响图，是一种从业务目标到产品需求的映射方法挖掘和组织。软件开发过程中可能会遇到一些问题，比如使用不同的业务语言和技术语言，这可能会造成角色之间的沟通障碍，也可能会导致一些问题，比如需求的误解，错误的传递要求等；这会直接导致产品的功能需求和要实现的业务目标之间没有映射关系。但是在交付期，研发人员必须交付这些需求，却不知道这些功能需求的原因，解决客户的哪些痛点。研发人员往往只是拿到了解决方案，需要去实施，却没有和业务方一起思考这个方案是否正确，是否真的能帮助客户解决问题。用户影响图通常是连接业务目标和产品功能的一种方式。我们在每次迭代中添加的假设是功能需求。先先实现，然后逐步验证我们的每一个小目标是否实现了，再看下一个目标是什么。影响图就是帮助我们在这个过程中不断梳理目标和功能之间的关系。我们在软件开发中可能遇到的一些问题针对这些问题，我们应该如何避免呢？先简单介绍一下做敏捷转型的总体思路：先做团队级的敏捷，先把产品、开发、测试，还有一些后端人员，比如交互式运维同学，组成一个专门的团队培训团队进行交付。该团队应包括交付过程中涉及的所有角色。那么业务敏捷性就需要打通整个业务环节，在研发端做一个交付。在上图中，我们可以看到敏捷中的需求是分层管理的。第一层是业务需求。在此级别，用户目标和业务目标被用作规划的输入，并且需要考虑客户需求。通过获取到的业务需求，业务人员与团队一起进一步分解为产品需求。所以业务需求其实就是我们实际发布运行的单元，可以独立发布到我们的生产环境中。我们的产品需求其实就是产品的具体功能。它是我们集成和测试的对象，是我们最终部署到系统中的一个基本单元。当产品需求来到我们的开发团队，映射到迭代计划会议的时候需要分解成相应的技术任务，包括我们平时说的比如一些前端开发，后端开发，测试都是所有相应的技术任务。因此，业务敏捷性的目标是持续、顺畅、高质量地交付业务价值。将这些点串在一起形成一个金字塔结构。在顶层，我们会把商业目标放在整个金字塔的顶端。该业务目标是通过用户目标和北极星指标建立的。确定业务目标后，梳理出相应的业务流程，最后进行生产。此外，产品要求包括操作流程和业务规则，以及对交货时间、工程时间和我们的一些质量标准的要求。说到用户影响力图谱，其实在敏捷江湖上还有一个传说。对于敏捷的需求，大家有句话叫“任督二脉”。用户影响图其实是人脉，黑客马拉松用的用户故事图其实叫度脉。所以用户影响图是在用户故事图之前帮助我们理清我们要做的事情。在我们真正确定了我们要实现的业务活动之后，用户故事地图梳理了我们整个业务工作流程，以及每个工作流程节点下要包含的具体功能和用户故事。因此，用户影响图需要解决的问题包括：第一，范围扩散。我们需要在整个地图上有一个功能和对应的业务目标之间的映射。这样就避免了在一些我们有很多stakeholder参与的会议上，比如大家的想法和立场不一样，会提出很多的要求（正确的和错误的要求）。这个时候我们就根据目标来看这些要求是否真的会影响到我们的目标。这里说的错误需求，比如利益相关者提出的，客户认为产品应该有什么，产品经理需要分析师认为可以有什么……但是这些功能在用户影响中无法匹配相应的功能地图目标，需要降低优先级或丢弃。另外，通常我们在制定解决方案的时候，会考虑更完善的实现方式，从而得到包含很多功能的解决方案。这个时候关键目标就很重要了，会帮助我们梳理和优先排序。看一下用户对地图概览的影响，分为三层结构：第一层为什么，你的业务目标中哪个最重要，为什么？涉及哪些角色？第二层如何，如何产生影响？什么样的行为会影响用户角色？（没必要把所有的影响都列出来，根据业务目标）第三层什么的，最重要的是你在梳理需求的时候不需要一下子考虑所有的细节，这往往是在团队中遇到。到问题。让我们用这个例子来看一下客户服务中心的影响图。业务目标是在3个月内在不增加客服人员数量的情况下，支持1.5倍的用户数量。这个业务目标设定很符合smart原则，specific很具体，miserable很可衡量，actionreoriented就是activity-oriented，reallist也很实用。量化的目标会指导我们接下来的行动，梳理出一个业务目标，并尝试将其量化，例如：我们可以构建什么样的管道来提高整个部署的效率，时间是原来的1/2。这是一个可量化且有意义的目标。回到这张图，在how层面标识的内容，客服的作用：你想对它施加的影响，引导客户到论坛，帮助客户更容易的跟踪问题，更快速的定位问题。初学者：在论坛上找到问题。高级用户：在论坛上回答问题。通过这些用户角色，我们在不增加客服人员数量的情况下开展支持更多用户的活动。最后一层是我们日常接触比较多的真实功能的特点和需求，比如引导客户上论坛。事实上，该产品需要一个指向常见问题论坛的链接。这个层次需要我们的团队进一步交付，在每次迭代前做进一步的梳理，提炼成相应的用户故事。这是云智团队制作的影响图示例。您可以看到整个层次结构。序号表示优先级。那么我们的用户影响图可以总结为：在分析目标时，我们应该更多地关注目的而不是构建产品。在分析角色的时候，一定要着眼于业务活动，不仅要考虑产品应该具备什么功能，还要分析哪些角色会影响我们，帮助我们实现目标。同时，我们必须确定这个用户角色的优先级。在what环节，需要反复强调，而不是一次性细化。一个非常大的路线图，如果团队的资源很难在短时间内落地，路线图中的所有功能往往就像是给我们画了一个大饼。用户影响图中需要高度重视的一个思路——从发散到收敛。一开始是发散的，以至于用户印象图包含的内容很多，选项也很多。达到一定程度之后，我们要做衔接。我们想优先考虑地图上的目标。好了，以上就是用户影响图的应用规则和一些方法论。接下来，我们就来看看这个事件驱动的业务分析（EDBA），这个方法是如何应用的。先介绍一个概念。GIGO：Garbagein和garbageout，如果我们的输入是垃圾，那么我们的输出也是垃圾，充分说明了需求分析的重要性。为了解决这个困境，我们首先需要转变思路，以终为始。现在很多领域都提出了这个概念，包括一本非常畅销的DevOps书《高效能人士的7个习惯》，里面也提到startingwiththeendinmind。作者写道：__如果有一天在我的葬礼上，我希望牧师会读出什么样的悼词来总结我的人生，在明确了这个目标之后，我会反省我们的人生。__然后我们活着的时候，我应该做什么事情，让人们对我有一个最后的总结。在软件开发中，我们首先要弄清楚我们的最终目标是什么，并以此为出发点来做一个我们整个软件的交付过程。首先做业务分析，明确业务目标和流程，然后做产品设计，明确我们产品的功能和验收标准。如果映射到需求结构上，首先要明确业务需求，然后再分解产品的需求。整个过程也分为四个步骤，如上图所示，下面通过一个例子来看看这几个步骤是如何实现的。这是一种向卡车司机出售信用卡的商业产品。目标是让开卡流程更加顺畅，提高下个月的开卡成功率。最终目的是实现开户。如果我们要达到50%的开卡率。确认了这一点之后，就可以进行下一步的梳理——构建一个完整的时间流。在每个环节建立一个成功的过程。它有一个时间轴，从左到右。如果任何一个环节出现故障，流程就会中断，无法继续进行。那么第三个环节就是挑战和调整事件流程，补充分支流程。在某些环节，可能会出现这种故障。例如，当申请没有通过时，客户需要做进一步的更新/处理，然后再回到这个审核流程的一部分。在明确了完整的事件流程以及分支和异常的流程之后，还需要在各个节点上进行actor和操作。举个例子：我们可以看到审计通过后需要进行运营审计，而审计actor是一个运营角色，所以需要在流程图上标注哪些角色支持哪些业务活动。把所有的工作流程梳理完之后，就会有一个MVP版本的概念，跟用户故事图中的一样，叫做最小可行产品。对假设进行最小发布，以验证我们当前的假设是否可行。如果可行，计划下一步；不可行的，及时调整发布内容。根据刚才的需求分析结构，我们可以看到这张图中有一些业务需求映射到产品需求。现在假设一个场景，这个产品已经上线了，希望激活率最终能达到50%。我们实际验证一下，激活率其实只有35%。这个时候我们其实就需要思考如何优化我们整个流程？整个活动的最终目的就是希望司机拿到卡并充值。所以我们调整了整个事件流程，把一些物理卡的工作逻辑节点放在后面。Reach-entry-recharge其实已经达到了我们的最终目的。实体卡的寄送、签收、发放等过程需要较长时间。调整了这个工作流程之后，整个流程的实现时间会变得很短，用户会比较快的到达我们的finalstate事件，后续的一些环节会在后面实现。所以有一个很重要的概念。我们在规划整个需求的时候，一定要考虑优化局部流程，重构流程。局部优化可能只是较小区域的一些改进。如果我们考虑全局优化，我们需要在更多的地方谈深度优化，进一步提高我们整个商业价值的实现。相关阅读：https://segmentfault.com/a/1190000040860911后续会在AIOps社区持续提供和分享更多干货知识，关注我们不要迷路！AIOps社区：https://www.cloudwise.ai/#/datalaker/dashboard项目Github：https://github.com/CloudWise-OpenSource
