产品经理如何用好的需求评审流程开荒.docx
- 文档编号:2380251
- 上传时间:2023-05-03
- 格式:DOCX
- 页数:11
- 大小:577.38KB
产品经理如何用好的需求评审流程开荒.docx
《产品经理如何用好的需求评审流程开荒.docx》由会员分享,可在线阅读,更多相关《产品经理如何用好的需求评审流程开荒.docx(11页珍藏版)》请在冰点文库上搜索。
产品经理如何用好的需求评审流程开荒
产品经理如何用好的需求评审流程开荒
在产品落地开疆扩土前进的道路上,需求评审就是产品人开荒的第一步!
搞产品的人都会经历过无数次的挑刺,无数次的评审!
当大家对于产品提出一道道质疑时,这时候就要以专业的知识说服他们!
很多产品人更多时候在会议之前准备的不够充分,从而导致会议效率低下,甚至于需要好几次才能通过!
(需求评审会议的意义再次就不做讨论了,你们懂得!
)
在召开会议前,内心要清楚的知道本次会议参与的人员类型,各自大概的需求点?
好了,开始直奔主题内容,说说好的需求评审流程该怎么走?
按照会议的流程来说,可以划分为“会议前”,“会议中”,“会议后”这三大环节。
会议前
会议召开前
在会议召开之前,应提前准备好相关的内容,以及常见问题的应对措施。
1、了解会议目的
●统一思想,了解需求意义
●明确需求具体涉及范围
●确定事项落实工期与责任
●确定开展工作
你要清晰的知道为什么要召开这次会议。
2、提前准备好资料
需准备好相关的原型,交互设计稿,流程图,功能概要列表,PTT,PRD等,并在提前发送到环节涉及所有人。
3、提前通知责任人
●除了正式渠道(如邮件,群等),还需再次口头告知确认。
●通知内容需包含:
需求资料,参会人员,会议内容主题,需要配合资源内容等。
4、备好问题速救药
产品内部自行检查好:
一般保证这几方面:
(确定性,完整性,复杂性,熟悉性,稳定性,交互性)
●确定要这么做?
这么做会*,考虑清楚要这么做?
●还有这种情况你没考虑到?
●这个搞的话,太复杂了,能简单点不?
●你要动这一块,有没有考虑到现有的流程?
●确定定稿这些内容了,会不会再出现变化?
●这个交互为什么要这样,主要的是这样?
划重点来了,在对接研发人员,他们要的不是你懂技术,要的是你不要改需求!
会议中
会议召开中
准备好相关的资料后,也提前通知责任人了,终于可以开始了。
1、召集小伙伴开会咯
时间点到了后,要及时拉上所有相关人员,由于人都有拖延懒惰的特点,记得在开会10分钟就要喊上他们,保证会议准时进行!
2、讲解前应先说说本次会议的内容范围
相关涉及责任人到会议室后,应在开会前明确表明确认:
本次会议目的,涉及内容,会议所需结果;
(不要一上来就直接讲原型!
)
3、记得做好会议记录
除了记录常规的会议内容之外,还需要重点记录核心争议讨论点,以及讨论结果!
4、有争论不可怕,可怕的是方向偏,无效率
●在讨论需求之前,要明确争论基点,不能无休止讨论,也不能啥也不说
●出现争论是好事,证明哪些人有在看,有在听
●会前一定要保证主流程,主方向,主内容OK没问题
●非常细的内容,不涉及主流程环节下,建议会后解决
●主流程环节出现争论,一定要在会议解决掉
●不宜在会议争论太长时间在工期环节
●明确本次开会目标,不宜偏题讨论
5、终于可以开始好好的讲解需求了
讲解答疑环节中应讲究条理性与节奏。
●需求背景:
概述需求从哪来,为何要做这块
●用户与需求概述:
描述需求应该要做成什么样
●功能模块:
需求涉及相关的重点大的功能点
●简要优先级:
描述下当前的最重点内容
●流程讲解:
讲解本次需求涉及主要流程
●原型与交互:
开始讲解原型内容和交互
●数据指标:
讲解本次需要哪些关键性的指标
6、需要各各环节的配合
明确落实本次需求需要哪些人,哪些资源进行配合!
比如:
需要运营协助处理文案;需要开发协助技术实现,需要行政协助开设激励奖等
7、总结概括本次会议内容
●讲解沟通完成之后,应再次复述总体需求内容
●咨询确认是否了解当前整个需求内容
8、责任人复述确认
●让相关责任人简要复述确认理解层面是否一致
●以明确了解需求内容为判断依据
●是否签字画押确认由各自环境决定
9、争吵时间节点(工期与上线)
讲解沟通完毕后,就进行相关的初步定稿评估工期时间,以及告知计划上线时间;
(会议定稿初步工期,部分争议则私下解决!
)
会议后
会议召开后
终于熬过挑刺环节了,距离落地执行没多远了,可工作还有这些:
1、整理会议纪要内容
会议结束后,应当天总结处理会议上所有讨论的争议点,以及讨论的结果内容!
2、是否需要进行调整
立马处理在会议上未能讨论解决的内容:
●应尽快确认是否应该调整?
调整的范围是多少?
●并且及时反馈告知处理结果。
3、是否需要再次召开
会议结束后,是否需要再次召开会议,讨论内容,以落地责任人了解程度为判断依据!
4、发送会议记录
会议结束后,当天内应及时通过正式渠道发布会议纪要。
●会议讨论设计内容
●争议点及其处理内容
●初步定稿时间与责任人
5、落实明确行动计划
会议定稿后,应推动落实需求前进!
再次确定定稿内容时间节点!
6、任务排期
内容/节点定稿后,则落实到具体的排期,开始项目跟进!
7、定稿内容发送
定稿确认之后,应正式发布通知相关责任人:
●会议最终结果(排期,时间节点等)
●本次涉及内容(有哪些内容,做到啥程度等)
●需要谁进行配合,感谢哪些支持等等
希望对大家有帮助。
在产品落地开疆扩土前进的道路上,需求评审就是产品人开荒的第一步!
搞产品的人都会经历过无数次的挑刺,无数次的评审!
当大家对于产品提出一道道质疑时,这时候就要以专业的知识说服他们!
很多产品人更多时候在会议之前准备的不够充分,从而导致会议效率低下,甚至于需要好几次才能通过!
(需求评审会议的意义再次就不做讨论了,你们懂得!
)
在召开会议前,内心要清楚的知道本次会议参与的人员类型,各自大概的需求点?
好了,开始直奔主题内容,说说好的需求评审流程该怎么走?
按照会议的流程来说,可以划分为“会议前”,“会议中”,“会议后”这三大环节。
会议前
会议召开前
在会议召开之前,应提前准备好相关的内容,以及常见问题的应对措施。
1、了解会议目的
●统一思想,了解需求意义
●明确需求具体涉及范围
●确定事项落实工期与责任
●确定开展工作
你要清晰的知道为什么要召开这次会议。
2、提前准备好资料
需准备好相关的原型,交互设计稿,流程图,功能概要列表,PTT,PRD等,并在提前发送到环节涉及所有人。
3、提前通知责任人
●除了正式渠道(如邮件,群等),还需再次口头告知确认。
●通知内容需包含:
需求资料,参会人员,会议内容主题,需要配合资源内容等。
4、备好问题速救药
产品内部自行检查好:
一般保证这几方面:
(确定性,完整性,复杂性,熟悉性,稳定性,交互性)
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 产品 经理 如何 用好 需求 评审 流程 开荒