评审需求时，需要关注什么

需求评审是大家日常开发工作中，一个重要且频繁的工作。如果是评审一个自己非常熟悉的模块的需求，那会非常的轻松，因为你足够了解。但是，假如你是去评审一个自己完全不了解的需求时，需要关注哪些点，才能保证你掌握足够的信息。

一、评审需求

需求评审是大家日常开发工作中，一个重要且频繁的工作。如果是评审一个自己非常熟悉的模块的需求，那会非常的轻松，因为你足够了解。但是，假如你是去评审一个自己完全不了解的需求时，需要关注哪些点，才能保证你掌握足够的信息。

1. 确定需求跟 APP 哪个版本上线

确定了跟版的版本号后，就能确定自己的需求最终要集成到哪个集成分支，然后就可以从对应的集成分支创建自己的功能分支。

假如评审完需求发现，需要的集成分支还没有创建，只能暂时从上一个版本的集成分支创建功能分支的话，那么一定要在笔记里备注一下，以免集成到了错误分支。

2. 确定各方人员是否到齐

一般来说，评审需求时，各端人员一定都要出席，人员齐整的话，遇到一些有疑问的点，才能及时的确定清楚，否者会后还需要单独找时间沟通，影响效率。

3. 确定是否涉及 UI 新增和改动

一般来说，公司的 UI 资源都是比较紧张的，所以本次需求如果涉及 UI 的改动的话，一定要确定 UI 图产出时间，以免项目延期。

同时，还需要确认是否涉及UI的动效，因为有动效和没有动效的开发时间和成本是有很大差别的，开发动效一般需要多投入一些精力去开发和自测。

当然了，非常复杂的动效，可以通过一些框架来加载，比如Lottie。

4. 是否会涉及线上流程的改动

一些需求会涉及到对线上流程的改动，比如混合开发项目中，FE 和 Native 存在交互，需要确认开发新需求是否会对这个交互有影响。

如果有影响，就需要你多了解一下老的交互流程是什么，测试 case 有哪些，具体改动点是哪里，改动以后对老流程有怎样的影响。

5. 是否需要做版本控制

一般新的业务需求，不用考虑版本控制问题。但是，如果是修改线上业务，一定要考虑版本控制：是 FE 去做，还是 Server 端去做？

6. 确定需求的所有入口，每个入口请求参数是否一致

记得有一次开发直播的需求，原本以为，直播只有一个入口，后来，等要提测的时候才发现，总共有 3 个入口 。

而且每一个入口涉及到不同的业务场景，因此，从不同的入口进来，请求接口的参数是不一样的。

并且直播还涉及到与 H5 通信，而且不同入口，协议也不一样。

所以，为了避免这种情况发生，一定要在评审的时候多关注这一点。

以上就是我们需求评审的时候会比较关注的几个点。

当然了，不一定很全面，但是大家记住一点就行了，需求评审的时候一定要多问几个为什么。

并且建议大家把需求评审时候的一些重要信息记录到笔记里。

因为，在开发期间，你很容易受到其他事情的干扰，比如开会，或者中途让你修复一个bug，如果不记录下来，可能后面自己都忘记了。

最后，总结一下吧：

1.需求评审时，多问几个为什么；

2.随时记录下重要信息。

延伸阅读：

二、评审类型有哪些

按评审目的分类，可以分为管理评审和技术评审。管理评审是对项目计划、进度、资源、成本相关工作产品的评审，重点关注项目状态，根据评审结果决定下一步的工作安排。例如进展评审、里程碑评审就属于管理评审。技术评审是对项目工程技术类工作产品的评审，评估技术成熟度，检查是否满足规定的需求和标准，尽早发现问题和缺陷。同行评审属于技术评审。

按评审的组织范围分类，可以分为内部评审和外部评审，其中内部评审又包括公司级评审、部门级评审以及项目级评审。

按评审的组织方式分类，可以分为会议评审和审查。审查是指由评审人员独立对工作产品进行检查，记录问题并反馈审查结论。

最后建议，企业在引入信息化系统初期，切记要合理有效地运用好工具，这样一来不仅可以让公司业务高效地运行，还能最大程度保证团队目标的达成。同时还能大幅缩短系统开发和部署的时间成本。特别是有特定需求功能需要定制化的企业，可以采用我们公司自研的企业级低代码平台：织信Informat。 织信平台基于数据模型优先的设计理念，提供大量标准化的组件，内置AI助手、组件设计器、自动化（图形化编程）、脚本、工作流引擎（BPMN2.0）、自定义API、表单设计器、权限、仪表盘等功能，能帮助企业构建高度复杂核心的数字化系统。如ERP、MES、CRM、PLM、SCM、WMS、项目管理、流程管理等多个应用场景，全面助力企业落地国产化/信息化/数字化转型战略目标。 版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们微信：Informat_5 处理，核实后本网站将在24小时内删除。