影响地图的结构

简单的讲，影响地图是这样的一个思维逻辑和组织结构：为什么（Why）>谁（Who）>怎样（How）>什么（What）

也就是：我们的目标是什么（Why），为了达成目标需要哪些人（Who）去怎样（How）影响，为此我们需要做什么（What）。

影响地图通过构建产品和交付项目来产生实质影响，从而达到业务目标。

• 为什么（Why）？

  “我们为什么做这些？”也就是我们要试图达成的目标。

  找到正确的问题，要比找到好的回答困难得多。把原本描写在文档中，更多的是隐藏在高层利益干系人头脑中的业务目标，定性定量的引导出来。

  目标描述要遵循SMART原则，确保每个人知道做事的目的是什么，帮助团队协作，针对真正/合适的需求设计更好的方案。

  • Specific（明确的）
  • Measurable（可度量的）
  • Action-Oriented（面向行动）
  • Realisitc（现实的）
  • Timely（有时限的）

• 谁（Who）？

  “谁能产生需要的效果？谁会阻碍它？谁是产品的消费者或用户？谁会被它影响？”也就是那些会影响结果的角色。

  考虑涉及到的这些决策者、用户群和生态系统，注意角色同样有优先级，优先考虑最重要的角色。

  角色定义应该明确、避免泛化，可以参考用户画像Persona的方式进行定义。

影响地图的特点

• 结构性：从业务目标到交付的结构化梳理和挖掘的方法，目标--角色--影响--交付物。
• 整体性：连接目标和具体交付物之间的树状逻辑图谱。
• 协作性：利益相关人一起沟通讨论协作，把隐藏在个人头脑中的默认的思维逻辑挖掘共享出来。
• 动态性：动态调整、迭代演进、经验证的学习。
• 可视化：统一共享的视图，结构清晰易读。

影响地图将各个部门/角色不同的视角、不同的思维逻辑、不同的前提假设，通过可视化和协作的方式进行梳理、澄清和导出。通过连接交付内容、影响和目标，影响地图显示了之所以去做某个功能的因果链，同时也可视化了各利益相关人做出的假设。这些假设包括：业务交付的目标、涉及目标干系人、试图达到的影响。同时，影响地图沟通了两个层面的因果关系假设：

1. 交付会带来角色行为的变化，产生影响。
2. 一旦影响达成，相关的角色会对整体目标产生贡献。

影响地图的分层

是否可以将影响地图分层？ 答案是可以而且合理的。

建议计划两次会议：第一次定义预期的业务目标和度量，第二次来制作一张地图。第一步是确定使命，而一个战略目标往往太大，无法快速见效，需要拆分成可短期达成的战术目标。根据优先级排序的战术目标，逐次进行影响地图分析，期间动态调整更新，定期决定是否需要继续。

因此可以有两层的影响地图："一份针对整体产品愿景，一份针对中期交付。"

同时，通过分层，也可以有效的控制参与两个会议的人员组成。高阶的领导者未必需要参加所有的影响地图活动，尤其是战术影响地图会议。

参与人员

决策者，技术人员，业务人员。注意一定要有决策者参与，包括：商业决策、技术决策、营销决策。如果发现一个问题讨论很久没有决定，也许是因为缺乏合适的参与人员，应该找更高阶的人员决策。

参与人数：原书的建议是将第一次会议人数限制在不超过5-6人，确保关键的业务决策者和技术人员参与进来。随后的会议可以适当扩大规模分组讨论，随后汇总，但人数越多，会议的节奏和范围就越需要控制。

影响地图与用户故事的关联

• 影响地图可以作为用户故事列表的有效输入

  影响地图的输出物，可以作为用户故事的输入，作为Epic、User Story的来源。这些输入已经经过了价值判断、角色挖掘、优先级排序，甚至已经有了一部分的验收标准（是否影响了受众同时为达成目标作出贡献），同时也因为有资深技术人员的参与，初步做过技术可行性判断。因此这些backlog的输入，往往更加靠谱，对交付团队更具价值。

  • 输入形式

    《影响地图》书中有明确的描述，把三段式的用户故事与影响地图几个层级进行mapping：作为一个Who，我希望What，以便于How。

  • 用户故事管理 at DevCloud

    DevCloud中提供对用户故事的分级管理，可在“工作 > 需求规划”中，将影响地图中根据层级划分好的用户故事输入到DevCloud中，与影响地图的层级进行对应。

    需求规划视图以树形结构列出了需求从“Epic > Feature > Story > Task”的逐级关系。

    同时可以应用DevCloud对需求按照用户故事的通用格式进行编辑。

    ^{更多关于DevCloud敏捷项目管理的操作，参见项目管理帮助文档}。

