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

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

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

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

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

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

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

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

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

一、准备工作

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

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

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

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

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

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

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

二、正式X

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、要qiú和方fǎ

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

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

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

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

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

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

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

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

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

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

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

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

四、小思考

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

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

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

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

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

最后,不同的产品经理有各自xí惯的评审方fǎ,不同的团队有不同的工作方式,不同的X有不同的企业文化,不同的需qiú有恰当的评审方式,产品经理应该因地制宜。

#专栏作家#

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

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

题图来自Unsplash,基于CC0协议

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

收藏 (0) 打赏

以上内容不错,打赏支持一下!

打开微信/支付宝扫一扫,即可进行扫码打赏哦,分享从这里开始,精彩与您同在
点赞 (0)

声明:本站所有教程资源,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。

雄发创业网 自媒体是如何赚钱的 需求评审不只是讲解,还需要把握要点 https://www.xiongfawang.com/738.html

常见问题

相关文章

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

分享本文封面