好的需求评审流程该怎么走?
在产品落地开疆扩土前进上,需求评审就是产品人开荒的第一步!
搞产品的人都会经历过无数次的挑刺,无数次的评审!
当大家对于产品提出一道道质疑时,这时候就要以专业的只是说服沟通他们!
很多产品人更多层面是在会议之前准备的不够充分,从而导致会议效率低下,甚至于需要好几次才能通过!
(需求评审会议的意义再次就不做讨论了,你们懂得!)
在召开会议前,内心要清楚的知道本次会议参与的人员类型,各自大概的需求点?
好了,开始直奔主题内容,说说好的需求评审流程该怎么走?
按照会议的流程来说,可以划分为 “会议前”,“会议中”,“会议后”这三大环节。
一、会议前
会议召开前
在会议召开之前,应提前准备好相关的内容,以及常见问题的应对措施。
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 授权发布于人人都是产品经理,未经作者许可,禁止转载。
低保真流程
收藏了!
不错不错。挺齐全,收藏了。
文中的图片内容是用什么工具做的,
visio 跨职能流程图可以画
错别字太多+1
写的很全面也写的很理想
以后开会就按这个流程走,先把主线的工作处理完,其他的再开细会决定。
调理清楚,但实施起来有点恼火
刚开完会,正好!
然后我再个人中心里查看我的评论时,别人给我的评论怎么看不到了?我自己的评论也只是显示一条别的去哪了?虽然能评论“评论”但是怎么看不见了?这是BUG嘛?能盖楼但是我看不见怎么回事?
评论的字数没有限制吗?
这个APP做的不错,哪个产品经理?😄
整体还不错,收藏了
错别字太多!
好
好
我自己评论自己怎么不能显示呢?
大沙发发散度
写的挺全的!
挺全的,攒
很全面,一般都是按照这个流程走,有的会更简化一些
需求评审就需要 原型、prd这些了?
请教下,您觉得还需要什么内容?
【原型,交互稿,流程图,功能列表,流程图,PPT,PRD等,这些不能满足会议的沟通需要!】
点赞
非常完整的工作流程以及细节解剖。但是如果把需求评审作为一个产品,我建议砍掉5成以上的功能点。
说的没错,其实自始至终贯彻主线:【1、真的需要开会? 2、开会是为了什么? 3、会议想要达到什么结果】!
这应该是项目原型评审了。如果是部分功能的需求评审,是应该在会前就应该各方先前就讨论并达成一致的,可以节约很多没必要的讨论时间。
说的没错,会议之前 就应该明确 “真的需要进行开会?”,“哪些不清晰不明确的的?”!接下来才会在评审这一步!
我觉得即使需求评审阶段,你把什么原型都做好了。万一这个需求是不符合或者是推迟做的,感觉就有点浪费时间。个人认为流程以及原型是在评审通过过后,进去需求打包的时候再去做比较合理。
说的没错,不同的团队会有不同的业务模式,
这时候,还是要回归到基点上
【真的需要开会才能解决嘛】【需求真的清晰明确,方向正确嘛?】
项目经理在哪里,产品兼任了吗?
往小的说:
小公司,一般来说是产品兼顾项目来的!
大公司,才有这方面的,这时候,产品只需要关注时间节点跟优先级即可!
往大的说:
心中定调一个基点:从需求的产生到落地,产品应该进行推进!
Voilà c‘est ça
思维清晰,不错,支持下
如果是大的功能或产品,在第一次评审研发就能当场评估初步的工期?
1、其实这块跟团队合作密切相关,责任人对自己负责的环节是否有个清晰的认知了解!以及愿意真正投入进去!
2、第一次评估不准,项目有延期,那下一次的评估呢?再下一次呢? 那能否结合以往的经历加上对需求的理解进行评估
3、以前我在一本书看到有这种预估方式: 最好,最差,最适中
(这个点最好的话需要多久,最差的需要多久,一般情况下的需要多久,然后三者相加,再乘以 三分之二)
得出来的数值基本上相差无几!
【不过还是推荐第一点】
赞,第三种方式,对于新团队、新产品的第一个版本的评估应该比较有帮助。并不是说团队的能力不行,评估不准确,但确实往往过程中会有很多变数出现。
确定是乘以三分之二吗?
逻辑整理得非常清晰,不过我觉得,在会议前其实就应该跟与会各方就需求达成一致了,不是全部都要在会上去讨论,会上只是做最后的确认工作,这样会更高效~
说的没错,回归到基点上
【真的需要开会才能解决嘛】【需求真的清晰明确,方向正确嘛?】
这样才能找到一个适合自己团队的流程作风!
非常赞同。否则需求评审会的持续时间将会十分恐怖
ptt是什么?
hh,我就是来看看有没有和我有一样疑问的
应该是打错了
看的过程没发现,当成PPT
没错,真的是打错了,是PPT来的!