如何避免需求遗漏?
“我是淘音乐网的业务代表,你给我们做的音乐版权购买网站,我们试用了一下,离我们的预期还有很大的差距,我们这边无法通过验收,没法付款。”
“功能清单当初我们都跟你确认过了,该有的功能都有啊。”
“功能确实都有,但是不好用。”
“哪里不好用了?”
“比如,在线试听音乐功能,就不好用”
“稍等,我把界面打开看看......这界面原型当初也跟你确认过啦,点一下 '试听' 按钮就可以试听30秒音乐,很简单也很好用啊”
“有的歌我听几秒就不想听了,试听的时候都不能暂停、停止。
而且听完 30 秒停止时,音乐很大声突然停止很吓人的,试听时音量应该有淡入淡出的效果。
还有,试听时我想试听音乐中的任意30秒,你知道,有的音乐前奏都超过30秒了......”
“你说的这些听起来都有道理,可是当初提需求时,你们只说要试听功能,咋没告诉我们这些细节需求呢?”
“这些细节我也是在试用的时候才想到的啊。我以为你们是专业的产品人员,我想你们应该会考虑得很周到的。”
“哎,现在再加上这些细节需求还需要额外几天的时间。估计我们还得加班。能不能给我们加点钱?”
“这我不管。不做的话我们是不会给你验收的,别想拿钱。”
这个场景你有没有觉得很熟悉?等产品要上线、交付给甲方的时候,才发现需求收集不完整、需求遗漏,轻则导致需求变更、项目延期,重则导致产品无法通过验收、产品失败。
我们先来看看需求遗漏的常见原因:
-
用户说不清楚自己想要什么,直到他用了才知道
-
用户没有表达出隐形需求、细节需求
-
需求调研不够充分,没有为需求收集预留足够时间
-
调研时遗漏用户群、没找到合适的调研对象
-
异常情况考虑不足
这些原因有的是用户的原因,有的是产品开发者的原因。作为产品开发者(乙方),会遇到各种各样的甲方。我们不能把希望寄托在甲方身上,期待他们都很专业,能把需求描述的很清晰、很完整。
我们只能通过提升自己的技能来避免需求的遗漏。
如何避免需求的遗漏呢?业界内有些实践可以参考。
-
需求补充:通过场景分析法、360度分析法来补充细节需求、相似需求
-
检查清单:通过检查清单(Checklist)进行自查或需求评审
-
业务视角:给用户沟通确认的需求文档,不能从技术实现的视角来描述,因为大多数用户不懂技术,应该从业务视角/用户视角进行描述,这样用户才能理解,才能发现需求遗漏
-
原型法:一图胜千言。用图形的方式更直观,用户更容易理解,可以帮助用户发现需要遗漏,也可以减少需求沟通失真
-
需求评审:通过召集同行专家、业务代表参加需求评审会议,可以发现一些需求遗漏
-
干系人分析:通过干系人识别与分析、对目标用户群体进行梳理分类,确保没有忽视重要的干系人、没有遗漏用户群体
-
需求跟踪矩阵:通过对需求进行跟踪,确保项目范围内的需求都得到实现
在需求处理5步法中,第4步“补充需求”就是为了避免需求遗漏。
-
收集需求:从各种渠道收集原始需求
-
还原需求:对需求的关键要素进行还原
-
挖掘需求:对需求进行深入挖掘,找到深层次的需求
-
补充需求:举一反三,对相似需求、细节需求进行补充,避免需求遗漏
-
评估需求:评估需求的优先级、开发工作量,帮助制定项目迭代计划
接下来重点介绍补充需求的方法(场景分析法、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(增、删、改、查)操作,有没有遗漏?