今天来和大家聊一聊需求评审的那些事儿 🧐。
需求评审是大家日常开发工作中，一个重要且频繁的工作。如果是评审一个自己非常熟悉的模块的需求，那会非常的轻松，因为你足够了解。
但是，假如你是去评审一个自己完全不了解的需求时，需要关注哪些点，才能保证你掌握足够的信息，从而顺利的完成开发呢？
来看看我在需求评审时，关注的点：
强烈建议你，为每一个需求创建一条笔记，把需求评审的重要信息记录下来 ✍。
下面简单为大家解释一下每个点。
1. 确定需求跟 APP 哪个版本上线
确定了跟版的版本号后，就能确定自己的需求最终要集成到哪个集成分支，然后就可以从对应的集成分支创建自己的功能分支。
假如评审完需求发现，需要的集成分支还没有创建，只能暂时从上一个版本的集成分支创建功能分支的话，那么一定要在笔记里备注一下，以免集成到了错误分支。
2. 确定各方人员是否到齐
一般来说，评审需求时，各端人员一定都要出席，人员齐整的话，遇到一些有疑问的点，才能及时的确定清楚，否者会后还需要单独找时间沟通，影响效率。
3. 确定是否涉及 UI 新增和改动
一般来说，公司的 UI 资源都是比较紧张的，所以本次需求如果涉及 UI 的改动的话，一定要确定 UI 图产出时间，以免项目延期。
同时，还需要确认是否涉及UI的动效，因为有动效和没有动效的开发时间和成本是有很大差别的，开发动效一般需要多投入一些精力去开发和自测。
当然了，非常复杂的动效，可以通过一些框架来加载，比如Lottie。
4. 是否会涉及线上流程的改动
一些需求会涉及到对线上流程的改动，比如混合开发项目中，FE 和 Native 存在交互，需要确认开发新需求是否会对这个交互有影响。
如果有影响，就需要你多了解一下老的交互流程是什么，测试 case 有哪些，具体改动点是哪里，改动以后对老流程有怎样的影响。
5. 是否需要做版本控制
一般新的业务需求，不用考虑版本控制问题。但是，如果是修改线上业务，一定要考虑版本控制：是 FE 去做，还是 Server 端去做？
6. 确定需求的所有入口，每个入口请求参数是否一致
记得有一次开发直播的需求，原本以为，直播只有一个入口，后来，等要提测的时候才发现，总共有 3 个入口 😌。
而且每一个入口涉及到不同的业务场景，因此，从不同的入口进来，请求接口的参数是不一样的。
并且直播还涉及到与 H5 通信，而且不同入口，协议也不一样。
所以，为了避免这种情况发生，一定要在评审的时候多关注这一点。
以上就是我们需求评审的时候会比较关注的几个点。
当然了，不一定很全面，但是大家记住一点就行了，需求评审的时候一定要多问几个为什么。
一定要多问几个为什么❓
一定要多问几个为什么❓
一定要多问几个为什么❓
并且建议大家把需求评审时候的一些重要信息记录到笔记里。
因为，在开发期间，你很容易受到其他事情的干扰，比如开会，或者中途让你修复一个bug，如果不记录下来，可能后面自己都忘记了。
最后，总结一下吧：
1.需求评审时，多问几个为什么；
2.随时记录下重要信息。
