如何避免需求遗漏？

“我是淘音乐网的业务代表，你给我们做的音乐版权购买网站，我们试用了一下，离我们的预期还有很大的差距，我们这边无法通过验收，没法付款。”

“功能清单当初我们都跟你确认过了，该有的功能都有啊。”

“功能确实都有，但是不好用。”

“哪里不好用了？”

“比如，在线试听音乐功能，就不好用”

“稍等，我把界面打开看看......这界面原型当初也跟你确认过啦，点一下 '试听' 按钮就可以试听30秒音乐，很简单也很好用啊”

“有的歌我听几秒就不想听了，试听的时候都不能暂停、停止。

而且听完 30 秒停止时，音乐很大声突然停止很吓人的，试听时音量应该有淡入淡出的效果。

还有，试听时我想试听音乐中的任意30秒，你知道，有的音乐前奏都超过30秒了......”

“你说的这些听起来都有道理，可是当初提需求时，你们只说要试听功能，咋没告诉我们这些细节需求呢？”

“这些细节我也是在试用的时候才想到的啊。我以为你们是专业的产品人员，我想你们应该会考虑得很周到的。”

“哎，现在再加上这些细节需求还需要额外几天的时间。估计我们还得加班。能不能给我们加点钱？”

“这我不管。不做的话我们是不会给你验收的，别想拿钱。”

这个场景你有没有觉得很熟悉？等产品要上线、交付给甲方的时候，才发现需求收集不完整、需求遗漏，轻则导致需求变更、项目延期，重则导致产品无法通过验收、产品失败。

我们先来看看需求遗漏的常见原因：

• 用户说不清楚自己想要什么，直到他用了才知道

• 用户没有表达出隐形需求、细节需求

• 需求调研不够充分，没有为需求收集预留足够时间

• 调研时遗漏用户群、没找到合适的调研对象

• 异常情况考虑不足

这些原因有的是用户的原因，有的是产品开发者的原因。作为产品开发者（乙方），会遇到各种各样的甲方。我们不能把希望寄托在甲方身上，期待他们都很专业，能把需求描述的很清晰、很完整。

我们只能通过提升自己的技能来避免需求的遗漏。

如何避免需求的遗漏呢？业界内有些实践可以参考。

• 需求补充：通过场景分析法、360度分析法来补充细节需求、相似需求

• 检查清单：通过检查清单（Checklist）进行自查或需求评审

• 业务视角：给用户沟通确认的需求文档，不能从技术实现的视角来描述，因为大多数用户不懂技术，应该从业务视角/用户视角进行描述，这样用户才能理解，才能发现需求遗漏

• 原型法：一图胜千言。用图形的方式更直观，用户更容易理解，可以帮助用户发现需要遗漏，也可以减少需求沟通失真

• 需求评审：通过召集同行专家、业务代表参加需求评审会议，可以发现一些需求遗漏

• 干系人分析：通过干系人识别与分析、对目标用户群体进行梳理分类，确保没有忽视重要的干系人、没有遗漏用户群体

• 需求跟踪矩阵：通过对需求进行跟踪，确保项目范围内的需求都得到实现

在需求处理5步法中，第4步“补充需求”就是为了避免需求遗漏。

1. 收集需求：从各种渠道收集原始需求

2. 还原需求：对需求的关键要素进行还原

3. 挖掘需求：对需求进行深入挖掘，找到深层次的需求

4. 补充需求：举一反三，对相似需求、细节需求进行补充，避免需求遗漏

5. 评估需求：评估需求的优先级、开发工作量，帮助制定项目迭代计划

接下来重点介绍补充需求的方法（场景分析法、360度分析法），并提供一个检查清单（Checklist）供参考。

1、场景分析法

a）场景痛点分析

通过对用户的使用场景进行分析，分解出每个步骤，找出每个步骤用户会面临的问题与挑战，然后针对这个挑战，提出解决方案/功能需求。

举个例子。乘客在使用滴滴出行APP打出租车时，我们可以把打出租车的过程分解为如下步骤：

1.打开APP，输入起点、终点

2.呼叫出租车

3.等待司机接单

4.司机接单

5.等司机来接

6.司机到达

7.上车

8.在途中

9.到达目的地

10.支付、拿发票

11.评价

接着分析乘客在每个步骤可能会遇到的问题与挑战，再根据问题与挑战给出解决方案、提出功能需求。

在第1步中，输入起点时，乘客如果在陌生地方不知道起点名称，滴滴APP应该提供自动定位功能。

在输入终点时，手机打字不方便，可以提供语音输入功能；经常打车去的地方（如公司、家）可以设为常用地点；最近打车去的地方可以在历史地点中找到供用户选择。

在第2步呼叫出租车时，乘客如果很赶时间想快点叫到车，可以通过追加红包、同时呼叫多种车型的功能帮助乘客快点叫到车。在一个偏僻地方车很少时，怕太偏僻司机不来接，可以提供“打表来接”的功能让更远的司机也愿意来接乘客。

