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

48 评论 65030 浏览 981 收藏 9 分钟

在产品落地开疆扩土前进上,需求评审就是产品人开荒的第一步!

搞产品的人都会经历过无数次的挑刺,无数次的评审!

当大家对于产品提出一道道质疑时,这时候就要以专业的只是说服沟通他们!

很多产品人更多层面是在会议之前准备的不够充分,从而导致会议效率低下,甚至于需要好几次才能通过!

(需求评审会议的意义再次就不做讨论了,你们懂得!)

在召开会议前,内心要清楚的知道本次会议参与的人员类型,各自大概的需求点?

好了,开始直奔主题内容,说说好的需求评审流程该怎么走?

按照会议的流程来说,可以划分为 “会议前”,“会议中”,“会议后”这三大环节。

一、会议前

会议召开前

在会议召开之前,应提前准备好相关的内容,以及常见问题的应对措施。

1、了解会议目的

  • 统一思想,了解需求意义
  • 明确需求具体涉及范围
  • 确定事项落实工期与责任
  • 确定开展工作

你要清晰的知道为什么要召开这次会议。

2、提前准备好资料

需准备好相关的原型,交互设计稿,流程图,功能概要列表,PTT,PRD等,并在提前发送到环节涉及所有人。

3、提前通知责任人

  • 除了正式渠道(如邮件,群等),还需再次口头告知确认,
  • 通知内容需包含:需求资料,参会人员,会议内容主题,需要配合资源内容

4、备好问题速救药

