产品经理内容分享(二)：用户故事地图，测试左移到需求阶段

目录

用户故事地图

左移到需求阶段

---

用户故事地图

主要的用户故事场景，就是测试应优先关注的覆盖场景。本文就聊聊用户故事场景的脑爆梳理方法：用户故事地图。相关理论来自Jeff Patton。

常规的需求拆分手法，很容易让人忘掉软件需求的全景图，用户故事地图则是一个生动的全景故事挖掘活动，参加者不限于产品经理和设计师，也可以包括开发，测试，运营，业务代表。鼎叔曾参加了两次用户故事地图的工作坊，花了两三个小时完成了“早上起床做什么”的故事地图设计及讨论，印象还挺深刻。

用户故事的目的就是在协作中更好地达成共识，它比单纯描述事实的效率高很多倍，它也不是需求分析，后者目标是精确构建软件结构。因此，用户故事使用视觉方式是一个非常自然的结果，它为开发和设计之间建立桥梁。敏捷文档就应该做成类似度假照片/视频的回忆录。

好的用户故事讨论，是讨论为谁做，和为什么做（怎么做能让世界更美好），而不是只讨论做什么。最终我们希望用最小化的输出，来最大化成果及其影响力。

用户故事卡片很适合边讲边记，讲的时候工程师可充分利用肢体语言，并能灵活移动卡片的摆放顺序。

随着梳理出来的用户故事卡片越来越多，我们可以按照一定的时间先后顺序（横向）和必要程度（纵向）进行排列梳理，形成一张用户故事地图。即从左到右讲述故事，自顶向下拆分细节。

地图中的用户活动，是指的相似的人在相似时间完成的任务集合，它沟通了用户故事地图的主干脉络。

我们可以把用户故事的相应界面草图和其他注释，放在这个故事卡片的周边。故事卡的内容标签可以尽量生动，比如痛点、乐趣和奖励、问题、创意，鼓励多放照片而不仅靠文字。

借助创建用户故事地图的头脑风暴活动，我们可以对产品需求的价值及发生场景更加明晰。这是一场让用户需求变成“正好、更好、最好”的故事分解游戏。

我们应该从整体团队视角，展示不同卡片故事的依赖关系。粗看起来参与脑爆的人让卡片越来越多，但这不代表需求范围被延伸了，而是我们对需求的理解更加深刻了。

我们还会对现实成果排列优先级，而不是只从一个个功能本身排列优先级。具体功能的优先级建议这么排序：差异化功能（代表了产品的竞争优势），搅局功能（叫板领先的对手），降成本功能，基础功能（这是我们入场竞争的筹码）。

 

产品负责人（PO）也会根据必要程度把梳理出来的用户故事分批纳入不同的发布（release）版本计划。

PO应聚焦预期发布成果来决定系统内需要什么功能，用分割线划分出发布版本和路线路，这也体现了产品对现实世界产生的价值。通常前三个迭代版本可以这么划分：see it work（必备的主流程），make it better（周边功能，提高质量，增加风险故事-把风险可视化），make it releasable（为发布打磨细节，看到抢眼的效果，关注真实用户数据反馈）。

整个脑爆团队围绕产品故事的交流，从讨论具象的机会开始，验证要解决的问题是否存在。注意：用户不一定是他想要的产品的使用者。最佳的问题解决方案，来自需要解决问题的人，和有能力解决这些问题的人彼此协作。

团队具体可以从以下三点进行梳理和交流。

1) 用户类型分析：主要有哪几类典型用户，按什么属性能清晰区分？每一类用户使用产品（需求）的主要场景（差异化场景）在哪里？该类用户是如何在使用中获得满足感的（实现想要的价值）？

2) 这几类用户的占比如何？行为习惯和关注点有什么差异？是否有调研数据支撑这点？这会成为我们判断场景优先级的参考。

3) 关注用户故事场景地图中的“风险区域”。某些用户功能面临很多样的分支路径，需要进一步拆解为多个子场景；也有一些场景的预期响应结果难以判断，需要进一步地剖析。我们从地图中会发现，这些有待挖掘的“麻烦”通常会集中在地图中的特定功能区域，这个区域既是产品设计的难点，也是质量验收的难点。

以“手机管家App产品”作为例子，最早的产品主打功能是安全，防范手机木马病毒，但在实际运营和对用户行为的洞察中，发现传统安全的场景占比很低，而反骚扰、隐私保护等“泛安全”的需求更为迫切。于是产品的需求重心向泛安全演化，相应的测试体系内容也发生很大变化，从木马病毒的识别，转换为以骚扰拦截效果，隐私漏洞等为高优先级。

随着产品用户进一步的扩展，为了突破价值瓶颈，手机管家的重心放到了更高频的用户需求-手机空间管理（瘦身功能），因为空间占用越来越快且大容量手机价格昂贵，相关体验和精细化需求持续升级。测试策略和自动化建设的重心自然也发生变换，安全类功能就变成以稳定运营为主的模块，而团队在瘦身效果评测、微信等空间占用大户的专项清理等场景，投入了更多的测试精力，确保用户价值——“清理要快，空间释放足够大，重要信息不误删”这三项指标达到设计预期。