后面的几个步骤你可以接着来分析，相信可以找到不少细节需求。然后你会发现，你找到的细节需求可能在滴滴出行APP已经实现了。

下面是场景分析法的表格，简单有效，你可以在工作中马上使用起来。

b）同类场景扩充

接到用户提出的需求后，要举一反三，对同类场景进行扩充，看看有没有相似需求、相关需求。

例如，酒店管理系统中有登记入住的功能，前台服务员在给客人办理入住时，同行的旅客会提出要相邻房间的要求。所以在做登记入住的功能时，就要考虑如何帮助前台服务员找出指定房型的相邻的房间。

但不能止步于此，还要举一反三，看看在登记入住的时候，客人还会提出哪些类似的需求。

比如：房间要安静、不靠马路、远离电梯、无烟......

在做登记入住的功能时，要把这些潜在的需求与“要相邻房间”的需求一起考虑、评估。否则后续极有可能会提出这些需求，造成需求变更。

2、360度分析法

对B端产品来说，用户要完成一个工作任务、达成工作目标通常不是独立完成的，往往需要其他角色的协作来共同完成。

所以，我们在做B端产品的需求分析时，不能只考虑某个角色的需求，还要考虑跟这个角色有工作交集的相关角色的需求。如果没有考虑其他角色的需求，可能获取到的需求是不完整的，就会造成需求遗漏。

我们可以参考企业绩效考核中的“360度考核法”（也称为“全方位考核法”，是指由员工自己、上司、下属、同仁同事、顾客等从全方位、各个角度来评估人员的方法），从360度进行分析，找出这个角色的上游、下游、管理者、协作者，分别考虑他们的相关需求。如下图所示。

例如，在设计超市收银机管理系统时，除了考虑收银员的需求，还要考虑相关联角色的需求：

• 上游：买单的顾客，担心买单价格与货架标价不符或误看单价，希望在收银员录入商品时也有一个面向顾客的LED显示屏显示每笔金额。

• 下游：财务人员，收银员交班时要把钱与收银数据交给财务人员对账，财务人员希望及时对账，不要影响下班。

• 管理者：超市经理，担心收银员会通过改单来贪污钱款，希望把收银员的改单权限收回，改单要找超市经理，超市经理可以用钥匙在收银机上切换到改单模式。

• 协作者：搬运工，负责把顾客买单时临时不要的商品搬回库房。希望顾客少退货，较少工作量。

3、检查清单

检查清单也是避免需求遗漏的有效手段，用于自查或需求评审时提醒检查，预防错误的发生。

每个成熟团队都有自己的检查清单。下面是跟需求遗漏有关的检查项，你可以根据你的产品特征从中选择检查项，来扩充你自己的检查清单。

a）异常情况

• 网络类：无网络、网速慢、网络环境的变化、网络连接超时、服务器异常

• 帐号类：是否支持游客模式、未登录、多设备同步、身份标记（token）失效、是否支持第三方登录、账号切换

• 硬件类：屏幕过大、屏幕过小、找不到相关设备、横竖屏旋转、内存不足、配置过低

• 权限类：无权限、权限不足（相册、照相机、定位、麦克风）

• 缓存类：内容编辑是否缓存，最新数据与缓存数据不一致

• 活动类：活动有效期，过期提醒

• 数据类：数据为空、数据丢失，数据加载失败，数据库访问失败

• 操作类：页面布局是否支持横竖屏、是否支持异步操作、执行某个操作的同时执行其他操作是否允许（如在语音播放过程点击返回是否结束语音播放）

• 输入类：输入长度限制、输入字符限制、内容违规处理

• 状态类：夜间模式、飞行模式、离线模式

• 版本类：历史版本的兼容、什么时候强制更新

• 平台类：安卓与iOS的操作差异、操作系统版本的差异

b）容易被遗漏的功能需求

• 数据采集与分析

• 版本自动升级

• 用户反馈渠道

• 推送通知

• 公告栏

• 后台维护管理

• BUG信息收集

• 新手引导

• 第三方账号登录

• 好友邀请

• 分享到朋友圈

c）考虑流程的异常分支

如：ATM机取款，除了考虑主流程（成功取款），还要考虑如下异常分支：

分支1－ATM内没有现金

分支2－ATM内现金不足

分支3－密码有误（还有输入机会）

分支4－密码有误（不再有输入机会）

d）约束

• 技术性约束

• 法规性约束

• 标准型约束

• 遗留系统集成

• 分批实施

• 指定时间上线

• 竞争因素

• 多国语言

• 用户水平

• 保密要求

e）对称操作

• 备份、恢复有没有漏了一个？

• 撤销、重做有没有漏了一个？

• 数据实体通常都有CRUD（增、删、改、查）操作，有没有遗漏？