产品小白不迷路06：怎么“完好”的从需求评审走出来？

需求评审是每个产品经理都需要修炼的技能，只要工作还在进行、业务还在继续、需求还没消失，那就一定会存在需求评审。

在需求评审会议上，前端、后端、测试、设计、业务负责人甚至你的老板可能都会过来，不同的角色聚在一起，听产品经理讲需求内容。这不是一件容易的事情，因为你需要经得起各个角色对你的产品设计的质疑或挑战，怎么“完好”的从需求评审走出来，对每一个产品经理来说，都需要去仔细琢磨，也是必须得掌握的基本功。

一、需求评审会前准备

进行需求评审前，有几个动作是需要做的：

1. 需求评审需要用到的资料，包括但不限于：PRD、原型、流程图、设计稿、相关资料文档、需求时间计划等。
2. 需求评审干系人：确定需要参与会议的人员，例如，业务对接人、前端、后端、测试、设计等。特别是业务对接人，参与会议可以让业务更了解他们提出的需求是怎么被实现的，提交给到开发其实需要需求描述到什么程度；另一方面，技术也可以通过业务对接人了解到更多业务场景，对需求实现有更深的理解。确保干系人都参与到会议，避免需求评审时相关人员不知情导致需要再次沟通或者需求实现偏移。
3. 需求评审时间地点：因为涉及到的与会人员多，所以需要沟通好会议时间地点，如果是常规迭代，最好是约定一个相对固定的时间，例如每周几或者每月几号这样，让团队人员避开会议时间安排其他会议。通知方式根据实际公司情况而定，例如邮件、微信群、企业微信、钉钉、内部通讯工具等。像钉钉、企微这种协同办公软件有会议通知提醒功能，能更好的提醒到与会人员。

二、需求评审会中

作为需求评审会的主持人，第一，要清晰明确产品需求讲解；第二，要把控整个会议的节奏。

需求评审需要大家达成共识并按照产品设计的实现它，简单来说就是明确：价值、功能、实现。

• 价值（背景/目的）：为什么要做这个需求，上线之后的价值是什么。
• 功能（涉及产品、端、功能模块）：为了这个价值，需求包含了哪些功能。
• 实现：针对每一个功能，应该怎么实现。

例如需求为：运营部门需要发布促销活动在网站上客户可选择促销活动下单。

第一步：产品经理在进行需求评审时，就需要把这个需求的价值（或背景目的）先说明清楚，即本次需求的目的是促使客户下单，提高销售效率。

这一步其实很重要，很多时候，技术对产品的不信任在于觉得产品提出的需求可能是伪需求，并非业务关注的，所以有必要在评审会上说明每个需求的来源和价值，证明我们是想清楚了才这样设计功能的。

第二步：把需求价值同步后，就需要说明功能。

可先讲解需求的业务流程，让参与会议的人知道功能涉及哪些角色、哪些系统、数据流是怎样的，做的心里有底，这个需求的范围大小。然后，讲解涉及到的单据状态是怎么流向的。如果是复杂的功能，还需要有相关的表关系图辅助技术理解。

这一步的重点在于，需要大家对流程先达成共识，如果大家对流程有疑问，需要及时沟通，否则后续说明实现时就会一团乱。

第三步：功能具体是如何实现的。这里可以根据个人习惯进行讲解，这里介绍的是我自己的讲解习惯，仅供参考。

流程 模块

说实话，对着PRD或者原型讲解，很容易走神，不知道讲到哪里了，效果不佳，还容易被技术吐槽。

所以我采用的是流程 模块的方式进行讲解。在上一步，我们已经将流程说明了，也共识了流程，那我接下来的功能实现就是按照流程一步一步讲解。

例如：发布促销活动先进入促销管理的页面，进行新建促销活动。那第一个节点模块就是促销管理的入口-》到进入促销管理模块中的促销列表页-》新增页面-》编辑页面-》详情页面的顺序来讲解实现。

• 在讲解实现过程中，与会人员会对刚刚的产品设计进行提问，甚至是多个不同角色针对不同方面进行提问。能提问是好事，证明大家是认真听了并思考了，通常我在讲解完模块实现后都会问一句：有没有问题？没有我们继续。以此来保证大家进度。
• 但我们开会的时间是有限的，就需要判断哪些问题需要当场解决，哪些问题可会后补充。个人建议，如果存在以下条件的，就应该当场解决，也因干系人都在，这时候解决效率最高：
  1. 关于项目价值目的，为什么要这样做。例如：促销活动详情为什么还需要查看关联的订单情况？因为做促销活动的目的就是反应在最后的下单情况上。
  2. 关于业务流程/逻辑完整性，这个问题不解决，业务进行不下去。例如：业务需要发布了活动才生效还是设置的开始时间到了自动生效。
  3. 影响到其他系统或功能模块的。
• 而那些不影响主流程功能问题，比如前端细节，交互细节，后端逻辑细节，或者是你还不确定的点，如果会上不能快递确定解决的，身为会议主持人，应该把控时间节奏，在PRD文档上标注即可，会后沟通确认。

需求评审会议时长最后把控在1小时内，因为时间长了，我们的精力和注意力都会打折扣，想象一下一群人在会议室超过1个小时，里面的二氧化碳浓度也让你浑浑噩噩，俗称缺氧。

需求评审的目的：需求评审不是解决所有的问题，而是在会议时间里解决最重要的问题。检验需求的合理性和完整性，降低需求风险，确保项目目标和需求之间的一致性，便于团队成员理解工作任务。

做到这一步，其实已经可以卸下大半的压力，离“完好”走出还差最后一步。

第四步：需求时间计划同步

在完成需求实现说明后，大家最关心的就是什么时候需要完成开发、提交验收、上线等。因为这关乎工作量的评估和时间的紧迫性。

这时候，如果是新功能或者关键功能重构优化，建议技术部门提供技术方案，以此完善整个需求文档，同时验证产品设计是否有技术实现的问题。

三、需求评审会后跟进

会议结束后，当我们“完好”走出需求评审会，其实还需要对会议记录进行整理，更新需求文档，并通知相关团队成员，才算真正的结算。

四、总结

通过需求评审，可以对产品需求进行全方位的论证，验证或更改原有想法，获取更多的想法，从而完善产品需求。

所以说，虽然在需求评审会上产品经理看似单兵作战，其实我们跟会议上的人是合作关系，相互补充，为了让产品需求更合理更明确。切勿有个人情绪，应当对事不对人。

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！