需求评审:产品经理的高光时刻
需求评审能极大锻炼产品经理的表达能力、逻辑能力、说服能力、执行力;在面对各位小伙伴的轮番diss,产品经理在那一刻得到了十足的存在感,并在一一回应各方问题后享受着那高光时刻。
什么是需求评审?
需求评审其实是PM非常讨厌的工作,因为每次做都需要耗费身心精力直到被掏空,但它又是非常重要不得不做。需求评审简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议;俗称挑刺大会,撕逼大会,逼死产品经理大会。一般评审会要经过几次,一次完成要拼“专业度”、“产品人品值”和“颜值”。需求评审过程每每都很激烈,通常会有很多类似问题逼问产品经理:
- 这样做很麻烦,开发难度很大。
- 你考虑清楚了吗?真的要这样做吗?
- 这个流程太复杂了,能不能简单点?
- 你这根本没考虑到实际情况和用户使用情况!
- 还有一种情况你没有考虑到!
在这些逼问中,如果有一个回答得不好,那场面就会非常尴尬,然后失去小伙伴们的支持。
需求评审的角色
每一种会议都会有几种角色的人员参加,评审会也不例外。
- 同行,本项目产品、配合部门的产品
- 设计,UI设计师、UE设计
- 研发,iOS,Android客户端研发、前段研发、后端研发
- 测试,QA人员
- 运营,运营推广,客服
首先需要拉上产品同事,主要是让他们参与进来,保证系统模块之间的统一性和联动性,其次是为了不让自己被“欺负”,用来壮胆的;设计师一般会挑原型的刺,但她们大多数还是会站在产品这边的,所以也有很多公司是把UI、UE并在产品部;研发同学们更多会关注流程上的细节和信息数据流的方向;测试由于岗位天性,专门debug,所以他们什么刺都会挑;最后运营会看能否达到运营目的,客服也会看能否解决日常客户咨询的问题。
为什么要做需求评审?
在需求规划的过程中,其实只有产品经理一个人在负责所有事情,其他同事并不清楚具体的实施方案,因此,当PM输出初始方案后,就必须要让所有人都明确需求的背景和目的。产品经理会向需求的提出方确认需求,向需求的相关方(前后端开发的小伙伴,相关产品线的产品)确认需求,避免产生理解不一致的情况,也能及时发现并修正评审过程中的疑问和新的建议,完成更优方案迭代。
如何做需求评审?
按时间顺序可以分为3个阶段,会前-会中-会后。
会前准备工作:
将需求和实现的方法跟核心人员小范围提前沟通,尽可能保障评审前期不会出现很多质疑和疑问,提前解决大分歧;另外和提出方(运营、销售)确认清楚解决方案,获得支撑;将需求文档、流程图、原型提前发给有关人员,让大家知道评审的内容;和核心参会者确认可出席时间并提前发出会议邀请,定好会议室;产品经理可提前到会议室演练一遍。
评审会现场:
不要一上来就开始讲功能,可以先从需求背景或者用户故事说起;
讲需求要有节奏和条理,控制好时间,阐述功能、流程和方案,并开展讨论,将需求文档内容分模块输出;
记录重要争论点,评审中与会场所有人讨论做决定,如果会议中无法得到结果或者需要数据支持,则可以会议后通过下次评审或者通过书面形式进行;
确认需求目标,即功能上线达到什么目的,相关数据指标;
确认项目预计的上线时间和需要什么资源;
评审会后:
追排期;整理遗留问题,并拿出解决方案;发出会议记录,使每个问题都有具体行动计划;发出修改后的需求文档,并更新到内部系统中;如有需要可约下一次的评审时间。
成功的需求评审是产品经理的高光时刻,除了充分的准备外,还有一点很重要,就是让人信服,这关乎于沟通的态度和方式。
如何让人信服?
研究沟通的专家John Neffinger与Matthew Kohut在《令人信服的人(compelling people)》里提供了一种答案,认为那些人之所以能在第一面就对他人产生影响,是因为他们同时表现出力量(strength)与温暖(warmth)两类特质。
如果你只展现你的力量,你或许可以迅速获得人们的尊敬,但同时也可能招致他人的畏惧。如果你想要立刻获得人们的钦佩与支持,就一定要在表现出力量的同时,让他人感受到温暖。力量包括了你的能力和意志力。一个展现出力量(strength)的人会让人感到:你有能力实现你提出的想法,并且你能敦促自己采取行动、去尽力追寻你的目标。它包含了两个维度:a. 能力(ability)与b. 意志力(force of will)。当我们和人第一次接触时,表现出力量可以获得人们的尊敬。其中,一种展现力量的重要方式是做到自我坚定(self-assertiveness):做到能够在不伤害他人、以及控制住自己攻击性的同时,坚定地维护自己的立场。
力量这一点对产品经理是很重要的,自我坚定同时体现了能力和意志力,它需要一定的社交技巧(能力),也需要经受住他人施加的压力(意志力)。在需求评审中,适当坚持自己的立场,不要随着别人的质疑就轻易改变,因为要明确知道,没人比自己更清楚这个解决方案,还要经得起扛得住别人给的压力,毕竟最后还是产品经理对产品负责。
Kohut指出,长久以来人们误解了温暖的含义,认为表达温暖意味就意味着表达友好,意味着要多微笑或者显得好说话(agreeableness)。“但实际上,你要让别人相信,你和他们追求着同样的目标、欣赏同一种价值——人们会从这种相似性中感受到温暖”
温暖是一种“归属感”和“被关爱感”的结合。其中,归属感指的是“我与你是同一阵营”的感受。如果人们对你产生归属感,他们会相信你和他们有着相同的情感、观点、价值观。
同理,“同理心”是产品经理核心技能。在需求评审中,必须换位思考,因为很大可能由于设计上一个很小的不合理,会使得别人做大量的工作。
总结
需求评审是一位产品经理综合素养得以展示的时候,与其害怕,不如多做一份准备,多做一次演练,以最好的一面示人。尽管不一定每次都很成功,但是坚持对自己负责,对产品负责,对团队负责,久而久之,必然得到团队的信任。Everybody can say No,Some one can say Yes,PM就是那个说‘Yes’的人。
作者:志志(微信公众号:志太爷),喜欢打篮球,交朋友,欢迎大家一起交流学习。
本文由 @志志志 原创发布于人人都是产品经理。未经许可,禁止转载。
题图来自 Unsplash,基于 CC0 协议
评审中的流程不太对,核心流程高于功能模块
在业务层面上,流程是高于功能这是对的,因为功能模块服务业务流程。但是一个功能模块之下,也有它的实现流程,比如用户很渴,现在我们提供一个“供水”功能模块,那么就要先讲这个“供水”功能,然后再讲“如何供水”的流程。不同工作场景需要灵活应用。
不要乱定义 什么叫最讨厌的工作 也不是所有人都觉得讨厌 而且会给新人种下负面的种子
文中没有提及“最讨厌的工作”,文章表达的都是一种对需求评审要认真对待的态度,通过充分的准备而获得的成就感就是PM的高光时刻。这种认真付出得到回报的事怎么就给新人种下了负面的种子?
首段的第一句:需求评审其实是PM非常讨厌的工作 🙁
在做产品设计的时候多和开发经理沟通,避免需求评审再和开发怼起来
没错,其实需求评审只是一个最终确认的步骤,而产品需求如何设计和实现需要平时多沟通
一般评审会议大概要几次?
简单功能基本的1次可以过,假如会上有出现异议的,会后通过邮件形式说明就可以了。如果功能特别复杂涉及多方配合或者是新的产品线,这样就至少要2次了,这种评审会会耗时耗精力,所以产品经理一定要准备充分,避免浪费大家时间。