对于一个传统设计师来讲，仅仅理解“开发流程”、“项目管理”、“敏捷”等术语的表层含义都要大费脑筋。然而交互设计师却是冠以设计师之名，但从知识结构、技能、思维方式等都与传统设计师大相径庭。“产品设计师”做为交互设计师未来职业发展方向之一，则要求拥有更富结构的知识体系，对产品、团队、项目有更深的理解，而这也是我写这一系列文章的原因之一。
从这一篇开始，将会进入正式的知识“转述”过程，如若这些文章有幸被此领域专家看到，发现了其中的错误漏，还请斧正，帮助我们成长进步。
上篇文章结合一次沙龙简单介绍了用户故事的内容和作用。那它能解决哪些具体问题？在介绍用户故事的具体内容之前，我们先简单聊聊，我认为用户故事图最实用的三个方向：
- 规划版本需求；
- 验证需求有效性；
- 产品优化与开发跟踪；
规划版本需求
对于用户，版本开发的功能间有哪些影响？各阶段版本对产品和用户的整体影响是什么？是否要遵循某些线索和规则？这些取决于如何选择各版本的开发内容。
每个产品都会有一个需求池，里面存储大量等待消化的需求。每当规划新版本，从需求池中翻找需求都是很痛苦的过程。我曾带过一个项目，我们使用用户故事的语术描述需求，以便判断其对用户的影响。随着时间推移，有些需求不再适用，但需求数量依然“稳步”增加。这此需求粒度不同、指向不同，每次筛选需求都十分痛苦不说，团队也被带入各种细节中无法自拔。
用户故事地图很好的解决了这一问题。它从需求层面，对产品进行横向流程和纵向细节的梳理。将需求按照核心操作流程进行组织。每次先聚焦于各关键流程环节，再筛选对应需求。即保证持续从大局着眼，同时，又对所有需求进行了结构性的组织。
验证需求有效性
产品开发中如何评估需求可靠性？如何评估与权衡需求的用户价值和产品价值？以用户故事驱动的开发流程，提供了一些快速、不断验证需求可靠性的方法。
在用户故事地图中，未经讨论的需求被称之为“机会”。在团队中，分阶段对这些“机会”进行不同层面（真实性、用户/产品价值、重要性、成本等）的提问，以在开发前发现不合适的需求，节省后期的沟通和设计开发成本。
流入开发阶段的需求，结合快速原型、可用性测试、用户阶段测试等方式快速校验方案，并更新到用户故事地图中，以让所有变化在整个地图中得到体现，便于团队随时刷新对产品的整体认识。
产品优化与开发跟踪
开发和测试工程师普遍讨厌变更，有时候以变更数量多来说明需求质量差。变更越少越好吗？大多数人都期待需求在早期就能完整和正确，然而哪些最牛逼的产品和交互设计师，都无法代表用户——在没有反馈和验证的情况下保证方案适用。我们需要正确认识“变更”，它其实是在开发过程中不断发现、学习新的知识，以修正最初的结果的工具。以变更数量来判别需求好坏，并非明智之举。
在开发过程中，常有“将XX功能放在后续版本”、“具体看上线数据情况再调整”这种情况，但现实却是这些“后续开发”的功能往往石沉大海。将这些“后续开发”的功能放在用户地图中，就能在后续规划功能时看到它，并从大局去考虑是否真的有必要优化。
产品负责人希望项目中所有人都关心产品，并且就开发内容达成共识。但现实却是，除了产品负责人和需求方，其他人大多扮演“被说服”的对象，被动完成任务。这导致需求方成为产品的瓶颈，而产品上线后的好坏，其实在开发之前就已被决定。
大多情况下，流入开发环节的需求已经被确定，团队直接按照需求完整开发、测试，有时候遇到性又红又专、历史逻辑问题，导致整体被推翻或干脆中止。侥幸上线，之后接触到用户发现效果不佳，只能缝缝补补，非常被动。用户故事地图驱动的开发流程，建议我们分三个阶段来开发功能。各阶段中分别进行测试，以验证其对用户的有效性和稳定性。
| 阶段 | 内容 | 目标 | 说明 |
|---|---|---|---|
| 开局 | 开发核心流程 | 排除技术风险 | 1、通过数据观察功能的性能； 2、使用自动化测试检验稳定性; 3、关注技术挑战和风险，通过消除技术风险，避免风险在后期造成更大成本; |
| 中局 | 开发周边功能 | 关注质量，达到可发布标准 | 1、开发主流程之外的其他可选流程和复杂逻辑； 2、常常加入之前未发现的新特性; 3、原系统无法满足性能上的需求而需要额外投入来解决的问题 |
| 末局 | 打磨产品 | 让产品更抢眼、使用更高效 | 1、可能会加入未预想的东西； 2、使用线上真实数据测试； 3、常常会现在原型阶段无法识别的改进点 |
下期预告：用户故事的内容、用户故事地图的创建方法
网友评论