scrum敏捷影响地图的实践

凤翼天翔这一式的来源是儿时的漫画《圣斗士星矢》中一辉的绝招，那为什么会用这个名字呢？读下去你就知道。

这一式是讲的影响地图的实践，继承于上一式 WHY到怀疑人生，我们已经得到了一个软件项目的价值目标，在这一式中，我们会围绕这个价值目标从WHO, HOW和WHAT的维度展开软件系统的需求结构。

我们知道影响地图实际上是一种思维导图，我个人以前在使用思维导图的工具的时候，最困扰我的地方就是怎么划分维度，如果没有一个很清晰，合理的维度指引，我会发现导到后来会非常混乱，有些节点相互矛盾，有些节点又相互重叠。影响地图的方法帮我们设计好了从价值目标到功能需求的展开维度和方法，这一点是我认为影响地图给我带来的最大的便利。

继续沿用上面的例子，我们现在已经知道了价值目标：2018年实现售后配件3000万增收。那么实际上我们已经识别出影响地图中的WHY：

那么，下一步我们会识别这个地图中的WHO，即哪些用户或者角色会影响我们的目标（WHY）。在我们的例子中，很明显，影响最大的用户当然是我们车主用户，当然除了车主用户之外，经销商，和制造厂商的市场部（这里简称总部）也会影响到我们的目标。

事实上，对于WHO的识别和划分是很有讲究的，就拿这个例子来说，同样是车主用户，可以分成新车主（刚买车2年之内的），中期车主（买车3到5年的）和老车主（买车5年以上的），对于不同类型的车主，他们对售后配件的购买欲望，购买方式都可能会有差异，软件功能的设计根据这些差异也会各有侧重。但是在当前这个时间节点，并不需要急于把用户类型细分，只要区分出大的群体区分就可以。

然后，我们可以开始考虑HOW了，HOW要解决的问题是，WHO怎样才能帮助我们实现WHY？在这一步，业务分析人员很容易会开始罗列这个用户会使用的功能，比如说登录/注册，在线预约，消息推送，等等，这是严重的错误。这个功能清单并不能通过用户和价值目标直接连接起来，用户才不会关心这些七七八八的功能，他们见得多了，不给为用户带来收益的功能，只能是一堆没有价值的代码而已。

在这个环节，我们需要强化的概念是“WHO能得到的好处”。用户得到什么好处他才能正向影响我们的价值目标？其实从这个角度去思考，我们会发现2C软件的HOW都差不多：实惠的价格，透明的信息，方便的预约，体贴的服务，高效的流程...... 这些HOW的答案，关键字都是形容词。所以在回答影响地图中的HOW的时候，我们可以利用这样一个技巧：HOW这一列的答案应该都是以形容词为关键字，如果我们发现某些地方的答案是名词或者动词，我们多半是犯错了。

下一步，我们可以根据HOW列里的内容展开WHAT了，这才是软件需要构建的功能。这一步并不难，思维开拓一点的人，无论是KBU还是IT人员，都可以在这个环节提供大量的输入。我们的例子展开后的WHAT如下图（这又和Design Thinking里的“发散”类似了）：

用户视角的展开

经销商，总部视角的展开

由于绘图空间的原因，这里我不完全展开所有的功能清单，但是我相信大家读到这里可以理解这种思维方式和操作方法。聪明的同学们到这里应该能意识到为什么这一式叫凤翼天翔，完全展开的影响地图，就像一个张开的翅膀。分解WHAT的时候，有几个地方需要注意：

1. 反向细分用户

在分解WHAT的时候，参与这个工作的人会越来越有意识用户还是可以继续细分的，那什么情况下需要把一个类型的用户群体从原有的某个用户群体里分裂出去呢？我自己的设想是，当某些功能是为特定的用户构建，其他用户无法使用这些功能的时候，我们就可以考虑把这个用户群体分裂出来。

拿上面的例子来说，比如说我们对于老车主用户（购车5年以上的），他们很有可能在考虑卖掉车子了，而他们对于零配件的贡献值又特别高。所以我们可能为他们设计专门的功能去引流他们购买正品零配件，比如说和二手车环节打通，鼓励他在车子最后的使用周期内购买正品零配件，以提高二手车的售价。又比如，为他们提供更优惠的新车置换的服务，但前提是他们始终在使用正品配件。

那落到影响地图上，我们应该怎么体现用户的划分呢？参与讨论的同学们自己达成一致就好，不必拘泥于一个用户应该放在哪儿，怎么和WHAT连线这些问题上。

坦率的讲，以上都是我的臆想，因为我并没有在实际的项目中反向细分过用户，但是在实际使用影响地图的过程中，我不止一次的在思考这个问题，什么时候以及怎么样去把用户群体给分的更合理一些？以上只是我脑海里的答案，同学们觉得有道理就去试一下，觉得没道理那就当没看到过这一段好了。

2.识别运营需求

对于一个向最终用户发布，从最终用户那里获取价值的系统来说，运营需求的优先级，应该是远远低于用户可以直接使用的功能需求的，理由很简单，满足功能需求才能直接引流用户。

但是用户提出的很多需求中，往往包括了大量的运营需求，继续引用这个例子来说，用户提了很多关于优惠券管理，折扣算法管理的需求，方便运营人员可以在后台灵活高效的配置各种优惠活动。这些需求功能本身没有问题，但是如果在一开始就花费大量时间精力去实现这类需求的话，一定会严重拖慢这个APP的发布时间。可以想象，在APP刚发布的时候，只会有很少量的优惠活动，我们只要保证在APP发布的时候，已经内置了这些优惠活动的数据就可以了，这个阶段并不需要那么复杂的配置管理功能。所以在这个阶段如果能识别出哪些是运营需求，对后面的功能优先级排列会很有帮助。

3.识别数据需求

数据需求其实和运营需求是相关的，在我们的例子中，零配件的明细数据的导入，就是一个数据需求，但是我们需要在APP发布的时候导入所有的零配件数据么？当然不是的，之前说过，提高高年限车主的忠诚度是收益最高的方向，所以一开始我们只要把那些行车5,6年会需要换的零配件数据导入到系统里就可以了，让APP可以先为那个群体的车主提供服务。然后在后面的产品迭代中逐步的把其他的零配件数据导入进系统就可以。

综上，大家可以看到，一个影响地图里，所有的功能需求，都会和价值目标产生关联，也就说所有的功能需求，都在直接或间接的为价值目标服务。如果将来想到了新的功能需求，我们需要把这个需求放进影响地图，然后回答这样一个问题，这个功能（WHAT），会给谁（WHO）怎样（HOW）的影响，最终为价值目标（WHY）服务？如果能回答出这个问题，那在地图上一定能在价值目标和这个功能需求之间建立连接，否则，就找不到要去做这个功能的理由了。

到了这里，第二式 凤翼天翔也基本上讲完了，影响地图的使用和实践，我们参照了GOJKO ADZIC的著作，由何勉和李忠利翻译的《影响地图》一书。只是我们在实践过程中做了些调整，把HOW这一列聚焦在“WHO得到的好处"上。具体使用什么样的策略，我相信并没有什么统一的做法，大家根据自己的实际情况灵活调整就好。最后总结一下我们使用影响地图的心得：

• 始终围绕WHY展开

• 合理的划分WHO（初始划分与反向细分）

• HOW以形容词为关键字

• 识别运营需求和数据需求

• 不用探讨WHAT的细节

• 不必追求一次成型，在项目过程中持续演进

本文由@合气大蒜 原创发布于管理圈，未经许可禁止转载。