怎样梳理需求全景？
你真的需要梳理吗？
交付过程中的挑战
在产品研发和交付过程中，你是否遇到以下问题：
- 收到的需求较为零散，难以快速聚焦到用户场景中去
- 在需求分析时，难免遗漏掉一些不那么关键的需求
- 思考近期要交付的内容时，难以了解需求彼此之间的关系，就无法快速排除优先级
- 无法基于需求全貌去看待我们当前交付的进展
- 擅长进行功能需求的分析，时常考虑不到非功能需求
- ……
产生这些问题的原因可能在于，我们没有采取有效的方式来梳理和呈现需求的全貌，无法端到端的可视化用户需求场景，也就无法清晰理顺需求彼此之间的关系。而用户故事地图就是这样一个帮助我们梳理需求全景的有效工具。
使用用户故事地图梳理需求全景
用户故事地图作为一个需求识别和梳理的工具，帮助我们透过时间维度了解所有的产品需求，构建出需求全景图。
用户故事地图是一个有方向的图表：
- 从用户角色出发，直至完成用户目标结束
- 横向为时间线，相关的用户行为可以基于时间线放置
- 纵向为为必要程度，按优先级从高到低自上而下放置产品需求
- 在产品需求部分，同时包含了功能需求与非功能需求
制作用户故事地图的步骤：
- 准备好核心用户的用户旅程：确认角色、目标、用户行为
- 从核心场景出发，头脑风暴支撑每个用户任务的功能需求
- 列出支撑每个功能需求的非功能需求（安全、性能、质量、体验等）
- 审视整个用户故事地图，查缺补漏、去重
常见问题澄清
用户故事地图 vs 用户旅程
在制作用户故事地图的步骤中，我们提到第一步是准备好核心用户的用户旅程，可能大家会觉得一定是先有用户旅程，才有用户故事地图。而在实际情况中，有可能是在没有用户旅程的情况下，团队基于系统现有功能而梳理出了用户故事地图，使用它帮助团队梳理和规划需求全量。
我会倾向于认为，只要我们对用户角色、目标和关键行为理解正确，用户旅程并不是用户故事地图的必需输入。分析用户旅程的角度更多的是从用户行为和痛点出发，是一个帮助我们深刻理解用户、识别需求价值点的工具；而用户故事地图用于需求价值已确认的交付场景，更多的是基于软件功能和迭代规划的角度，帮助我们呈现和梳理需求全貌。这两个工具可能共用了用户角色、目标和关键行为，但分析思路和解决的问题是完全不同的，二者并没有明确的先后顺序、孰轻孰重或者二选一的关系。
功能需求 vs 非功能需求
在产品同质化愈发严重的今天，同类产品的功能需求大同小异，如果用户的行为习惯塑造完成，可能在功能需求上再多投入也难以形成差异化优势。在此时，关注如何提供更好的使用体验、确保生产环境的高可用、做好信息安全等提升非功能需求的响应措施，可能更有利打造产品的综合优势。
不是所有产品都需要梳理需求全景
之前聊了很多如何使用用户故事地图梳理需求全景的方法，那是不是所有的场景都可以这样梳理呢？答案是否定的。大家发现用户故事地图有其鲜明的特点：
- 从用户角色出发，有明确的用户目标（有用户、有用户目标）
- 从用户到目标，横向罗列了用户行为（有用户行为）
- 是一个有时序的端到端业务流程（有时序的业务流程）
当我们要处理的业务满足以上特征时，就能很方便的通过用户故事地图梳理需求全景。反之，当我们处理的业务不满足以上的一个或多个特征时，就无法方便快捷的用它进行梳理。举几个简单的反例：
- 没有用户行为的复杂逻辑判断程序：如复杂的拍卖算法、OCR等
- 前端逻辑简单而后端复杂的应用：如搜索引擎、复杂接口和后端集成等
- 没有时序的提供开放功能的基础平台：如开放接口平台、内部支撑平台等
小结
文章的最后，让我们再来审视一下开头的问题，回扣梳理需求全景的价值。
梳理需求全景对于需求规划有很大益处，希望大家能够结合产品需求的特点和团队情况，找到适合自己的梳理工具，使其有效服务于研发过程。