需求评审不只是讲解,还需要把握要点

1 评论 4899 浏览 10 收藏 21 分钟

编辑导读:需求评审是产品经理的一项基础工作,和技术人员、UI设计师等人员一起探讨需求落地的可行性。在需求评审会议中,不单单只是讲解,还需要把握要点,让需求评审会议发挥出它最大的价值。本文作者对此进行了分析,与你分享。

需求评审是产品经理工作的重要环节,是团队成员间衔接需求的重要桥梁,产品经理的方案能准确落地的重要保障。几乎每个产品经理,工作中都经历并主持过需求评审。无疑,产品经理是需求评审的主角,主导整个过程。

需求评审的主要内容,其实就是讲解需求。很多次刚入行的产品经理会疑惑,为什么有了PRD和原型,还要进行需求评审?因为,有很多信息是图和文字不能完全表达清楚的。需要大家进行沟通,打破信息的孤单岛。

当然,需求评审也不完全是讲解,还要与干细人员一起审验需求的方案和业务细节。因此,需求评审在需求落地的过程中的也有很积极的作用。同时,还能够促进需求方案的完善,探索方案的合理性。在这基础上,优秀的需求评审,甚至能影响团队的凝聚力,达成方向与目标的一致性。

需求评审的参与人员,几乎涵盖团队的所有人员。最直接的人员,就是技术人员和UI设计师。他们是负责产需求落地为产品功能的第一把手。他们在业务的可行性上,会提供最具参考价值的意见和反馈。当然,也需要运营和市场的人员参与。他们能为方案和细节提供一些参考和建议,同时也为了减少后续的重复沟通。特别是B端产品,运营和市场人员可能会直接对接客户。那么他们的很多意见就代表着客户的反馈。

可能很多产品经理会觉得需求评审,是一件很简单的事情,只是讲一讲需求,与大家一起探讨一下需求的正确性。但要做好需求评审,却是一件非常困难的事情。特别是要在保证效率和质量的情况下。这其中有很多的细节和方法,能够帮助产品经理改善需求评审。这些方法大都是对细节的把控和经验的总结。

一次失败的需求评审会,在技术及其他团队成员之间,容易造成对需求理解的歧义,进而导致更大的项目风险。失败的需求评审,极端情况下可能导致团队的裂痕,项目的开发进度延误,甚至于项目的失败。

如果在需求评审的过程中,与会人员对于业务的设计上存在较大的歧义,对方案有较多的负面反馈。那就需要反思产品经理的需求设计,是不是准备的不够充分。

一、准备工作

在正式开始需求评审之前,我们需要先做好的相关的准备工作。毕竟,需求评审涉及到的内容通常都是比较多的。而且,需要我们及时流畅的进行讲解。产品经理不能打没有准备的仗,一定要准备足够充分。

既然要进行需求评审,第一步必须完成原型设计、UML图和PRD文档的准备。这是需求评审的前提。需求评审评的就是这些东西所承载的内容。

在需求评审前,产品经理还需要先进行方案和技术的可行性评审。

第二步产品经理需要梳理一下评审的流程,并进行粗略的预演。

第三步则是需要准备好相关的资料。比如,相关的背景资料、技术人员研发过程中用到的对接文档等。如果在评审的过程中,我们需要进行演示,那还要准备好演示的相关资料和环境。如果有争议的需求,我们可以提前准备好数据等内容,以提升我们方案设计的说服力。

最后,做好以上准备后,我们就可以准备会议室并通知相关的参会人员。通知参会人员时,我们需要将准备好的资料提前发放给他们,并告知他会议的日期和注意事项。如果有远程参会的人员,需要进行特别提醒,并设置好提前通知他们参会的备忘事项。

在进行准备工作时,一定一定要提醒相关人员在参会前预习发放的资料和相关的PRD、原型、UML图等。如果参会人员不提前了解需求的相关方案,在会上再来思考的话,一方面会降低会议整体的效率,另一方面也不能充分的吸收和理解需求评审的内容。

二、正式会议

在正式开始需求评审会之前1~2个小时内,产品经理一定要对会议的流程和评审的需求进行回顾和熟悉。

需求评审的进行过程,我个人比较喜欢采用,经典的总分总的模式来开展。整体的总分总,在细化到每个功能点和细节的总分总。第一个「总」代表着整体性的介绍和说明;「分」代表着分点说明;第二个「总」代表讨论提问和总结环节。在这基础上,我将我的需求评审过程,分为五个步骤。第一步是背景介绍;第二步整体介绍;第三步功能细节评审;第四步提问讨论环节;第五步总结环节。下面,我们就来讲讲,每一步是怎么做和对应的一些方法。

正式开始需求评审之前,我们还需要确认一下人员的到场情况。如果,有一些关键人员没有到场的话,我们可能要确定一下是否需要延迟需求评审或者改期。