在地图集体脑暴中要注意的系列技巧：

1 不要从自己而非真实用户角度出发来思考

2 对于异地脑爆，可以借助远程工具让两地看板卡片能同步移动。

3 如果参与的人比较多，可以采用少数人（不超过5人）集中讨论用户故事，再分享出去。讨论过程采取金鱼缸协作模式，没有跳入讨论的人只能默默观察，出去一人才能进来一人参与讨论。

4 我们可以交付半个烤好的蛋糕，但不能交付一整个半熟的蛋糕。因此，用户故事要有完整的使用价值。

5 用户故事中会存在一些特别巨大的故事，如果我们像行星战机一样急着射碎巨石，碎裂的石头会让主角死得更惨。相反，我们可以把不重要的一类小故事（碎石）聚集成一张新卡片，暂时无需讨论它。

6 发散讨论完，我们还可以做一个收敛的讨论过程，把彼此关联的一组故事聚合在一个主题下，以方便集中解决一个商业机会。一个机会是否值得现在解决，还是延迟解决，我们主要基于这几个要素的讨论：对象是谁、解决什么问题，构想是怎样的，为什么，工作量大小。

7 地图脑爆团队是多样化的探索团队，主要角色是PO，UED/UX专家，技术专家，决定最终设计是看feasible、valuable、usable，而不是看民主投票，我们和用户不是乙方和甲方的关系。

8 用户故事地图也不一定要一次完成，也可以再次改进。我们拿出初版的地图展示，邀请让其他人针对疏漏提问，或者扮演不同的用户角色，排练这个时间轴上的用户活动，甚至让大家打散所有卡片重新组成地图。这个时候可以让旁边的观察者进行提问，最终巩固大家的共识。

9 从用户故事地图的脑爆，到最终的产品设计方案，需要良好的设计思维。设计者需要和用户共情，把产品的定义聚焦，形成关键想法，进而绘制原型图，并拿给干系人和目标用户进行测试。这个测试过程要避免仅仅邀请专业人士，避免强势否定，并合理控制成本。

迭代完成后：

为了自我学习，我们应该在迭代结束时进行回顾，从产品、设计和过程三个要素找到下一周期能进行的“小改变”，并承诺要达成，再对用户活动进行评分和反思。等产品真正发布后，我们的改进就更有价值了。这种验证性的学习胜过“可以工作的软件”和“面面俱到的文档“。

左移到需求阶段

测试左移是多年来测试行业的热门话题，在实际的践行中容易停留在“意识流”层面，仅仅是鼓励测试人员应该“主动做什么”，然而在业务压力大的常态下，被鼓励的尝试往往无疾而终。只有基于敏捷理念的理解，对研发生命周期各个环节进行质量内建实践，才能把测试左移落实成好习惯，形成好流程，最终内化为敏捷团队的本能。

具体而言，测试左移，可以移动到需求澄清阶段，也可以移动到开发设计、编码和开发自测阶段。

而测试右看，是指当研发阶段的测试活动结束，产品进入发布上线阶段时，测试人员依然不能放松对质量数据和用户反馈的敏锐度，持续汲取下个迭代如何改进的反馈，形成滚动提升的飞轮。

《测试左移和右看》这个专辑，将基于多年来的测试团队实践，分享在测试左移和右看活动中的推荐做法和有效经验，它们也是敏捷理念在测试活动中的落实，在整个软件生命周期中持续性测试。

为什么要左移到需求阶段

敏捷测试的本质是尽早测试，频繁测试，推动质量从源头内建。

而产品研发的源头，自然是需求产生及澄清阶段。精益需求的产生过程，就是测试左移最早可以发力的地方。

如果我们忽视在需求阶段的测试左移活动，仅依靠软件工程层面的效能提升，始终会存在部分本质矛盾难以解决的情况。需求质量难以提升，那么很容易给技术团队带来频繁的返工和浪费。测试左移到需求的本质，就是从一开始尽量提高需求的可测试性。

基于敏捷知识，先从精益需求的产生过程进行介绍。

一个软件产品需求的产生流程可以简单分为这几个阶段，最终将形成价值验证的闭环。

制定业务目标：确定产品的愿景，商业机会，和核心价值（包含产品定位的差异化策略等），并确定目标群体。以此为蓝图制定本年度的商业发展目标，包含量化指标。

梳理用户（或客户）需求：通过多种调查方式，如用户访谈，用户画像，用户调查问卷等，完成相关的定性定量分析，挖掘出用户真正需要满足的诉求，即定义好产品的“问题域”。在此阶段可以将梳理完成的用户需求写成BRD（商业需求文档）。

产品设计方案：在产品核心目标和定位的基础上，根据用户的本质诉求，形成完整的产品设计创意思路，最终给出可落地的产品设计方案，即梳理出产品的“解决域”。所谓可落地就是成本，时间，技术能力等限制条件都可以满足。这个阶段就可以开始输出PRD（产品需求文档）了。

