写这篇文章的此时此刻，正在听徐大乐的《一个人的朝圣》。它一度是我非常喜欢的歌，它的作者而今是一个互联网人。有感于那句歌词“世界太大，人会迷路，要么庸俗，要么孤独”。世界总是太嘈杂，我只是想静静。坐在最常来的咖啡馆，写下这一章严肃的文。
当我们收集了大量用户故事进入机会阶段，并且根据3W方式筛选出“用于进一步讨论”的部分后，我们将带着这些用户故事，进入“探索阶段”。在这一阶段，我们的任务是讨论、明确这些用户故事在技术和设计侧的方向，最终形成待开发清单。
在探索阶段，要详细讨论谁会用、为什么要用以及怎样使用你的产品。团队的目标是构思一个有价值、有用、可行的产品。这时要做许多碎石的工作。只需要将最少数量的故事推入发布待办列表中，这些列表描述了一个最小可行产品版本。
——《用户故事地图》
第二阶段：探索阶段
这一阶段的目的是将讨论、明确“机会”的可行性方向，选择其中合适的部分组成待开发清单。这一阶段共有五个步骤。
1. 重新阅读并理解“机会”信息
这里不再赘述，因此为了更好的进行机会探索，需要对“机会”进行复习。回顾它们的3W信息。
2. 深入理解用户
“人物画像”是我们理解用户的方法，而“用户旅程图”则帮助我们理解用户行为，快速建立对用户和遇到问题的共识。
提到“人物画像”总感觉是很高深的内容。然而似乎并非如此，简单的用户画像方法也可以帮助我们很好的接近用户。你需要和团队一起明确、完成以下几个部分：
- 画出简单的人物素描（照片也行）；
- 基础信息：包括“Ta是谁？”、“Ta为什么要使用我们的产品？”
- 关于Ta：特点、目标&痛苦点、活动；
- 启示：“对Ta有什么价值？”、“这个方案能改变Ta的理由？”
“用户旅程图”可以做为脑暴解决方案的跳板，也可以通过它来验证自己心仪的解决方案是否真的可以解决问题。在用户原有行为路径中，去看它的“事件”、“观察”、“痛点”和“快乐”。此方法网络上有大量资料，这里不再赘述。
3. 快速可视化方案，进行逻辑、技术可行性评估
在回顾机会、理解用户及行为的过程中，解决方案会逐渐浮出水面。做为交互设计师，应该具体基础的手绘能力，能在会议中将大家说出来的方案快速在白板（大家都能看到的地方）上还原——它将大大提升方案输出的速度，并在共创中快速达成共识。除了界面草图，用户画像、流程图、照片和文字描述都是不错的方案呈现方式，唯一重要的是（此处敲黑板），快速的、将它们呈现在所有人都可以轻易看到的地方。
将可视化呈现的方案草图和故事地图（为什么要加入地图？后面会解释）放在一起，与参会的技术人员、设计师进行沟通，将能够快速获得专业建议，发现技术风险。减少“先需求后评审”带来的成本和时间浪费。在讨论过程中，我们可以使用“如果……会（怎样）”的语句来不断推敲方案、填补漏洞。这一过程中，会谈到硬件条件、数据情况、后台服务等内容，请确保自己对所有事情都做了笔记。后面你就会知道它们有多重要。
也许有人会有疑惑，为什么要在这里加入机会所在的故事地图？因为在开发过程中，我们易于关注有趣的功能而忘记在这期间的基本流程。然而机会所在的整个地图帮忙我们补充和记忆这些细节和过程。通过地图，能从全局角度发现技术限制。
4. 针对上述内容，重新校正用故事内容
在探索阶段的讨论过程中，具体应该讨论什么？哪些是必要或重要的？下表做为一个清单，也许可以帮助我们尽可能做好探索阶段的任务，试着让探索阶段讨论的内容包括以下内容。
| 标题 | 说明 |
|---|---|
| 产品角色 | 1)讨论不同类型的用户：在产品中，这个功能的用户包括哪些细分用户； 2)有哪些其他干系人； 3)若为企业软件，它的客户是怎样的； |
| 使用原因 | 为什么特定的用户会关注这些功能 |
| 使用场景 | 1)用户何时使用； 2)使用时的现实场景是什么； |
| 功能内容 | 1)用户希望通过软件来做的事情； 2)可将调用某不为人知的系统视为特殊用户; |
| 方案实现 | 1)有品质的讨论需要关注：为什么做、做成什么、怎么做； 2)没有明确谈到如何实现，就很难评估其实现成本； |
| 问题与假设 | 1)对技术假设发问：需要依赖的底层系统是什么；是否已了解这些系统的工作原理；还需关注的其他技术风险； 2)对产品假设发问：用户会接受这个方案吗？真的理解用户吗？它真是用户需要的的吗？是用户痛点吗？ |
| 异常情况 | 1)有哪些异常情况出现； 2)出现异常时，用户是否有其他方式完成任务； |
| 开发周期 | 1)随着讨论的进行，逐渐主准确出开发时间（xx天）； 2)根据开发周期的结果，判断是否中止开发或是继续； |
| 其他方案 | 丢掉文案中的部分假设，回到解决问题上来，找到最小成本、更有效的解决方案 |
5. 去掉低优先级的内容，保留必要内容进入下一阶段
当有多人参与讨论的时候，为了让每个人都满意，往往会以得到一个巨大的解决方案。这显示有违初衷。如果决定开发的故事数量最后大于“放弃开发的故事数量”，往往说明探索阶段没有做对。
写在后面
在探索阶段留下来的用户故事，将会进行产品原型的设计和细节讨论。探索阶段是从产品和用户层面来检测、过滤用户故事（我们在实际过程中一概称“需求”），我们在这一阶段的关注点优先顺序是：优先关注“优先满足的业务目标、用户群体”，然后再关注他们的需求中“优先满足的那部分”，最后再“根据需求，排列功能的优先级”。
探索阶段之所以重要，是因为它实际解决了成本问题。例如需求方担心会议效率低，不能快速输出结果，自己就直接把需求写完了。然而有时思考片面、知识结构受限，常会产出低质量、在需求会中被推翻的需求。若这个需求输出的过程中邀请各岗位重要人员参加（人数要限制在5人以内），不仅可以在前期就得到专业的反馈，同时还能突破单一的视角，为方案带来更多的可能性。
将早期的用户故事（需求）确认环节分为“机会”、“探索”两个阶段，看似是增加了环节，实际上却是有效控制流入后续阶段的需求质量，从整体上降低了协作成本和需求风险。毕竟也不是每个阶段，都需要所有人参加。
最后，以这段非常喜欢的歌词结束这一章。
做梦的 醒来的
沉默着 躁动着
世界太大 人会迷路
要么庸俗 要么孤独
……——《一个人的朝圣》徐大乐
—— end ——
全部内容链接：
用户故事地图（1）：体验用户故事
用户故事地图（2）：作用
用户故事地图（3）：故事与卡片
用户故事地图（4）：创建方法
用户故事地图（5）：开发流程之“机会”阶段
用户故事地图（6）：开发流程之“探索”阶段
用户故事地图（7）：开发流程之“设计”阶段
用户故事地图（8）：开发流程之“故事工作坊”阶段
用户故事地图（9）：开发流程之“研发-评估-交付”阶段
用户故事地图（10）：开发流程之“回顾”阶段
用户故事地图（11）：故事（需求）拆分
用户故事地图（12）：后记