正式开始需求评审之后,第一步是背景介绍。首先我们要介绍需求的背景以及相关的行业背景。通常可以穿插着介绍一下用户的情况或者说客户的情况。在背景介绍的环节,通常我还会进行一些暖场。简单介绍一下我们这个需求解决的问题,以及完成这个需求之后,我们产品可能达到的目标或带来的增长。

第二步则是,需求方案的整体介绍。包括我们设计方案的整体结构,整体的业务流程,涵盖了哪些功能,涉及那些系统,以及系统间如何进行交付。还有整个业务的角色构成,甚至于我们给到的文档的构成情况。

第三步是正式进行功能的评审。功能评审,可以按照功能的关联性,串起来按模块进行评审。这样会使整个条理清晰。对于业务有关联性的,也可以按照业务流程来进行评审。对于单个功能的评审,也可以按照总分总的原则来展开。

在实际进行评审时,通常是根据原型图来进行讲解。一边以原型的交互来演示,一面配合逻辑上的讲解。在讲解的过程中,如果有UML图的话,可以穿插UML图到讲解的过程中。比如,在讲解某个功能的业务流程时,先讲解流程图。在讲解的过程中,应该按照用户的交互过程来进行展开。

在讲解原型的过程中,需要对细节进行补充。主要涉及到的内容,包含限制条件异常处理;UI需求的一些要点;可动态修改数据;某些业务包含的明细规则。明细规则,应该一条一条的给大家捋清楚,并且详细说明这些规则的说明在文档的那个部分。

在功能的讲解过程中,应该包含系统性的要求。比如说安全性、稳定性、响应时长、数据需求等。

在进行业务和功能讲解时,如果一场需求评审会,有多个产品经理参与,那么就需要在产品经理间穿插进行需求评审。通常以我需求评审的经验,进行产品经理间的穿插评审,我会保证业务的流程的完整性和顺序。同时,要求产品经理保持评审的风格一致。

当完成功能评审后,就进入到提问和讨论环节。提问和讨论环节,可以分为两个部分。一部分是在现场完成的。现场进行提问,并解答和讨论。另一部分则是在会后,相关人员进行更细致的消化之后的提问和讨论。在提问和讨论环节,尽量避免长时间的争议。以提高会议的效率。尽量把存在争议的环节,放在会后仔细研讨后再做定夺。对于提问和讨论,产品经理需要及时的记录相关的要点,以便会后对相关的文档和方案进行更新。

提问和讨论环节,并不是严格的放在所有功能评审完成之后再进行的。应该在功能评审的适当环节进行。比如,完成一个功能板块的评审之后,就可以乘热乎,对于这个功能板块的内容提问和讨论。特别是,当评审的内容较为庞大时,最后进入提问和讨论环节,可能并不效率并不高。因为相互人员想到的问题,已经被他们忘记了。但是,也并不建议在评审环节中随时提问。因为评审整个过程是存在关联性的,可能现在提出的问题,是后面的评审内容。再者,随时的打断不仅会打断产品经理的思维,还会降低整体的评审效率。

最后是总结环节。总结环节,主要是将大家提出的疑问和讨论的结果,进行总结提炼。最后还要和参会人员确定一下反馈的内容。比如,相关的研发人员给出节点的时间的时间,某些待明确问题的确认时间等。以及,讨论一下具体的后续计划安排。

以上,就完成了一场需求评审会。虽然会议完成了,但不代表着需求评审的工作完结,还有一些后续的环节。评审会完之后,产品经理需要对设计的需求方案和收到的一些意见反馈进行优化,会上待明确的内容进行明确,并且确定相关的时间节点。如果评审完之后,还要进行二次评审,那需要尽快确定二次评审的时间,尽快进行二次评审。需求评审也只是需求落地的万里长征的第三步。

已经没有待确认项并需求评审通过后,产品经理需要和相关人员,尽快确定好后续节点的时间。比如,UI的评审时间,研发的时间节点,上线节点等。最后,将时间节点整理成计划表。

三、要求和方法

在评审会时,产品经理要保证会议良好的氛围。尽可能,调动与会人员参与讨论。但是,尽量不要陷入到无穷的争议当中,避免抬杠。我有一个诀窍,就是当大家产生争议,如果能给出佐证争议的相关证据,那我们就继续深入讨论。如果,没有给出有说服力的证据,那我们就留待会后,再深入研究和小范围讨论。

在需求评审会上,建议大家多使用白板。不仅是自己用,也督促参会人员使用。特别是在讨论一些较为复杂的内容时,白板上勾画的内容比单纯的言语更令人易于理解。

前文已经提到过,这里再强调一下。要提高需求评审会的效率,一定一定是相关参会人员要提前阅读需求相关的文档和资料。

