认识达内从这里开始

我们在前几期的文章中给大家简单介绍程序员在开发软件的时候为什么要进行需求评审等步骤，今天运城达内IT培训就给大家再来介绍一下，需求评审前中后不同阶段注意事项。

一、需求评审前

1.做好产品基本功

角色：产品经理

和业务方认真推演产品要解决的问题，深挖业务述求，相信自己的产品设计能力，业务方提供的产品方案可以作为参考，不能作为指南。

充分准备需求原型和PRD，反复推敲产品方案，确保所有的功能点都能实现闭环，正常和异常场景都要考虑。任何一个遗漏的场景，都可能成为评审会上的“雷点”，产品们需要提前扫雷。

提前找到此项目对应的技术负责人，认真的和他们沟通你的方案和想法，技术的小伙伴们不是被动的执行者，让他们参与到你的前期设计中来，驱动技术前置。

提前将完整的原型和PRD发给相关人员，以便他们提前阅读相关文档，深刻理解需求，有疑问的点提前标注出来，方便在开会的过程中积极地去参与这个会议，抛出疑问点。

2.技术人员提前介入

角色：研发、测试，建议提前2天

团队制定好规范，利用各自碎片化时间，提前介入进来理解需求。前期了解过程中除了关注功能要求，还需要关注数据类型、接口定义、性能要求、安全性等，这个根据具体业务进行评估，例如高并发场景，频繁请求的场景等。同时还需要考虑一些隐性需求。

技术负责人可以前置到需求沟通和设计阶段，给产品经理提供必要的技术支持，协助评估产品方案的可行性。

3.提前进行会议邀请

角色：产品经理，建议提前1天

给出会议时间、地点、预计需要时间。一方面，这样可以让参与人员得知你对整个需求评审会议内容的掌控;另一方面，参与人员能根据时间安排手头上的其他任务，以致于节奏不被打乱。

二、需求评审中

1.节奏把控

角色：产品经理

产品是会议主持人，那么自然就担当着会议节奏把控和主持的角色。当角色众多时，其实是比较容易出现讨论内容溢出的问题，大家一聊开就上头了，结果导致会议开了足足几个小时都还没有产生定论。需求评审中产品要做的一件事就是把控整个会议的节奏，既要及时把聊得起兴的大家拉回评审中，还要尽量按照参会人的精力去做好节奏的规划，让整场会议高效而轻松。

2.情绪管理和争论处理

角色：全员

很多产品都惧怕需求评审，感觉研发、测试在找茬，有针对自己的感觉。这个时候重要的一点，先，做好自己的情绪管理，有问题抛出是好事，说明大家都听了并且在思考。其次，换位思考，尝试先根据对方表达的看法去梳理他的思路，然后用自己的理解复述一遍，看对方是否认可你的理解。接下来，再根据你的理解去进行判断并阐述自己的观点，看是否能够得到对方的认可。后，如果实在在会上没法沟通，那就告知大家：自己会先记录下待讨论的问题，会后再进行讨论，后续的议程继续。“下来再讨论”真的是一句解决会上冲突的万能金句。

3.关注讲解方法和策略

角色：产品经理

不要上来就讲方案，大家一定会懵圈，个人总结下来，可以按照以下的步骤推进：

需求背景：传达本次需求的背景，为什么有这样的需求，解决了什么问题。

需求价值：为什么要做本次需求，做完后会给产品带来哪些价值(例如：提高用户留存、提高转化率或者是提升用户体验等)。

需求概述：需求提出方想实现什么，描述该产品方案如何解决业务述求。

方案详解：详细的进行产品方案讲解，让与会人员都充分的了解产品方案，判断是否会牵一发而动全身。建议分模块讲解，一个模块讲解完后，可以稍微停顿一会，询问大家是否有疑问，并进行答疑(如果是一个比较复杂的问题，讲解的时间比较长，可以考虑会议后单独和相关的人员进行沟通);会议中如果出现一些自己未考虑到的点，一定要记录下来，会后进行完善。

4.刻意关注、沉浸式参与到评审中

角色：研发、测试

需求评审的时候不要在会议上面玩手机或者干其他事情，因为如果需求理解不深刻，后面相关的工作就很难开展。需求中产品设计不合理、很难理解、逻辑有问题、以及可能影响原功能的地方，对于这些点我们要抛出疑问进行澄清，从而推动产品进行修改，終达成一致。

需求评审会上，前端、后端和测试分别都关注什么?

后端：

关注方案可行性的评估，重点在需求逻辑可行性、技术难度、工作量和改动成本上

关注需求逻辑的覆盖度，帮助产品经理做好逻辑的查漏补缺

关注研发过程中的实现风险

前端：

关注需求场景及业务合理性

关注页面样式交互，为产品经理提出一些更合理的样式交互建议

关注技术方案和成本评估，尤其关注新页面中交互与已有统一标准组件的评估

测试：

关注需求的逻辑性及合理性

关注需求描述的准确程度、是否排除二义性等

关注整个迭代的质量风险及进度，保证交付的稳定性

三、评审后

1.评审会议纪要

角色：产品

会议结束之后，确实可以长舒一口气，开始准备下一阶段的工作了，但注意：会后还是需要做好

会议纪要、会议同步和后续问题的跟进。会议纪要主要分为三个部分：

待讨论：指会上的遗留问题

待完善：指会上确认要改的问题，后续要完善在文档中

已确认：指会上讨论得出要做/不做的结论的点

2.待办项跟进

角色：产品+相关人员

整理会议中记录的问题，在原型和PRD中进行调整和补充，有需要的话，可以拉上相关的人员针对这些问题，进行二次评审。

好的产品一定得有项目管理能力，在整个开发过程中，一定要定期跟进开发进度，避免需求延期或者需求缺失。

另外，开发过程中，如果涉及到需求的调整.一定要在原型和PRD中标记修改记录，并且及时通知相关的人员，确保理解一致

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。