• 影响地图可以很好的控制用户故事列表无限蔓延

  看似动态调整的用户故事列表，根据精益消除浪费的思想，维护完整的故事列表，事实上也是浪费。

  存在的问题有两点：

  第一，看不到用户故事与业务价值直接的联系，往往为了实现功能去做，而不是考虑其背后交付的价值，以及这个价值是否被用户认可。

  第二，故事列表往往是各方头脑风暴的结果，同时还在不断更新，却很少剔除，这个长长的列表不仅需要定期维护，其背景、内容、优先级、价值等都在随着商业环境的变化而不断变化，事实上维护一个三个月或者半年以后才可能实现的需求就是浪费。

  • 目标/里程碑与发布计划

    业务目标可以与迭代的发布计划关联，每次迭代只处理少量的目标。

    《影响地图》建议一次只处理一个目标，目的在于快速反馈和调整。个人认为基于团队规模、迭代步速，一次迭代可以包含几个目标取决于目标的颗粒度以及时间估算，不可一概而论。在具体执行时，这里会是一个争论以及变数较多的点。

如何防止思维蔓延，地图扩张

• 先发散再收敛

  实战练习中，我们40多人分成6组，分别绘制自己的影响地图；实际场景中，如果每组都基于同一个目标，绘制出来的地图会各具特色而发散，最终需要引导将发散的地图进行收敛，在此过程中，会发现更好的实现方式或是新的假设导出，最终得到成型的影响地图。

  

  分层和拆分时，掌握80/20原则，不求面面俱到，只需要涉及最关键重要的因素。考虑到大部分团队会使用物理板+即时贴的方式进行影响地图的设计，因此，原本因为物理空间受限以及可读性原因存在的物理白板的弊端，反而可以作为细化程度的一个有效限制原则（正如著名的两个披萨原则）：以物理墙/白板为影响地图的最大边界。

  相对于我们通常关心的业务功能/营销活动，即影响地图的第四层What，我们更应该把注意力放在前三层目标、角色和影响上，尤其是角色和影响上，关注点如此，优先级排序也是如此；先不要关注在What即自己要做什么事情上，这往往会让我们陷入执行的细节，埋头做事，而忽略了事情的初衷。

• 多数的路径最终不会被执行，是否需要保存？

  首先，要避免过早陷入过多的细节，未来一切都是未知的，所有的结论都是基于当前的假设。所以，维护一份完整的地图，试图将所有想法都归纳在地图上，是没必要的。

  其次，要遵循目标导向原则，避免在那些对整体目标没有作用的影响上花费过多的时间。整理出来的路径，当然可以保留下来，作为下一次影响地图的部分输入。

  此外，需要注意的是，What包含交付内容、软件功能和组织的活动，如果交付的所有条目都是技术性，也许要重新审视影响地图，尤其是角色Who与影响How两部分，并非所有的目标都是需要通过产品功能达成，更多情况下，也许一个简单的营销活动就可以快速实现目标。

什么时间结束

• 影响地图会议何时结束

  “当关键想法已经出现在地图上。”

  当团队已经达成目标，并且确定最快/小路径，暂时也想不出更好的替代方案时，就可以结束。

  建议设定严格的timebox，一旦出现时间点超时，或者是由于团队陷入太过细节的讨论，或是没有找对合适的人，例如缺乏合适的决策者，也许是业务决策者，也许是技术决策者。

• 影响地图何时失效

  如同计划，在制定出来的那一刻也许影响地图就已经失效，因此需要适时调整（注意是适时，未必是实时）。

  影响地图更像是迭代计划，每个影响达成，进行反馈评估，对影响地图的内容以及优先级进行调整；一旦目标达成，也许这张影响地图就完成了使命。

本文参考资料：