需求评审的流程

什么是需求评审

简单都说就是让干系人提前了解产品。

在这之中需要向他人传达产品的设计背景,自己的设计理念,产品的业务逻辑等

需求评审不是一轮就可以结束的事情,可能有产品内部需求评审,技术需求评审,相关业务线评审。

面对不同的评审环节,可能有不同的评审重点中,但是评审的准备工作和评审的重点都是一致的。

评审前需要做什么

评审前需要做好充分的准备工作,一句话说的好:“文档准备不充分,需求评审等于直播吃翔”。

在直播吃翔之前,需要准备好产品的必备文档比如:

  • 业务流程图、页面流程图
  • 信息结构图、功能结构图
  • 产品原型
  • 产品需求文档

同时要注意文档细节,不然在评审过程中会陷入不休止的讨论细节中,无异于直播吃虫子。

如:

  • 不要有错别字
  • 文档格式保持统一
  • 文档的字段命名规范
  • 文档里面的例子要恰当

评审时需要怎么做

在需求评审的开始阶段,首要讲解的不是具体的需求设计结果和功能点,而是要让参与评审的相关人员先明确需求产生的背景。要让大家知道需求产生的来龙去脉,这有助于大家建立初步的认知。从用户那边收集过来的,老板提出来的,业务部门提出来的,还是产品经理团队自己发掘出来的,以及需求产生的过程。

其次要让大家知道需求实现的价值,这时更多都是预估的,若有相关的数据分析支撑,会更有说服力。价值能够量化的情况下尽量量化,用相对科学的方式去计算预估。不能量化的情况则需要定性的描述,把实现的目标和完成的标志说明清楚,这样大家就清楚的知道去实现的意义,价值越大,实现的必要性越高。

按模块简单介绍一下产品的功能模块,不要写入细节。只是让参会人员现有一个概念,产品的结构和事怎么样,有什么样的一个优先级。

按场景简述产品的主要流程。一般先讲总体,再讲重要细节,再讲次重要细节,并层层确认。比如订单支付流程,先讲解支付顺利的主流程,再讲解支付失败的异常流程。

接下来才是产品的原型内容和交互文档。

对于会议上争议较大的问题点,有个「5分钟原则」,5分钟后还没有结论,就记录下来,会后再单独讨论。如果问题点太多,就说明产品经理还没考虑清楚,那就尽早结束会议,再重新修改原型,再召开一次会议,当然我们还是希望这样的情况不要发生,因为非常浪费时间和精力

评审后还需要干什么

整理遗留问题,并拿出解决方案;
发出会议记录,使每个问题都有具体行动计划;
发出修改后的需求文档,并更新到内部系统中;
如有需要可约下一次的评审时间。

推荐阅读:

好的需求评审流程该怎么走?

The Why·Liam·Blog by WhyLiam is licensed under a Creative Commons BY-NC-ND 4.0 International License.

WhyLiam创作并维护的Why·Liam·Blog采用创作共用保留署名-非商业-禁止演绎4.0国际许可证

本文首发于Why·Liam·Blog (https://blog.naaln.com),版权所有,侵权必究。

本文永久链接:https://blog.naaln.com/2019/06/requirement-review/

如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!