需求评审&沟通技巧
2019-08-13 10:25:49 8 举报
AI智能生成
需求评审&沟通技巧
作者其他创作
大纲/内容
需求评审&沟通技巧
什么是需求评审?
UI设计:为什么页面结构这么复杂,跟我们目前根本不是一个风格的东西。开发:你确定要这么做?开发难度很高啊,周期可能会很长!运营/市场:你这样的目的是什么?你确定用户会喜欢?我觉得没有卖点啊。然后就需要产品经理一个个耐心的解释需求,然后耐性消失开始卖萌耍贱,直到被逼死后大家勉强达成共识!
简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议;俗称挑刺大会,撕逼大会,逼死产品经理大会。
是产品经理阐述自己的需求设计思路和结果的一个重要环节,也是需求从设计环节到开发环节转化的中间桥梁。
需求评审可以起到承上启下的作用,如果在这个环节不能让相关方理解你的设计思路,要么需要进行二次评审,要么在后续的开发测试过程中会出现很多待确定的事项。
为什么要需求评审
让所有人相关者都明确需求的背景和目的。向需求的提出方确认需求,向需求的相关方(前后端开发的小伙伴,相关产品线的产品)确认需求,避免产生理解不一致的情况,也能及时发现并修正评审过程中的疑问和新的建议,完成更优方案迭代。
需求评审的重要性
与相关方达成统一认知
认知一致,大家在才能为了共同的目标讨论解决方案
对系统设计人员、开发人员来说,需求理解的越透彻,开发实现的完成度就越高,越不容易偏离需求设计结果。
需求评审过程本身也是一个知识传递过程
相关人员可以与产品经理一起讨论需求设计的前因后果,这有助于相关人员获得用户需求的前期认识。
需求评审过程中可能发现不明确的或者遗漏的需求
产品二次确认
需求评审很多时候也是一个迭代过程,很多情况下不能一步到位,事实上,这并不是什么坏事。我们都知道,需求失真发现的越早,修复成本越低。评审人员在多次迭代的评审过程中,或许能够发现解决现实问题更好的方案,而且他们对每次评审中出现的情况也比较清楚,知道哪些问题导致评审不通过,哪些需求可能还会有进一步变更等等。
需求评审过程中可能发现某些间接需求或隐藏的问题
与会人员共同讨论
需求评审需要做什么
评审前
将需求文档、流程图、原型提前发给有关人员,让大家知道评审的内容;和核心参会者确认可出席时间并提前发出会议邀请,定好会议室;产品经理可提前到会议室进行准备。
评审会上
讲解流程:需求背景-用户与需求-功能模块-流程-原型与交互-数据指标-资源和上线时间
先从需求背景或者用户故事说起,不要一上来就开始讲功能
在需求评审的开始阶段,首要讲解的不是具体的需求设计结果和功能点,而是要让参与评审的相关人员先明确需求产生的背景。要让大家知道需求产生的来龙去脉,这有助于大家建立初步的认知。从用户那边收集过来的,老板提出来的,业务部门提出来的,还是产品经理团队自己发掘出来的,以及需求产生的过程。其次要让大家知道需求实现的目的和价值,这时更多都是预估的,若有相关的数据分析支撑,会更有说服力。价值能够量化的情况下尽量量化,用相对科学的方式去计算预估。不能量化的情况则需要定性的描述,把实现的目标和完成的标志说明清楚,这样大家就清楚的知道去实现的意义,价值越大,实现的必要性越高。
将需求文档内容分模块输出。有节奏和条理,控制好时间,阐述功能、流程和方案,并开展讨论
“总分总”的方式。可以先说明白整体步骤,先做什么,再做什么,最后做什么。然后再按步骤细评各个环节的细节,都评完后再阐述一下总的流程。
阐述逻辑时也一样,先讲述通用逻辑,后补充特殊逻辑以及一些异常情况。
控制时间:作为评审会主持人,除了交代清楚需求,控制评审的节奏和效率也是十分重要。一些与会议无关的话题,要及时收住,提示大家回归正题。(有时开发会陷入技术细节讨论,如果与会人员较多时,细节讨论时间过长时可以提示对方会后私下讨论)
记录重要争论点,评审中与会场所有人讨论做决定,如果会议中无法得到结果或者需要数据支持,则可以会议后通过下次评审或者通过书面形式进行;
确认需求目标,即功能上线达到什么目的,相关数据指标;
确认项目预计的上线时间和需要什么资源;
评审后
整理遗留问题,并拿出解决方案;
发出会议记录,使每个问题都有具体行动计划
发出修改后的需求文档,并更新到内部系统中
如有需要可约下一次的评审时间
需求确认后,追排期
如何让你的需求更靠谱
需求设计阶段
和你的业务方认真推演产品要解决的问题。注意要抠出业务方要解决的问题,而不是问业务方“你要不要这个功能?” 作为产品经理,你要相信自己的产品设计能力,业务方提供的产品方案可以作为参考,不能作为指南。
仔细推敲产品方案,是否有考虑过还有其他的方式可以解决问题,不同的方案优缺点各是什么。
对于不确定实现可行性的功能需求,提前找到此项目对应的技术负责人,认真的和他们沟通你的方案和想法。降低需求评审被驳回重做的风险。
仔细review你的需求文档,是否各个细节都考虑到了,尤其是异常的情况,和其他系统有依赖影响的情况。
准备好相关数据佐证你的假设。评审上可能用得到
如果之前评审经常出现表达混乱,说的意思别人不容易懂。你可以再辛苦点,准备好一份评审大纲。帮助自己理清思路,查漏补缺。
产品思考很多时候是自己经历认知的反映,设计出身的产品会比较在意界面呈现;交互出身的产品会比较在意体验的感知;开发出身的产品比较在意逻辑的严密;运营出身的产品会比较在意数据的的反馈;或者因为之前做产品的经历,也会让你特别注重某些方面。经历往往会促使你对某方面比较执着,造成在思考的过程中不自觉的思维倾向,这种情况下,很容易思维走偏。在设计需求时,自己要注意提示自己修正自己的思考路线。
优化思维方式
表达的逻辑
思考的逻辑
解决问题的逻辑
https://www.jianshu.com/p/a4d184e89541
分析解决问题的方法论
小范围验证
找个合理的理由
心理感知
用户使用习惯
过往类似问题处理
一套方案,而不是一些思考点
我们是需要思考在当前任务下的一系列的解决方案,将原来思考的散点串联起来,形成一个解决问题的核心主题,再在这个主题下逐个检查产品中需要做的事情。将主题内产品的各个交互、流程、界面、功能、以及文案所有牵涉到东西都做一遍再分析,再根据分析结构来是否要改(做),怎么改(做)。
如何让评审沟通更顺畅
沟通最重要的是什么?
7-38-55理论
语言在沟通中的占比只有7%
38%取决于语气
55%取决于肢体语言
沟通的技巧
小游戏-你说我画
沟通需要有来有往
需要注意关键人是否接收到了你的信息
反复确认
重复你的理解
如何克服紧张
知己知彼
参与评审的技术,他们的关注点可能各不相同。有的擅长剖析你的需求动机业务目标(大部分的技术leader会关心)、有的擅长追求细节(比如测试同学)、有的喜欢带偏话题(在你评审的时候,可能他们会提一个其他的话题)、也有的喜欢用“教导你”的口吻“教你”做怎么产品,还有各种各样
唯练不破
为什么我说的别人听不懂?
讲解顺序很重要,你可能没有先讲框架,大家没get到你想表达的核心诉求是什么。
当别人不能理解你说的话时,尝试换种表达方式。审视自己是否表达条理不够清晰。
为什么有时候我感觉自己理解了,但是却并没有和对方达成共识?
缺少了沟通最重要的一步,复述
当你不确定自己是否和对方达成了一致观点时,请按照自己的理解讲述一遍你是怎么理解的。让对方确认你的理解是否有误
对方不同意你的方案怎么办?
找出方案相关者的共同利益点,表达自己特意考虑到了对方的利益
逐渐提升合作信任感
提升自己的逻辑自洽能力
曲线救国
先对对方抛出的观点表示认可,再表述你的方法,询问对方是否可接受,他有什么难处。
这个不好做”、“实现不了的”。遇到技术们这样的回应时,绝大情况下是背后有一个巨大的开发量。不建议直接驳斥“这个还这么麻烦啊?”“很简单的啊,这样搞搞就行了啊”。我们需先权衡是否值得这样的投入?如果的确是一个很重要的业务卡口,可以表达清楚这件事的严重性,就算开发复杂,需要较多的时间也可以接受。
举例:上个版本的埋点触发逻辑,开发直接在群里说他实现不了。pm立刻电话沟通,询问是有什么难处导致实现不了。最终了解到是在现有的刷新逻辑下,实现不了需求。pm表示可以接受时间顺延,并且给出了调整刷新逻辑的方案,并且调整了埋点需求。最终双方打成了共识。
不要吝啬夸赞对方,让专业的人给你专业建议
遇到争执怎么办?
注意情绪
要适当认怂,你的态度决定了对方的态度。
注意用语
你也会遇到喜欢爆粗口的技术。“我x,这有个屁用啊!”“你是不是脑残啊!” 我们要控制好自己的情绪,因为这个粗口的背后,他们想表达的意是:“这样设计是不是不对”?只是加了一个感叹词嘛。听他们把背后的原因说出来,不建议用“为什么没用啊?”“这样挺好的啊”“我靠,你才脑残”来正面回应他们的感叹词,这会让气氛更尴尬,后面的评审更难进行。可以问“是有什么问题吗?”“方案哪里不合理?”
从这看来我们的开发真的很nice哈
需求评审是一位产品经理综合素养得以展示的时候,与其害怕,不如多做一份准备,多做一次演练,以最好的一面示人。尽管不一定每次都很成功,但是坚持对自己负责,对产品负责,对团队负责,久而久之,必然得到团队的信任。
0 条评论
回复 删除
下一页