怎样梳理需求全景?

你真的需要梳理吗?

交付过程中的挑战

在产品研发和交付过程中,你是否遇到以下问题:

  1. 收到的需求较为零散,难以快速聚焦到用户场景中去
  2. 在需求分析时,难免遗漏掉一些不那么关键的需求
  3. 思考近期要交付的内容时,难以了解需求彼此之间的关系,就无法快速排除优先级
  4. 无法基于需求全貌去看待我们当前交付的进展
  5. 擅长进行功能需求的分析,时常考虑不到非功能需求
  6. ……

产生这些问题的原因可能在于,我们没有采取有效的方式来梳理和呈现需求的全貌,无法端到端的可视化用户需求场景,也就无法清晰理顺需求彼此之间的关系。而用户故事地图就是这样一个帮助我们梳理需求全景的有效工具。

使用用户故事地图梳理需求全景

用户故事地图作为一个需求识别和梳理的工具,帮助我们透过时间维度了解所有的产品需求,构建出需求全景图。

用户故事地图.png
用户故事地图

用户故事地图是一个有方向的图表:

  • 从用户角色出发,直至完成用户目标结束
  • 横向为时间线,相关的用户行为可以基于时间线放置
  • 纵向为为必要程度,按优先级从高到低自上而下放置产品需求
  • 在产品需求部分,同时包含了功能需求与非功能需求

制作用户故事地图的步骤:

  1. 准备好核心用户的用户旅程:确认角色、目标、用户行为
  2. 从核心场景出发,头脑风暴支撑每个用户任务的功能需求
  3. 列出支撑每个功能需求的非功能需求(安全、性能、质量、体验等)
  4. 审视整个用户故事地图,查缺补漏、去重

常见问题澄清

用户故事地图 vs 用户旅程

在制作用户故事地图的步骤中,我们提到第一步是准备好核心用户的用户旅程,可能大家会觉得一定是先有用户旅程,才有用户故事地图。而在实际情况中,有可能是在没有用户旅程的情况下,团队基于系统现有功能而梳理出了用户故事地图,使用它帮助团队梳理和规划需求全量。

我会倾向于认为,只要我们对用户角色、目标和关键行为理解正确,用户旅程并不是用户故事地图的必需输入。分析用户旅程的角度更多的是从用户行为和痛点出发,是一个帮助我们深刻理解用户、识别需求价值点的工具;而用户故事地图用于需求价值已确认的交付场景,更多的是基于软件功能和迭代规划的角度,帮助我们呈现和梳理需求全貌。这两个工具可能共用了用户角色、目标和关键行为,但分析思路和解决的问题是完全不同的,二者并没有明确的先后顺序、孰轻孰重或者二选一的关系。

功能需求 vs 非功能需求

在产品同质化愈发严重的今天,同类产品的功能需求大同小异,如果用户的行为习惯塑造完成,可能在功能需求上再多投入也难以形成差异化优势。在此时,关注如何提供更好的使用体验、确保生产环境的高可用、做好信息安全等提升非功能需求的响应措施,可能更有利打造产品的综合优势。

FR&NFR.png
功能需求 vs. 非功能需求

不是所有产品都需要梳理需求全景

之前聊了很多如何使用用户故事地图梳理需求全景的方法,那是不是所有的场景都可以这样梳理呢?答案是否定的。大家发现用户故事地图有其鲜明的特点:

  1. 从用户角色出发,有明确的用户目标(有用户、有用户目标)
  2. 从用户到目标,横向罗列了用户行为(有用户行为)
  3. 是一个有时序的端到端业务流程(有时序的业务流程)

当我们要处理的业务满足以上特征时,就能很方便的通过用户故事地图梳理需求全景。反之,当我们处理的业务不满足以上的一个或多个特征时,就无法方便快捷的用它进行梳理。举几个简单的反例:

  • 没有用户行为的复杂逻辑判断程序:如复杂的拍卖算法、OCR等
  • 前端逻辑简单而后端复杂的应用:如搜索引擎、复杂接口和后端集成等
  • 没有时序的提供开放功能的基础平台:如开放接口平台、内部支撑平台等

小结

文章的最后,让我们再来审视一下开头的问题,回扣梳理需求全景的价值。

梳理需求全景的价值.png
梳理需求全景的价值

梳理需求全景对于需求规划有很大益处,希望大家能够结合产品需求的特点和团队情况,找到适合自己的梳理工具,使其有效服务于研发过程。

All rights reserved
Except where otherwise noted, content on this page is copyrighted.