拆解单个功能需求及用户故事：根据产品设计方案，对产品能力需求进行梳理和优先级排序，整理出具体的需求描述，然后进一步识别/拆解为可开发的用户故事。

需求评审会议：完成了上述的需求定义过程，产品负责人组织需求评审会议，和技术团队以及其他项目干系人澄清产品方案，分享需求背景知识，需求定义和优先级。团队估算工作量，确认交付计划（包括重要发布计划和短期迭代计划）。

测试人员如何提升需求质量

以上就是常见的需求产生及澄清过程，期间并非只由产品人员唱独角戏。在这些阶段中可以进行上一个专辑介绍的多种敏捷测试实践活动

。我们测试同学可以从下面几个方面进行质量把关，并输出专业意见，帮助产品经理和特性团队，在进入开发环节之前提升需求质量。

1）明确需求价值。

2）完善用户画像和用户故事场景。

3）需求评审前给出验收测试点，帮助团队建立需求验收标准。

4）迭代计划会议确保需求拆解合理，测试任务纳入估算。

5）需求评审中把关质量，并明确DoR纪律。

这篇文章重点说说测试人员如何实践前两方面的活动。

明确需求价值

首先，需要向业务方或产品经理获得背景知识，为什么我们要上这个需求？

第一，不做这个需求有什么损失？用户对我们这个需求有多期待？有没有具体反馈声音可以让我们学习？这对于测试场景的思考有极大好处。

第二，这个需求对公司有什么好处？提高满意度口碑，还是能提高收入？有利于我们未来盈利么？新需求是否匹配产品的“调性”（定位），它是否有利于产品长期目标的达成？

能提高用户口碑，或者提高利润的功能，自然是我们着力要保障的高优先级需求。

知道了业务价值是什么，成功的方向是什么，就能更充分地调动项目参与工程师的积极性。

其次，如何客观度量产品特性上线后带来了预期的价值？

虽然产品负责人对产品设计的价值（或商业变现目标）负责，但是产品价值是体现在具体指标的，和用户场景息息相关。测试人员知道了商业上的度量指标定义和目标，就能更加关注要验收的核心场景。

另外，对于预期价值的思考及信息同步，也给了产品负责人以终为始的压力。产品需求绝不是越多越好，甚至有可能新功能上线越多，用户流失越快。把产品预期价值和背后的逻辑晾晒给技术团队看，既可以推动产品设计更加深思熟虑，也可以获得技术人员宝贵的早期意见输入。

再次，多挖掘本产品相关的竞品信息和行业信息。

看竞品。本产品的竞争对手为用户提供了哪些相似能力的解决方案？他们和本产品的说明书差异是什么？实现方案有啥不同（哪个感觉更靠谱）？测试人员从中可思考什么场景、什么指标可以用来做竞品对比。

看行业（本领域）。本产品所在的细分领域，有什么规范/默认潜规则，是本产品（需求）应该顾忌的？本领域是否有约定俗成的产品形态/交互风格，让用户早已养成习惯？这背后有什么博弈故事么？理解约定俗成的法律、规范、强大习惯，就可以让测试断言（是否有效缺陷，严重程度如何）更有底气，降低争论成本。

最后，当需求功能上线一段时间后，敏捷特性团队通常应该复盘上线的结果，确认具体商业价值指标是否达成预期，产品设计方案是否达到预期，还可以针对上线的具体特性功能，观察用户使用健康度（通过数据埋点）是否达到设计预期。

如果没有达到预期，产品团队要思考背后缺失了什么，以此来调整后面的设计方案和需求安排。

完善用户画像和用户故事场景

测试人员同产品经理一道，梳理用户画像并给出自己的看法，再根据目标用户的特征和视角，针对性地调整测试优先级和覆盖场景。

首先，我们可以挖掘下，目标用户是从哪些维度来划分的？

一是从人口学特征划分，包括年龄，性别，地域，人体特征（如左撇子，手型大小，视力情况等等）。

二是从使用习惯和经验划分，如新手用户和老手用户，强目的性用户（专找秒杀，或用完即走）和漫游型用户（随便看看）。从中我们总结出用户的痛点和对产品的期待。

三是从文化背景/社会背景划分，识别用户的特征，如城市白领，小镇居民，乡村农民；如高级知识分子和中学文凭的工人；如中国大陆用户和东南亚用户等。对于测试人员不熟悉的社会文化背景，比如海外市场产品，有必要认真学习当地社会和文化知识，甚至出差去该国家走访，体验典型用户所处的生活氛围。

四是从平台角度来划分，是公司外部用户还是公司内部用户（如管理员）。

理解了被划分的主要用户类型，我们可以在脑海里尝试给每种类型创造一个生动的典型人物，起一个名字，如电商产品的用户——张小婷，想象她具备上述哪一种个性特征，如果她给我们产品的各个功能进行满意度打分，会打几分？标准是什么？她会用什么关键词来表达情绪？

当然，我们也可以从客服“用户之声”详细原声访谈中，或者从产品经理做用户调研的定性分析和定量分析中，寻找生动的典型用户形象、使用习惯和评价尺度。