纸上谈兵：用户故事地图（8）之项目需求评审
入冬许久，今天才刚刚有点凉意，把早早拿出来的卫衣换上。写这篇文章的此时，我和朋友们坐在星巴克，一边感受着久违的闲适，一边懒散的码着字。前两天回顾2018年计划——《用户故事地图》读书笔记是做为年度计划来准备的，看来我早就知这件事情的困难——翻译的书真是太难懂。看看思维导图后面还有很多内容，不知道在12月底之前，是否能把它们全都写完。
从各方收集到的需求（用户故事），经过了机会阶段的初步筛选、探索阶段的设计与开发侧的可行性评估，以及设计方案的实现和验证。接下来，将会进入团队共同参与的故事工作坊（在我看来就是项目需求评审会，以下均称为“评审会”），它也称为最后一次最佳参与的机会。
这一阶段主要讨论细节，其目标有2点：
- 基于开发层面拆分需求为小模块，以制定后续开发任务的迭代计划；
- 对开发的各个小模块达成一致的验收标准；
准备阶段
首先，在会议开始前要选择粒度合适的故事进入评审，清楚这些需求必要的细节，如有必要可以提供多种方案来进行评估。
提前邀请开发团队、其他利益相关人士等进入会议，例如开发人员、测试人员、体验专家、视觉相关设计师，总数在3〜5为益。为保证会议效率，会议人员不益过多（我们都经历过又臭又长的会议）。然而，在同一场会议中，在不同阶段可能需要不同的人参与。这里介绍一个“金鱼缸协作模式”，可以保证让更多人参与，同时降低人数太多造成的影响。
金鱼缸协作模式
具体如上图。参与讨论的3〜5个人聚集在白板前讨论——他们就是鱼缸里的金鱼。处于鱼缸（上图中的圈）外面的人只能看，不能讲话。鱼缸外的人要想参与讨论，必须与鱼缸里的人互换才行。
待上述内容准备就续后，接下来正式进入评审会。
执行阶段
1､与所有人一起，再次了解故事的大体情况
与前几个阶段一样，会议开始时候我们依然需要讲清楚3W（what、why、who）信息。有时候我们会认为团队成员不关心产品，只完成自己应该做的内容，不会从整体考虑。但我认为真实的原因是，项目并没有创造让成员们关心产品的环境，需求来源往往下意识认为其他人执行即可，不需要了解太多背景信息。同时也为了节省时间，会在评审会时直接讲解需求内容。这恰恰剥夺了成员们了解产品的机会。由此可见，讲清楚每个需求的3W信息（特别是why）非常必要。
在会议中，所有人通过讨论和交流，明确几个内容：
- 用户是谁？
- 他们是如何使用产品的？
- 功能完成后看起来应该是怎样的？
- 我们要如何开发这些功能，他们的工作原理（业务逻辑、数据等）是怎样的？
在讨论方案过程中，尽量以用户视角来讨论，例如“用户在做什么”、“用户接下来会看到什么”。若遇到产品内部逻辑时候，可以使用“数据是如何输入的”这样的表述方式，更容易被所有人理解。
会议中随时记录大家的想法和点子。非常建议借助一些道具来记录，例如白板、挂图、便利贴等，这样即可以防止信息被蒸发，也可以让大家都看到所有内容。（近期看了一本书《设计冲刺》，同样倡议使用这样的方法）。
2､分组讨论
待所有人了解了功能的大概内容和运行原理之后，接下来要将参与人员分组，尽量保证每个小组有测试人员、开发人员、体验设计师或需求人员。各组用固定时间，制作出这些用户故事的开发计划（估时）。
3､小组间分享计划和估时
每个小组分享他们制定的开发计划（不要讲细节），在此期间，需要指出开发功能的问题和改进点，并估算开发时间。
对很多人来讲，估算开始时间有时候是不太可能的。我猜测主要是对待开发内容和原有产品运行机制不了解导致：未知=不可估。而用户故事地图的过程，可以帮助大家对功能开发内容达成一致性的理解。此外，还可以将相似规模需求的实际开发时间做为样本，以让开发时间估算尽量接近于真实值。而对于这一点，则需要我们对已投入的开发时间进行记录，尽可能将大的计划切分为小的部分，这样就可以获得更多度量的机会。度量越频繁，统计的时间结果越接近于真实值。
会议人员需要对上述开发决策和另外一项内容达成共识。“另外一项内容” 是指，验证功能开发完成的最低标准（换句话说，就是一起评审软件时，应如何展示开发的内容，例如按用户操作流程，保证这个流程可以走通）。对验收标准的讨论，可以揭示如何进行工作分解。我们可以开发分解后得到的故事，并进行及时的检查和调整。
异常情况
用户故事工作坊的效果可能不会理想（开过需求评审会的同学应该深有体会），有几点原因可能会导致这一情况的出现：
- 不能从功能和技术角度考虑方案，整个会议过程都在务虚；
- 大家只关注如何完成功能，不关心3W内容；
- 一言堂，没有人积极参与。如何解决这些问题，那就是会议组织和管理的相关内容，可以自行学习。
除此之外，还有可能在讨论细节和思考开发时间时发现故事太大，无法在规定时间内完成。这个时候就需要进一步分解故事——将“更好”的用户故事，拆解为“正好”的用户故事。
