业务敏捷助推器之影响地图

长久以来，软件研发部门和它所支持的业务部门都是相互割裂的，少有例外。这样一来，使得技术团队与其他部门形成了天然屏障。业务团队难以理解研发团队的工作，同样研发团队也很难理解业务团队的规划。这种理解上的偏差势必造成沟通上协作上的困难。

一方面导致了业务价值不能很好的传递到研发侧，另一方面，研发侧交付的软件也很难产生预期的价值。这就是典型的业务侧与研发侧存在明显的“竖井”现象。

于此同时，业务目标到产品功能之间关系模糊，缺乏有效的映射，盲目的堆积功能点，不仅对严重的浪费了开发成本，同时也在行动过程中迷失了最终的目标，而滋生出一系列的问题。

在这种情况下，即使技术侧做到了“敏捷交付（比如采用迭代开发）”也收效甚微。所以，仅仅是研发侧敏捷是不够的，更重要的是业务也要具备敏捷性（Business Agility）！

那么如何打通业务侧到研发侧这堵墙，让业务也像研发侧那样敏捷起来呢？此时，你需要借助本期的主角来帮你实现——影响地图（Impact Mapping）。

一、何为影响地图

影响地图是一门战略规划技术。通过清晰地沟通假设，帮助团队根据总体业务目标调整其活动，以及做出更好的里程碑决策，影响地图可以避免组织在构建产品和交付项目的过程中迷失方向。

二、影响地图的结构

影响地图的结构很简单，通过“Why-Who-How-What”这四个简单的层级，可视化了交付计划与周边世界的动态关系，它既反映了交付范围，也反映了重要假设。它在帮助我们高效地调整计划和应对变化的同时，还提供给交付团队一个里程碑计划，并为业务方提供了一个整体视图。

1.WHY

WHY的部分关注：我们为什么做这些？也就是我们试图达成的目标。“要事先知道目标”或许这听上去只是常识，但根据我的经验，忙于交付的人很少知道真正的业务目标是什么。有时它是愿景文档中的草案，更多的时候，它只存在于高级利益相关者的头脑中。即使沟通了，业务目标的定义通常也是模糊不清的。

回答了“为什么（why）”，确保每个人都知道做事的目的。它帮助团队更好地协调行动、识别真实的需求和设计更好的方案。

需要注意的是：目标应该表达要解决的问题，而非解决方案。所以好的目标应该符合SMART原则，即：Specific（明确），Measurable（可度量），Action-oriented（面向行动），Realistic（现实）,Timely（有时限）。

2.WHO

WHO的部分关注：谁能产生需要的效果？谁会阻碍它？谁是我们产品的消费者或用户？谁会被它影响？也就是那些会影响结果的角色。然而大部分需求模型都忽略了这一点——他们把重点放在软件应该做什么，而不是软件交付后谁会受益、谁会受损。

需要注意的是：角色定义应该明确，避免泛化，如“用户”——不同类别的用户或许有不同需求，在一个专门的项目中，并非所有的用户都同样重要。

3.HOW

HOW的部分关注：角色的行为是怎样改变的？他们怎样帮助我们达成目标？他们如何帮助或妨碍我们取得成功？这正是我们试图创造的影响。

Strategyn公司首席执行官Anthony Ulwick写道：“交付成功的关键在于理解客户想要做什么，而不是他们对于产品和服务的想法”。所以我们要把重点放在客户在工作中期望的变化，而非仅仅是客户要完成什么工作。

需要注意的是：只需列出对接近目标有帮助的影响，而不是试图列出所有角色想达成的事。影响不是产品功能，所以要关注业务活动而非关于软件的想法。

4.WHAT

HOW的部分关注：作为一个组织或交付团队，我们可以做什么来支持影响的实现？包含：交付内容、软件功能和组织的活动。

相比交付计划和需求文档，他们通常只包含功能列表，却不包含这些功能为什么重要的背景。如果不能提供从交付到业务目标的清晰映射，以及是如何通过影响实现这一映射的，就难以去讨论和决定某一项功能是否应该做。

需要注意的是：不要想当然地认为所有列出的东西都是要实际交付的，你应该把列出的交付内容当成可选项。同时不要在一开始时就进入所有的细节，将来还会有时间做这些。

三、影响地图的实例

如果上面的文字描述，可能有些枯燥，那么下面，我将引入一个简单实例来说明。

1.目标（WHY）

某音乐APP在一个月增长1万以上的会员数量。

2.会影响结果的角色（WHO）

非会员老用户、会员用户、未注册的新用户。

3.如何产生影响（HOW）

以会员用户为例，第一个影响动作就是邀请，第二个影响动作就是分享；

4.如何做来支持影响的实现（WHAT）

仍以会员用户为例，第一个影响动作就是邀请：可以让他们直接邀请别人，如果被邀请的是非会员老用户，可以获取一个月的会员延期奖励；如果邀请的是未注册的新用户，可以获取现金红包奖励。

这就是一份非常简单的影响地图，当然这是一个例子，其实还可以扩展的更多。

四、影响地图的两个关键假设

1.功能假设：交付会带来角色行为的变化，产生影响。

2.影响假设：一旦影响达成了，相关的角色会对整体目标产生贡献；

五、影响地图的好处

1.专注于业务目标，防止范围蔓延

面向目标的需求实践意图让项目专注于支持有用的目标和行为影响，而不是预先设定的功能或任务。影响地图清晰的展示了交付内容和目标之间的映射关系，当我们通过度量得知当前目标已经实现时，就可以停止这一领域的所有工作，而把重点转到其他目标上，这样可以有效的防止范围蔓延的现象。

2.鼓励多样性，寻找最适合的解决方案

因为影响地图把软件交付内容放在了业务目标的情景之下，这使得检查解决方案、发现问题变得非常容易。在防止过度设计的同时，它还引导我们去思考替代方案，帮助交付团队找到更简单、便宜和快速的替代交付项来实现影响。

3.杜绝“宠物功能（纯个人爱好的功能）”

影响地图让我们可以快速找到那些不贡献任何影响或目标的功能。把它们放在影响地图的任何地方都不合适，这能帮助我们丢弃或延迟这类纯个人喜好的功能。

4.动态跟踪和调整业务假设

如果不能清晰地沟通背后的业务假设，当市场机会改变时，即使有最好的洞察力，我们也无法知道一个方案是否还成立。影响地图清晰地展示了这些假设，以便于我们跟踪和验证它们。

5.更好的优先级决策支撑

影响地图把功能放在了行为影响的情景下，以便利益相关人在功能和收益之间建立更好的关联，从而更好地决定优先级。在更大的组织中，影响地图有助于向众多利益相关人沟通整体图景，协调他们的决策，非常有助于协调所有人的期望，并在不同部门之间做出优先级的权衡。

6.编写更好的用户故事

如果你很了解用户故事，那么你应该很熟悉用户故事的结构：作为WHO，我想要一个WHAT，以便实现WHY的收益。影响地图恰好可以用户故事相结合，在目标WHY的牵引下，编写出更好的故事。

六、最后的强调

1.Deliver business goals, not just ship software！

(交付业务目标，而不仅仅是交付软件!)

2.People don't buy what you do , people buy why you do it ! What you do is just a proof of what you believe !

(人们买的不是你做了什么，而是你为什么做它！你所做的仅是在验证你自己所相信的！)