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

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

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

二、需求评审遇到的坑

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）排期确定较慢

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