软件前端开发需求评审沟通

UI设计：为什么页面结构这么复杂，跟我们目前根本不是一个风格的东西。开发：你确定要这么做？开发难度很高啊，周期可能会很长！运营/市场：你这样的目的是什么？你确定用户会喜欢？我觉得没有卖点啊。然后就需要产品经理一个个耐心的解释需求，然后耐性消失开始卖萌耍贱，直到被逼死后大家勉强达成共识！

简单来说就是一个评议、审查、明确需求、统一思想并确定实现过程的会议；俗称挑刺大会，撕逼大会，逼死产品经理大会。

是产品经理阐述自己的需求设计思路和结果的一个重要环节，也是需求从设计环节到开发环节转化的中间桥梁。

需求评审可以起到承上启下的作用，如果在这个环节不能让相关方理解你的设计思路，要么需要进行二次评审，要么在后续的开发测试过程中会出现很多待确定的事项。

什么是需求评审？

让所有人相关者都明确需求的背景和目的。向需求的提出方确认需求，向需求的相关方（前后端开发的小伙伴，相关产品线的产品）确认需求，避免产生理解不一致的情况，也能及时发现并修正评审过程中的疑问和新的建议，完成更优方案迭代。

为什么要需求评审

认知一致，大家在才能为了共同的目标讨论解决方案

对系统设计人员、开发人员来说，需求理解的越透彻，开发实现的完成度就越高，越不容易偏离需求设计结果。

与相关方达成统一认知

相关人员可以与产品经理一起讨论需求设计的前因后果，这有助于相关人员获得用户需求的前期认识。

需求评审过程本身也是一个知识传递过程

需求评审很多时候也是一个迭代过程，很多情况下不能一步到位，事实上，这并不是什么坏事。我们都知道，需求失真发现的越早，修复成本越低。评审人员在多次迭代的评审过程中，或许能够发现解决现实问题更好的方案，而且他们对每次评审中出现的情况也比较清楚，知道哪些问题导致评审不通过，哪些需求可能还会有进一步变更等等。

产品二次确认

需求评审过程中可能发现不明确的或者遗漏的需求

与会人员共同讨论

需求评审过程中可能发现某些间接需求或隐藏的问题

需求评审的重要性

将需求文档、流程图、原型提前发给有关人员，让大家知道评审的内容；和核心参会者确认可出席时间并提前发出会议邀请，定好会议室；产品经理可提前到会议室进行准备。

评审前

讲解流程：需求背景-用户与需求-功能模块-流程-原型与交互-数据指标-资源和上线时间

在需求评审的开始阶段，首要讲解的不是具体的需求设计结果和功能点，而是要让参与评审的相关人员先明确需求产生的背景。要让大家知道需求产生的来龙去脉，这有助于大家建立初步的认知。从用户那边收集过来的，老板提出来的，业务部门提出来的，还是产品经理团队自己发掘出来的，以及需求产生的过程。其次要让大家知道需求实现的目的和价值，这时更多都是预估的，若有相关的数据分析支撑，会更有说服力。价值能够量化的情况下尽量量化，用相对科学的方式去计算预估。不能量化的情况则需要定性的描述，把实现的目标和完成的标志说明清楚，这样大家就清楚的知道去实现的意义，价值越大，实现的必要性越高。

先从需求背景或者用户故事说起，不要一上来就开始讲功能

“总分总”的方式。可以先说明白整体步骤，先做什么，再做什么，最后做什么。然后再按步骤细评各个环节的细节，都评完后再阐述一下总的流程。

阐述逻辑时也一样，先讲述通用逻辑，后补充特殊逻辑以及一些异常情况。

控制时间：作为评审会主持人，除了交代清楚需求，控制评审的节奏和效率也是十分重要。一些与会议无关的话题，要及时收住，提示大家回归正题。（有时开发会陷入技术细节讨论，如果与会人员较多时，细节讨论时间过长时可以提示对方会后私下讨论）

将需求文档内容分模块输出。有节奏和条理，控制好时间，阐述功能、流程和方案，并开展讨论

记录重要争论点，评审中与会场所有人讨论做决定，如果会议中无法得到结果或者需要数据支持，则可以会议后通过下次评审或者通过书面形式进行；

确认需求目标，即功能上线达到什么目的，相关数据指标；

确认项目预计的上线时间和需要什么资源；

评审会上

整理遗留问题，并拿出解决方案；

发出会议记录，使每个问题都有具体行动计划

发出修改后的需求文档，并更新到内部系统中

如有需要可约下一次的评审时间

需求确认后，追排期

评审后

需求评审需要做什么

和你的业务方认真推演产品要解决的问题。注意要抠出业务方要解决的问题，而不是问业务方“你要不要这个功能？” 作为产品经理，你要相信自己的产品设计能力，业务方提供的产品方案可以作为参考，不能作为指南。

仔细推敲产品方案，是否有考虑过还有其他的方式可以解决问题，不同的方案优缺点各是什么。

