高效需求评审:需要用点“小心思”

来源:人人都是产品经理

2146

0

编辑导语:对产品经理来说,需求评审是一个必须经历的过程。只要工作还在进行,需求还在不断产生,需求评审就要存在。如何高效完成需求评审?这个问题需要在一次次会议中总结经验,也需要用点“小心思”。

开会是产品经理工作中最常见的事情了,比如需求讨论、方案评审、用例评审、项目复盘等等。当你经历了各种会议,相信你一定有所感触。

有的会议高效快捷,有的会议却让人失望,不仅会议频频延时、跑题、还充斥着会而不议、议而不决、决而不行……正确高效的开会是执行能力、表达能力的直观体现,也是职场人的必修课。如何把会议开好却不是件容易的事,需要我们花点小心思~

本文以需求评审会为例,通过会前组织、会中讨论、会后跟进分别来讲解各环节的注意事项。

一、请正视需求评审

当产品经理将需求转化成PRD文档输出后,眼见着就要进入研发阶段了,但是在交付前还需要再把把关。需求评审是向相关方讲解需求解决方案的过程,也是寻找方案漏洞和获取多方认可的过程。

评审会议需要完成3个小任务:

  1. 描述需求场景:让相关人员了解需求具体的应用场景,以及需求实现目标和预期获取到的价值是什么。
  2. 讲解实现方法:阐明解决方案的功能模块、实现逻辑、功能操作等内容,需要研发等人员达成共识。
  3. 确认工时排期:和下游确认对应工作的具体任务和交付时间。

涉及范围较广的需求解决方案一般会经过多轮评审,毕竟经过多次风雨洗礼的方案才会更加“完美”。一稿过的方案除了个人需要准备充分和专业过硬,也需要团队配合度+1。

当我们了解了需求评审的意义和目的,接下来看看在会议中我们应该怎么做。

高效需求评审:需要用点“小心思”

二、会前:准备你的武器

相信大家都有组织过会议的经验,会前准备工作并不复杂,但是随着会议涉及的部门和人员增多,会前协调工作就显得十分重要。

事先准备没有做好,会议基本就垮了……先看个案例,再看下会前准备事项。最近参加过最离谱的会议是ZQ集团召开的跨组织会议,会与方包含ZQ集团软件部和项目相关的5家供应商公司。

通知参会时主题是“LW工厂仓储软件对接会议”,会上沟通的却是业务实施流程相关内容,完全的文不对题。耗时一天,几无收获,造成项目进程暂停和多方资源的浪费。

1. 明确会议主题

大家都很忙,所以会议主题、议题、要达成的结果都需要明确并提前告知。以上述例子为戒,受影响的不仅是进度和资源,也会影响组织人员的人品值。

如果人品值的分数过低,影响的不仅是会议组织,其他工作也很难在团队内开展。

2. 准备会议资料

需求评审会议用到的需求文档、原型等资料需要提前准备并整理完成。会上不能只凭一张嘴,其他让大家会上自己意会。

3. 确认人员时间

人员和时间是会议的基本要素,只有确认好后才能发出会议邀请。

  • 与会人员:需求评审的人员一般包含UI、研发(前后端、移动端)、测试、运营,根据需求涉及的范围,其他相关人员也需要参会。
  • 会议时间:随着人员增多,每个人都有自己的事情,这时时间就较难协调。我们先和核心干系人确认出席时间,再协调其他人员时间。

4. 多种渠道通知

会议邀请一般会通过邮件和微信进行分别通知。邮件通知正式且便于后续事件追溯,但关注度不够。所以邮件通知后,会在微信上再次提醒干系人。

  1. 邮件会议邀请注意附上会议资料并对重点标注说明,好让会与人员提前了解信息,如何编写不在此展开。
  2. 会议当天或会议开始前1小时再次微信提醒相关与会人员,避免忙于其他事情导致忘记参会。

5. 先小范围讨论

会议通知前,产品经理先和核心干系人沟通需求评审的事项(如研发对接人),提前消灭大问题,避免会上出现重大事故。

三、会中:注意控制场面

需求评审的场面往往比较激烈,通常大家都会从各自的角度提出各种问题让产品经理来解答。那怎么做才能提高会议的效率和质量,让大家愉快的开个会呢?看过下面的案例,也许就知道该这么做了。

在某次需求评审会上,PM把功能操作逻辑讲解十分清楚,但是研发不理解功能的应用场景;系统操作的步骤是否过于复杂反复讨论;针对某功能实现方式PM和研发争论不止;研发非常认真的要对每个字段的限制都要扣明白……

1. 围绕主题讨论

围绕预设的主题讨论是保障会议效率和质量的前提之一。会议中我们要及时识别当前话题是否还在制定的议题中,如果超出范围,我们需要及时引导回来。针对延伸的话题可以先行记录,在会后再组织相关人员进行讨论。

2. 按照顺序讲解

需求评审一般会跟着PRD的顺序进行讲解,最忌讳一上来就说功能操作,会让人莫名其妙。讲解顺序应当是从概要到详细,层层推进。

顺序参考:需求背景 、方案概述、收益和风险、用户与需求、产品框架、功能模块、操作流程、原型交互、数据指标、所需支持、预期上线时间。

3. 控制会议节奏

会议时间有限,必须有序的推进会议进程,避免单个问题上占用过多的时间。针对讨论的问题分清轻重缓急,做到“抓大放小”,在细节上不做过多的争论。

如果主流程上出现问题,说明产品没做好准备。此处体现了会前小范围讨论的重要性。讨论的场面可能很热烈,最后必须有确定性的结论,不要光说的热闹,最后议而不决(主题外问题先记录,不做过多讨论)。

4. 做好会议记录

好记性不如烂笔头,会议可能长达1~2小时,为了避免会后相关问题的遗漏,一定要及时记录讨论重点。如果来不及写,录音是必要的补充措施。会议记录是针对已确认、待确认、待讨论的关键内容记录,同时标记对应事项的跟进人员和执行时间。只有如此才可能避免“决而不行”。

四、会后:跟进跟进跟进

会上聊的再热闹,会后没有执行等于白说。所以会后的跟进是第一要务。要做哪几件事情呢?先欣赏一个失败的案例吧……

某次需求评审会,经过会上激烈的讨论确认了解决方案调整项若干和待办事项若干,并且会上指定了对应任务的负责人,然后大家心满意足的就散会了,之后各忙各的。两周后再问进度的时候发现进度远低于预期……

1. 发布会议纪要

会议讨论的事项想要落实,首先要做的是将会议记录整理并发布。

  1. 整理的内容包含具体事项、交付物、跟进人、执行时间、完成时间等信息。明确了这些事情才变得可跟进。
  2. 通知的人员不仅是与会人员,未参会的相关干系人也要通知到。

2. 相关事项跟进

需求评审不论是否通过都会根据结论进行下一步的安排。评审通过就跟进上线的排期和进度;评审未通过就及时调整并约定下次会议时间。跟进进度的方式可以采用日报、周报、站会、约定时间等多种方式进行。但是千万不要一直催进度,体现了对对方的不信任,容易让人反感。

3. 需求文档更新

会议中涉及需求文档的修改点,在调整后及时更新和通知相关人。再视实际情况组织会议讨论。需要注意一点——会议中一旦确定的事项,除非有颠覆性的影响因素介入,否则不允许修改。否则会议就变得毫无意义。

以上就是组织一场需求评审会需要注意的事项。希望你能开一个高效、愉快的会议~

 

本文由 @耳目不染 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!

关键词: 产品经理

精彩评论文明上网理性发言,请遵守评论服务协议

共0条评论
加载更多