产品内部自行检查好:一般保证这几方面:(确定性,完整性,复杂性,熟悉性,稳定性,交互性

  • 确定要这么做?这么做会*,考虑清楚要这么做?
  • 还有这种情况你没考虑到?
  • 这个搞的话,太复杂了,能简单点不?
  • 你要动这一块,有没有考虑到现有的流程?
  • 确定定稿这些内容了,会不会再出现变化?
  • 这个交互为什么要这样,主要的是这样?

划重点来了,在对接研发人员,他们要的不是你懂技术,要的是你不要改需求!

二、会议中

会议召开中

准备好相关的资料后,也提前通知责任人了,终于可以开始了。

1、召集小伙伴开会咯

时间点到了后,要及时拉上所有相关人员,由于人都有拖延懒惰的特点,记得在开会10分钟就要喊上他们,保证会议准时进行

2、讲解前应先说说本次会议的内容范围

相关涉及责任人到会议室后,应在开会前明确表明确认:

本次会议目的,会议涉及内容,会议所需结果

(不要一上来就直接讲原型!)

3、记得做好会议记录

除了记录常规的会议内容之外,还需要重点记录核心争议讨论点,以及讨论结果

4、有争论不可怕,可怕的是方向偏,无效率

  • 在讨论需求之前,要明确争论基点,不能无休止讨论,也不能啥也不说
  • 出现争论是好事,证明哪些人有在看,有在听
  • 会前一定要保证主流程,主方向,主内容OK没问题
  • 非常细的内容,不涉及主流程环节下,建议会后解决
  • 主流程环节出现争论,一定要在会议解决掉
  • 不宜在会议争论太长时间在工期环节
  • 明确本次开会目标,不宜偏题讨论

5、终于可以开始好好的讲解需求了

讲解答疑环节中应讲究条理性与节奏。

  • 需求背景:概述需求从哪来,为何要做这块,
  • 用户与需求概述:描述需求应该要做成什么样,
  • 功能模块:需求涉及相关的重点大的功能点,
  • 简要优先级:描述下当前的最重点内容,
  • 流程讲解:讲解本次需求涉及主要流程,
  • 原型与交互:开始讲解原型内容和交互,
  • 数据指标:讲解本次需要哪些关键性的指标;

6、需要各各环节的配合

明确落实本次需求需要哪些人,哪些资源进行配合!

比如:需要运营协助处理文案;需要开发协助技术实现,需要行政协助开设激励奖等

7、总结概括本次会议内容

  • 讲解沟通完成之后,应再次复述总体需求内容
  • 咨询确认是否了解当前整个需求内容

8、责任人复述确认

  • 让相关责任人简要复述确认理解层面是否一致
  • 明确了解需求内容为判断依据
  • 是否签字画押确认由各自环境决定

9、争吵时间节点(工期与上线)

讲解沟通完毕后,就进行相关的初步定稿评估工期时间,以及告知计划上线时间;(会议定稿初步工期,部分争议则私下解决!)

三、会议后

会议召开后

终于熬过挑刺环节了,距离落地执行没多远了,可工作还有这些:

1、整理会议纪要内容

会议结束后,应当天总结处理会议上所有讨论的争议点,以及讨论的结果内容!

2、是否需要进行调整

立马处理在会议上未能讨论解决的内容:

  • 应尽快确认是否应该调整?调整的范围是多少?
  • 并且及时反馈告知处理结果。

3、是否需要再次召开

会议结束后,是否需要再次召开会议,讨论内容,

以落地责任人了解程度为判断依据!

4、发送会议记录

会议结束后,当天内应及时通过正式渠道发布会议纪要。

  • 会议讨论设计内容
  • 争议点及其处理内容
  • 初步定稿时间与责任人

5、落实明确行动计划

会议定稿后,应推动落实需求前进

再次确定定稿内容时间节点!

6、任务排期

内容/节点定稿后,则落实到具体的排期,开始项目跟进!

7、定稿内容发送

定稿确认之后,应正式发布通知相关责任人:

  • 会议最终结果(排期,时间节点等)
  • 本次涉及内容(有哪些内容,做到啥程度等)
  • 需要谁进行配合,感谢哪些支持等等

温馨提示:至始至终,要明确你开会是为了什么,想要什么结果!

终于可以安心了,任务开始徐徐前进了,可接下来的工作还不少,还要继续开撕!
——来自永远不定期断更的 youketao

==(关于需求评审质疑,如何有效的沟通,再说了!)==

 

作者:youketao

来源:http://www.jianshu.com/p/fda0c4887f4d

本文由 @youketao 授权发布于人人都是产品经理,未经作者许可,禁止转载。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 低保真流程

    回复
  2. 收藏了!

    来自山东 回复
  3. 不错不错。挺齐全,收藏了。

    来自福建 回复
  4. 文中的图片内容是用什么工具做的,

    来自广东 回复
    1. visio 跨职能流程图可以画

      来自广东 回复
  5. 错别字太多+1

    来自福建 回复
  6. 写的很全面也写的很理想

    来自北京 回复
  7. 以后开会就按这个流程走,先把主线的工作处理完,其他的再开细会决定。

    来自广东 回复
  8. 调理清楚,但实施起来有点恼火

    来自四川 回复
  9. 刚开完会,正好!

    回复
  10. 然后我再个人中心里查看我的评论时,别人给我的评论怎么看不到了?我自己的评论也只是显示一条别的去哪了?虽然能评论“评论”但是怎么看不见了?这是BUG嘛?能盖楼但是我看不见怎么回事?

    来自辽宁 回复
  11. 评论的字数没有限制吗?

    来自辽宁 回复
  12. 这个APP做的不错,哪个产品经理?😄

    回复
  13. 整体还不错,收藏了

    回复
  14. 错别字太多!

    回复
  15. :mrgreen:

    来自辽宁 回复
    1. 来自辽宁 回复
    2. 来自辽宁 回复
    3. 我自己评论自己怎么不能显示呢?

      来自辽宁 回复
    4. 大沙发发散度

      来自辽宁 回复
  16. 写的挺全的!

    回复
  17. 挺全的,攒

    回复
  18. 很全面,一般都是按照这个流程走,有的会更简化一些

    来自广东 回复
  19. 需求评审就需要 原型、prd这些了?

    回复
    1. 请教下,您觉得还需要什么内容?
      【原型,交互稿,流程图,功能列表,流程图,PPT,PRD等,这些不能满足会议的沟通需要!】

      来自广东 回复
  20. 点赞

    回复
  21. 非常完整的工作流程以及细节解剖。但是如果把需求评审作为一个产品,我建议砍掉5成以上的功能点。

    来自北京 回复
    1. 说的没错,其实自始至终贯彻主线:【1、真的需要开会? 2、开会是为了什么? 3、会议想要达到什么结果】!

      来自广东 回复
  22. 这应该是项目原型评审了。如果是部分功能的需求评审,是应该在会前就应该各方先前就讨论并达成一致的,可以节约很多没必要的讨论时间。

    来自福建 回复
    1. 说的没错,会议之前 就应该明确 “真的需要进行开会?”,“哪些不清晰不明确的的?”!接下来才会在评审这一步!

      来自广东 回复
  23. 我觉得即使需求评审阶段,你把什么原型都做好了。万一这个需求是不符合或者是推迟做的,感觉就有点浪费时间。个人认为流程以及原型是在评审通过过后,进去需求打包的时候再去做比较合理。

    回复
    1. 说的没错,不同的团队会有不同的业务模式,
      这时候,还是要回归到基点上
      【真的需要开会才能解决嘛】【需求真的清晰明确,方向正确嘛?】

      来自广东 回复
  24. 项目经理在哪里,产品兼任了吗?

    回复
    1. 往小的说:
      小公司,一般来说是产品兼顾项目来的!
      大公司,才有这方面的,这时候,产品只需要关注时间节点跟优先级即可!

      往大的说:
      心中定调一个基点:从需求的产生到落地,产品应该进行推进!

      来自广东 回复
  25. Voilà c‘est ça

    回复
  26. 思维清晰,不错,支持下

    来自广东 回复
  27. 如果是大的功能或产品,在第一次评审研发就能当场评估初步的工期?

    来自广东 回复
    1. 1、其实这块跟团队合作密切相关,责任人对自己负责的环节是否有个清晰的认知了解!以及愿意真正投入进去!
      2、第一次评估不准,项目有延期,那下一次的评估呢?再下一次呢? 那能否结合以往的经历加上对需求的理解进行评估
      3、以前我在一本书看到有这种预估方式: 最好,最差,最适中
      (这个点最好的话需要多久,最差的需要多久,一般情况下的需要多久,然后三者相加,再乘以 三分之二)
      得出来的数值基本上相差无几!
      【不过还是推荐第一点】

      来自广东 回复
    2. :mrgreen: 赞,第三种方式,对于新团队、新产品的第一个版本的评估应该比较有帮助。并不是说团队的能力不行,评估不准确,但确实往往过程中会有很多变数出现。

      来自广东 回复
    3. 确定是乘以三分之二吗?

      来自浙江 回复
  28. 逻辑整理得非常清晰,不过我觉得,在会议前其实就应该跟与会各方就需求达成一致了,不是全部都要在会上去讨论,会上只是做最后的确认工作,这样会更高效~

    来自浙江 回复
    1. 说的没错,回归到基点上
      【真的需要开会才能解决嘛】【需求真的清晰明确,方向正确嘛?】
      这样才能找到一个适合自己团队的流程作风!

      来自广东 回复
    2. 非常赞同。否则需求评审会的持续时间将会十分恐怖

      来自北京 回复
  29. ptt是什么?

    来自上海 回复
    1. hh,我就是来看看有没有和我有一样疑问的

      来自北京 回复
    2. 应该是打错了

      来自北京 回复
    3. 看的过程没发现,当成PPT

      回复
    4. 没错,真的是打错了,是PPT来的!

      来自广东 回复