目标：降低风险&提升效率
一场好的需求评审能够帮助我们很好地管理需求方的预期，同时也能通过一次次评审和纠偏，帮助整个产研团队就需求场景和优先级达成一致，及早进行风险评估及查缺补漏，有效提升团队开发效率和产品可用性，降低需求变更带来的风险。
对于前端开发人员来说，做好需求评审可以帮助我们更好地理解业务和需求，还可以锻炼出对业务的一整套分析能力实现技术与业务共赢。
方法：做好评审拒当工具人
需求评审前：理解需求&评估风险
重要：参加需求评审前请先花点时间阅读需求文档！！！
需求评审最重要的阶段就是在于需求评审前，做些准备工作是必要的，不要一脸懵地去参加需求评审。这包括阅读需求文档、与产品经理及团队成员沟通，确保自己对需求有一个清晰的认识。
关注需求背景：先思考原因，而不是先思考实现
在需求评审之前，前端开发人员需要充分了解需求的背景。技术人员容易犯的方向性错误是一开始就陷在需求的具体解决方案中。
思考需求：要解决什么问题？要解决谁的问题？要解决成什么样（实现什么目标/获得什么结果）？
| 关注点 | 策略 |
|---|---|
| 项目背景 | 功能的用户是谁？通常在什么场景下使用？当前在这个场景下遇到了什么困难？ |
| 评估必要性 | 思考：如果不做会怎么样？保持现状有啥问题？ |
| 评估合理性 | 合理的目标追求事前可证明or事后可度量，大方向上没跑偏，小方向上有收益 |
充分了解需求：不要默认产品的方案就是最优解
需求的合理性论述通过后需要考虑产品方案的合理性，即了解我们的功能是怎样帮助用户解决问题的？
这个阶段有两个核心点，一个是流程，一个是功能点。流程包含了业务流转以及状态变化，功能点包含所有需要做的功能。
| 关注点 | 策略 |
|---|---|
| 流程 | 流程设计的是否完善，流程能否闭环？ |
| 功能点 | 功能点是否都是必要的？能否从技术角度补充改进方案，乃至给出更优解？ |
| 完整性&一致性 | 是否有遗漏或冲突的地方(描述不清醒/流程不完整)？ |
| 产品方案通用性 | 是否有更通用的实现方式？维护成本有多高？ |
| 方案复杂性 | 对复杂的产品方案：未来的变动可能性有多大？发生后的处理成本有多大？ |
技术评估：有效的经验来自对需求的分类与建模
在了解需求的基础上，前端开发人员需要评估需求的实现难度和风险。
| 关注点 | 策略 |
|---|---|
| 技术选型 | 根据项目需求，选择合适的前端框架、库、工具等 |
| 技术难点 | 分析需求中的技术难点，如新技术的学习成本、性能优化、兼容性处理等，并提前准备解决方案 |
| 技术风险 | 评估需求实现过程中可能遇到的技术风险，如第三方库的稳定性安全性等 |
| 依赖关系 | 如果不能搞清楚所有的依赖，以及这些依赖是否可用、能否及时就位，那么排期就是不可靠的 |
| 风险点 | 识别需求中的潜在风险点，如性能瓶颈、安全隐患等，并提前制定应对措施，如果需要做好技术方案的预研工作 |
| 开发周期 | 根据需求的复杂程度和自己的开发经验，预估完成需求所需的时间 |
思考前端业务开发究竟有哪些类型的需求？每一类需要注意什么？在项目中更加主动一些，可以按照你觉得最合理的方式设计技术方案，也可以在项目中落地一些你想推动的技术方案，有业务结果的同时也能有技术产出。
需求评审过程中：提问题&落实到文档
需求评审的时候，产品经理会先介绍需求的背景以及需求的目标，然后就是正式评审需求内容，我们在参与需求评审时需要仔细听，并且做到：
敢于提出问题&建议
| 节点 | 策略 |
|---|---|
| 评审前准备的 | 1. 需求不合理的地方以及和目标不匹配的地方； 2. 需求不合理的地方以及和目标不匹配的地方； 3. 功能点有遗漏或冲突的地方(逻辑、交互、视觉等等)；4. 给出更通用的实现方式（标准组件、通用解决方案等等）；5. 对复杂的逻辑和方案提出疑问给出建议； 6.技术难度&风险同步 |
| 评审过程中 | 1. 有不了解的地方或者没有听懂的点，在需求评审的时候提问； 2. 听听其他人的提问和建议，不懂的点也可以提出问题； 3. 需求的依赖是否可用，何时就位； 4. 避免陷入细节陷阱，对于不影响主流程和大方向的细节问题不要占用过多时间讨论，会后确认清楚落实到文档 |
评审的内容，需求文档里必须体现
在需求评审会上提到的任何改动，都需要在需求文档里体现，因为需求文档会关系到后续技术方案设计以及具体的技术逻辑实现，特别是一些边界情况。清晰的需求文档也方便后面回溯和复盘，防止因为需求评审和具体功能实现之间存在差异导致误会发生。
| 关注点 | 策略 |
|---|---|
| 需要落实的点 | 1. 需求内容中考虑不全的地方，需要变更的地方； 2.需要不在场的人员会后确认的细节； 3. 确认事项的 action，跟进人和 deadline |
项目研发相关流程符合规范
| 关注点 | 策略 |
|---|---|
| 需要落实的点 | 1. 明确项目研发相关的信息，比如团队角色情况，里程碑等等 |
需求评审后：技术方案&排期
- 需求评审之后，按照需求内容设计技术方案
- 确认需求的优先级，然后进行排期
- 任务分解：将需求分解为具体的开发任务，明确每个任务的输入、输出、负责人等
实践：从前端专业角度发现问题提出问题
针对需求背景的提问
- 本次需求的主要用户是谁（管理者、全体员工、hr、财务等等）？
- 主要是解决什么问题？要达到什么目标？预计会有什么收益？
这些问题可以在会前跟产品进行沟通，作为前端开发人员还是需要了解你做的需求最终的目标和价值
针对产品方案的提问
-
关注UI交互细节
- 非标组件要细节：非标准组件(或标准组件未实现的功能点)需要特别关注，是否可以用标准组件代替，如果不能需要详细的设计、交互说明
- 复杂交互要合理：需要给出原型图、交互图，详细的文字说明
- 静态图片要说明：文档中出现的截图要有详细的文字说明
- 异步交互要可控：接口等待如何展示，接口调用成功后给出适当提示展示下一步状态，接口调用失败给出错误提示和界面展示说明，接口调用时做好防抖
- 表单输入要校验：输入框可以输入多少字数，是否必填，字符串格式等等
-
关注流程设计
- 业务流程要闭环：对于涉及到业务流程的需求最好能有流程图：每个流程要有开始节点和结束节点，对于可能出现的分岔点每条路径的判断条件和走向如何，最终能否到达结束点
-
关注异常场景
- 异常 提示要清晰：操作失败的提示语要准确及时，无数据状态展示要有说明
- 误操作场景要可控：对于用户的误操作，提供二次确认或者撤销的功能，提高用户的操作可控性
-
关注视觉风格
- 视觉交互要统一： 最好可以参考相关模版
- 无设计稿时要确认：对于没有设计稿的原型图需要确认最终UI需要实现成什么样
-
关注边界问题
- 数据量：内容超长溢出的处理，数据量过大增加必要查询条件
- 端适配：浏览器（版本）、操作系统
- 响应式：屏幕大小如何兼容
总结
严谨对待每一个需求，站在产品和业务的角度考虑目标和价值，站在技术的角度考虑可行性和 ROI，争取做到每一个需求都不是白忙活。
