如何规避需求评审遇到的坑

0 评论 948 浏览 15 收藏 8 分钟

对于产品经理而言,需求评审是每个项目开展前都需求做的事情。本文就为什么需要开展评审以及需要避的坑进行总结,希望对你有所帮助。

一、为什么要开展需求评审

  • 让设计、开发、测试同学知道需求目的及要做什么需求,明确项目分工;
  • 评估需求方案合理性:项目成员可以从用户视角出发,看需求方案是否能满足用户需求,或者是否还有更好的方案,可以提建议。让需求方案更加完善;
  • 评估技术实现可行性:系统层面的实现逻辑,开发同学比较熟悉,可以评估产品所提需求的可行性,视情况提出更好的技术实现方式;
  • 评估开发时长:这是项目落地前必须要确定好的技术排期。

二、需求评审遇到的坑

1. 需求逻辑遗漏

1)遗漏其他业务方的需求

举个例子,如果你做的是一款贷款产品,偏前端业务需求。当你要做新需求时,一定要考虑到风控端、资金端是否也要联动改造。比如你想把前端的借款入口合并优化用户体验,基本上会涉及到额度系统底层账户改造、资金端路由改造等。如果没把风控和资金的需求考虑进去,就开展需求评审,那就尴尬了。

2)没有考虑版本兼容

版本兼容问题的出现,主要原因是因为新版加了新接口,旧版是原生APP或H5旧链接,没有很好地识别新接口造成的一系列问题。

例如:

a. 新数据在旧版可否显示:如果后台系统以前有预留接口,新增加字段的数据应该可以在旧版正常显示。如果是后来新增接口,那前端识别不出来则默认不显示。

b. 新功能在旧版可否使用:一般来说,新功能大多数是新接口而且没有预留,所以一般不能在旧版使用。如果旧版有展示新功能入口,可提示用户升级到新版后使用新功能(当然只限于H5旧链接)。而且新接口需要做版本判断,只有新版本才可调用新接口。

3)没有考虑异常情况

我们往往只考虑到用户操作的正常流程,而缺乏考虑用户遇到的异常情况。正常流程很容易想到的是操作成功,但是用户操作失败也是很常见的状态。操作失败有如下五种情况:

a. 流程中断:中断是否要考虑信息保存,信息保存在本地还是服务器

b. 系统没有返回结果:系统之间有交互,没有返回结果,需要考虑兜底方案。例如设置默认值或调度机制

c. 重复点击多次:禁止用户点击或限制操作次数、限制一定时间内操作次数

d. 网络、服务器出错:提示出错,并给出解决方案

e. 等待超时:等待超时设置一个上限时间,超过时间则弹出失败提示,引导用户重试

f. 过期失效状态:操作失败不仅是系统出问题造成,也有可能是过了有效期,此时需要考虑有效期

2. 技术实现考虑不严谨

1)没有考虑接口共用

因为不了解旧接口,当提新需求时,有可能会与旧接口冲突,则产生新的问题。例如新需求是:时间间隔30分钟触发轮询,系统A就去轮询系统B。而以前有个旧接口,触发逻辑为时间间隔1分钟就要去轮询,新业务和旧业务共用一套逻辑。此时如果没有考虑到旧接口,新业务就贸然上线,有可能会出现生产事故。

2)系统处理是同步还是异步

这一点非常重要,涉及到前端交互是否变动。如果系统处理是同步的,那前端基本不需要让用户看到等待状态,立即出结果;如果系统处理是异步的,比如需要1分钟以上,前端一般需要提供等待状态,反馈实时进度以缓解用户等待焦虑。比如借贷产品里的放款环节,因为需要回调第三方资金方的接口,大概等待为15分钟,这时候加个等待状态就很合适。

3)已经有现成接口解决,又提出新的实现方案

提需求时,需要考虑好是否已经有解决方案支持,如果已经有,则无需重复造轮子。例如公司已经有完备的奖品发放系统,当新增一个奖品种类时,已经不需要再重新考虑奖品发放逻辑,复用已有逻辑即可。

3. 沟通没有达到预期

1)开会耗时较长

a. 需求不完整,开发一直在帮忙补逻辑,即上面说到的需求逻辑遗漏或技术实现考虑不严谨;

b. 开发人员没叫齐,中间插入浪费时间。以后应对这种情况,最好开会前就要确定好业务开发人员;

c. 开发花费太多时间讨论细节。遇到这种情况,产品经理最好引导开发先跳过,先把主要矛盾解决,再考虑次要矛盾。

2)研发理解需求与产品不一致

研发与产品理解不一致,会造成需求实现不符合预期。一般是产品快上线时才会暴露出来,直接造成的结果是项目延期。归根结底,大概率是前期需求评审时,产品经理没有很好地传达需求,或者没有跟开发确认好需求。要规避这种坑,最好在需求评审时,就要确认好项目分工。如前端需要改动什么,后台系统需要提供什么接口。

3)排期确定较慢

按照经验,排期确定最好是在评审会期间。因为需求刚评审完,开发大佬们对需求还比较有期待、有新鲜感。所以笔者的建议就是排期尽量在会上确定,这样的项目推进效率才高。

专栏作家

狐檬,公众号:小狐学产品,人人都是产品经理专栏作家。专注互联网金融领域,具有千万级互金产品和运营经验,擅长做业务增长。

本文原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 目前还没评论,等你发挥!