要开好需求评审会,不是一个快速的过程,而是一个逐渐形成标准化的流程的过程。对于每个产品经理都是这样,即使是很多年工作经验的产品经理,换了一个工作环境和团队,也需要重新形成需求评审的标准化流程。因为不同的团队,环境和文化氛围不同,需求评审会议最优的方式也不一定相同。

有些产品经理在评审时,特别是提问和讨论环节,喜欢全程录音,来会后进行回顾。我个人并不建议这样做,因为一般评审会的信息密度都达不到录音来保存信息的底部。对核心要点,记笔记,就足以应付大多数问题。除非你记性实在是太差了。

要开好一场需求评审会,虽然对于大家来说方法可能各有不同,但是有一些要求。一些要求是相同的,只有达到这些要求,基本上才能做一场良好的需求评审会。

产品经理一定要成为需求评审会的主导者,一定要带领大家去参与需求评审。而不能被其它牵着鼻子走。特别是在,有上级领导参与的过程中。

既然需求评审会,要求产品经理进行讲解,那么产品经理最基础应该保证自己发言的简洁明了通俗易懂。但是,切记不要去追求语言上的技巧。直白的语言,是最容易传递信息的。另一方面,在沟通和讲解的技巧上,产品经理还是要花点心思学习的。怎么与人沟通,怎么把一个东西简单明了的讲清楚,还是有一定技巧的。多练,也能熟能生巧。

需求评审会,产品经理要精确的控制好节奏和时间。计划多久完成需求评审,尽可能按时完成。多人会议通常拖的时间越久效率就越低。控制会议的节奏,也是产品经理的基础需求功力的体现。说白了就是自己对自己业务的熟悉程度。

在需求评审会上,尽量不要陷入到UI和交互的主观讨论甚至于扯皮上。产品经理一定要明确需求和产品的核心价值是什么。UI和交互是个人倾向很重的内容。这部分能容应该是群体的认同占主题,而不是陷入到个人执拗当中。

需求评审会上,尽可能的保证某个人都不被打断完整的发言。会议室不是菜市场,严禁多人产生哄抢式的争论。会议上的争论并不可怕,可怕的是走偏了方向,去讨论无关紧要的内容。菜市场式已经是被证实最容易带偏方向的。如果讨论的方向走偏了,作为评审会的掌舵人,产品经理要及时把大家带回正轨。

需求评审会不是挑刺大会。尽可能控制,任何人不要以为别人找出问题为目的来讨论问题。大家的核心目的一定要专注在理解到整个需求,讨论问题并找到最优的解决方案上。

四、小思考

在某些情况下,需求评审会可能要远程进行。远程评审的难度比在会议室高了很多很多。远程评审的硬件环境,要更复杂一些,需求投屏、语音之类的设备。而且,语音沟通肯定不如现场沟通来的直接。所以,我个人觉得能够现场评审,尽量不要做远程评审。如果一定要远程评审,那么尽可能的准备充分的文档,并且让与会人员详细详细再详细的阅读。

需求需不需要评审,其实主要由两点决定的。一是文档能不能详细的阐明清楚需求的设计方案。另一点是有没有容易导致大家产生歧义的点。也与团队的协作模式有关系。如果团队协调的已经很高效,而且非常乐于用文档传递信息,并且已经在高效的通过文档来传递信息,那么可以考虑不进行需求评审。有时候一个过于简单的需要,其实也是没有必要进行评审的。

需求评审是不是一种高效的传递信息的方式?显然不是的。因为一群人聚在一起通过讲解和讨论的形式,短时间内吸收大量的信息,并不高效。通过文档来传递信息是最高效的。但是,对于同一个内容,不同的人可能会产生截然不同的理解。因此,需求评审是需求文档的有效补充。需求评审能够「更准确」的传递信息。

我个人觉得一场会议,无论是什么类型的会议,尽可能的都要简短。超过两个小时的会议,会议的效率会非常非常低。我个人参加一个会议,超过半小时,待在一个密闭空间里,就有些受不了。更别说专心的吸取庞大的信息。

需求评审会上还需要注意,谁有决策权。是与会的领导有决策权?还是民主的方式来进行决策?这决定了需求评审会的进行过程和讨论氛围。强势的上级领导,在需求会上做决策,通常是一场需求评审会的灾难的开始。所以我通常在需求评审会前和后,与上级领导和后进行沟通,而不是其直接参与需求评审会议。「前」是确认,「后」是反馈。

最后,不同的产品经理有各自习惯的评审方法,不同的团队有不同的工作方式,不同的公司有不同的企业文化,不同的需求有恰当的评审方式,产品经理应该因地制宜。

#专栏作家#

产品小思考,微信公众号:产品小思考,人人都是产品经理专栏作家。擅长行业业务分析,设计行业方案,设计B端产品架构。主要关注医美、医疗行业,涉及HIS、CRM和各类业务系统产品。

本文由@产品小思考原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 满满的干货 一看就是经验之谈

    来自北京 回复