对于不确定实现可行性的功能需求，提前找到此项目对应的技术负责人，认真的和他们沟通你的方案和想法。降低需求评审被驳回重做的风险。

仔细review你的需求文档，是否各个细节都考虑到了，尤其是异常的情况，和其他系统有依赖影响的情况。

准备好相关数据佐证你的假设。评审上可能用得到

需求设计阶段

如果之前评审经常出现表达混乱，说的意思别人不容易懂。你可以再辛苦点，准备好一份评审大纲。帮助自己理清思路，查漏补缺。

表达的逻辑

思考的逻辑

解决问题的逻辑

https://www.jianshu.com/p/a4d184e89541

优化思维方式

分析解决问题的方法论

小范围验证

心理感知

用户使用习惯

过往类似问题处理

找个合理的理由

我们是需要思考在当前任务下的一系列的解决方案，将原来思考的散点串联起来，形成一个解决问题的核心主题，再在这个主题下逐个检查产品中需要做的事情。将主题内产品的各个交互、流程、界面、功能、以及文案所有牵涉到东西都做一遍再分析，再根据分析结构来是否要改（做），怎么改（做）。

一套方案，而不是一些思考点

产品思考很多时候是自己经历认知的反映，设计出身的产品会比较在意界面呈现；交互出身的产品会比较在意体验的感知；开发出身的产品比较在意逻辑的严密；运营出身的产品会比较在意数据的的反馈；或者因为之前做产品的经历，也会让你特别注重某些方面。经历往往会促使你对某方面比较执着，造成在思考的过程中不自觉的思维倾向，这种情况下，很容易思维走偏。在设计需求时，自己要注意提示自己修正自己的思考路线。

如何让你的需求更靠谱

7-38-55理论

语言在沟通中的占比只有7%

38%取决于语气

55%取决于肢体语言

沟通最重要的是什么？

小游戏-你说我画

沟通需要有来有往

需要注意关键人是否接收到了你的信息

反复确认

重复你的理解

沟通的技巧

参与评审的技术，他们的关注点可能各不相同。有的擅长剖析你的需求动机业务目标（大部分的技术leader会关心）、有的擅长追求细节（比如测试同学）、有的喜欢带偏话题（在你评审的时候，可能他们会提一个其他的话题）、也有的喜欢用“教导你”的口吻“教你”做怎么产品，还有各种各样

知己知彼

唯练不破

如何克服紧张

讲解顺序很重要，你可能没有先讲框架，大家没get到你想表达的核心诉求是什么。

当别人不能理解你说的话时，尝试换种表达方式。审视自己是否表达条理不够清晰。

为什么我说的别人听不懂？

缺少了沟通最重要的一步，复述

当你不确定自己是否和对方达成了一致观点时，请按照自己的理解讲述一遍你是怎么理解的。让对方确认你的理解是否有误

为什么有时候我感觉自己理解了，但是却并没有和对方达成共识？

找出方案相关者的共同利益点，表达自己特意考虑到了对方的利益

提升自己的逻辑自洽能力

逐渐提升合作信任感

这个不好做”、“实现不了的”。遇到技术们这样的回应时，绝大情况下是背后有一个巨大的开发量。不建议直接驳斥“这个还这么麻烦啊？”“很简单的啊，这样搞搞就行了啊”。我们需先权衡是否值得这样的投入？如果的确是一个很重要的业务卡口，可以表达清楚这件事的严重性，就算开发复杂，需要较多的时间也可以接受。

举例：上个版本的埋点触发逻辑，开发直接在群里说他实现不了。pm立刻电话沟通，询问是有什么难处导致实现不了。最终了解到是在现有的刷新逻辑下，实现不了需求。pm表示可以接受时间顺延，并且给出了调整刷新逻辑的方案，并且调整了埋点需求。最终双方打成了共识。

先对对方抛出的观点表示认可，再表述你的方法，询问对方是否可接受，他有什么难处。

不要吝啬夸赞对方，让专业的人给你专业建议

曲线救国

对方不同意你的方案怎么办？

要适当认怂，你的态度决定了对方的态度。

注意情绪

你也会遇到喜欢爆粗口的技术。“我x，这有个屁用啊！”“你是不是脑残啊！” 我们要控制好自己的情绪，因为这个粗口的背后，他们想表达的意是：“这样设计是不是不对”？只是加了一个感叹词嘛。听他们把背后的原因说出来，不建议用“为什么没用啊？”“这样挺好的啊”“我靠，你才脑残”来正面回应他们的感叹词，这会让气氛更尴尬，后面的评审更难进行。可以问“是有什么问题吗？”“方案哪里不合理？”

从这看来我们的开发真的很nice哈

注意用语

遇到争执怎么办？

如何让评审沟通更顺畅

需求评审是一位产品经理综合素养得以展示的时候，与其害怕，不如多做一份准备，多做一次演练，以最好的一面示人。尽管不一定每次都很成功，但是坚持对自己负责，对产品负责，对团队负责，久而久之，必然得到团队的信任。

软件前端开发需求评审沟通