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

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

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

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

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

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

表达的逻辑

思考的逻辑

解决问题的逻辑

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

心理感知

用户使用习惯

过往类似问题处理

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

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

提升自己的逻辑自洽能力

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

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

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

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

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