作为产品经理，需求评审环节是非常重要的，遇上会沟通的技术皆大欢喜，遇上沟通困难的技术也在所难免。本文作者总结了一些产品与技术在需求评审各个阶段中，可能会出现沟通困难的场景、复盘思路和应对建议，希望能给你带来一些帮助。
入产品坑的这年，我直接对接工作交流过的技术人员至少+，运气好遇到好交流的技术，与他们进行需求评审时，他们总会非常认真地对自己认知不清晰的地方，以提出问题、同义转化或作出假设等表达方式进行需求确认，或者将你在需求分析和产品设计之中的不足之处暴露出来，还非常积极地跟你一起讨论解决方案，更有甚者还能为你提供用户体验更好的参考设计，让你的产品之路跟开了挂一样地轻松、有趣。
运气不好就会在需求评审时遇到一些“奇奇怪怪”的技术，例如：
提前发布了需求评审的相关材料后，技术不会提前阅读，等评审会上过需求时，技术依然会问一些评审材料中已提到过的需求细节；
在需求评审过程中，当你询问是否有疑惑或者技术难点时，技术稳坐泰山一般不表达自己的观点，宛如对需求已经了然于胸；又或者提出一些似是而非的问题，当你追问是否有建议时，又不吭气了，仿佛刚刚提问题的不是他；更有甚者职责分明的质问你：“这难道不是你作为产品该思考的问题？”。
作为产品经理，在需求评审环节能遇上会沟通的技术皆大欢喜，遇上奇奇怪怪沟通困难的技术也在所难免。
当遇到沟通困难的技术时少不得会忍不住吐槽：xxx技术好难搞啊！xxx技术事儿真多！xxx技术不配合产品工作！
说实话我之前也这么吐槽过，也有过其他产品小伙伴响应我说遇到过同款技术。后面随着对工作的复盘和技术转产品同学的分享才发现：在产品觉得技术“难搞”的时候，技术可能也是这么看产品的。
换个角度，假设你是技术，在需求评审环节是不是也会有“一头雾水”的时候？又或者是“不敢说”的情况？例如：产品给的资料都是什么呀，东一份西一份的，到底哪个是重点？需求评审的资料要么全是文字，要么就一个不带交互的原型图，这也太简单了吧！需求评审时产品讲了半天，因为不知道需求背景没听懂，提问题反倒被产品说我是在故意找茬？我看到有个需求有问题，想提醒一下产品，一想到之前有遇到过向产品提问题就被怼的情况，还是不说了吧……
还记得之前“产品汪”与“程序猿”因为需求评审意见不合而爆出来的各种热门文章么？这些文章会通过文字或漫画的形式，给读者还原一些产品与技术在需求评审环节中搞笑、暴力、充满火药味的场景，由此火了很多自媒体账号。这也说明产品跟技术关于需求的“意见不合”是长期存在的共性问题，而这些问题追根溯源实际上都是“沟通问题”惹的祸。
正所谓一个巴掌拍不响，在需求评审环节出现沟通不畅时，必然是双方都有一定的因素，只是多与少的区别。
当你遇到在需求评审环节中与技术对接过程中沟通不困难时，不要先急于从技术身上找原因，要先自省，检查自己有没有做好自己在需求评审过程中的本职工作。
怎么进行自查呢？以让你最崩溃的一次需求评审为基础进行复盘，回顾一下在你在此次需求评审的各个阶段。例如，你为该阶段做了什么准备工作？该阶段你是怎样与技术/产品沟通的？最终造成了怎样的后果？你当时的情绪是怎样的？你觉得对方当时的情绪是怎样的？是否有思考过以下提到过的相关问题？
以下便是我总结的关于产品与技术在需求评审各个阶段可能会出现沟通困难的场景、复盘思路和应对建议：
作为产品，你是否有做到在需求调研和规划过程中，就会与技术同步客户诉求或者产品规划思路？是否有主动与技术沟通客户新诉求中有哪些可能会涉及到新技术？
涉及新功能开发或新流程设计时，是否有给技术预留充足的技术选型时间？是否有在条件允许的情况下就让技术参与与客户进行需求确认时的需求确认会或者将相关信息事后同步给技术？整个需求调研环节中是否有过技术参与？提升技术的参与感强不强？
建议在每次需求调研结束后第一时间与技术同步信息，主动询问技术是否有技术难点或者对客户需求不明确的地方，如果有你则沟通好替代方案或想办法砍掉后，再拿这些结果找客户进行重点沟通确认，以确保需求符合客户需求的同时技术可实现。
这个阶段的沟通的技巧在于：选择合适的场合与时间，主动“勾搭”你的目标人物，将你要说的内容以故事的形式传递出去。
例如：午饭时，产品和技术一起吃饭，这时候产品可以“不经意”的说起xxx客户今天又给我打电话提新需求了，说的是……搞得我不知道怎么搞，头都想痛了，你觉得这个需求能整不？如果是技术，同样可以在午饭时间问产品，今天听到你好像在跟客户讨论xx需求，这个是干啥的？是我们后面要做的么？是有新的功能还是可以套用现有功能呢？
另外，产品可以通过场景式的“用户故事”引导技术代入到用户的使用场景中，便于技术了解用户需求、对研发难度有所评估。参考表达方式“我作为XXX角色，我希望拥有XXXX需求，目的是XXXX”。例如：当我要买一辆车时，我希望能同时看到尼桑逍客与长安plus的各项配置，如大小、可选颜色、排量、价格等，好让我能更方便的对比两个车的配置哪一个更适合我。
至于为什么会把这部分放在前面呢？因为需求调研是需求评审的“地基”。需求调研过程中产品与技术沟通良好、对项目的参与感强，才能让技术同产品一样，愿意把此次要做的需求当作是自己的“孩子”，而不是全靠产品思考及规划，能进一步地推动后续工作的有效开展，提升沟通的效率，同时双方也会将需求背景、目标、内容等达成共同的认知，而不是等后期再向技术传递二次加工过的内容，导致技术认知产生片面化。
咱们作为产品经理，需要提前准备好需求评审相关的所有资料，并发起需求评审会议。这时候要重点关注的点：评审资料里包含什么？是否有做好全部资料中文件名的备注，可以让人直观地了解文件是干嘛的？
会议通知中是否有说清楚资料之间存在什么关系？如何引导参会人按要求阅读评审资料？怎么检验参会人是否有在会前按要求完成资料阅读/会前任务？哪些人必须参加需求评审会议？是否有跟必须参加的人员沟通确认好参与时间内肯定可以到场或远程参与？
建议在需求评审前提前与主要的技术进行一些有互动性的沟通。例如，针对在评审会议通知的内容中，除了会议通知中必要的：会议主题、时间、地点、参与人、会议形式、会议地点、会议流程之外，一定要把附件的评审材料都包含哪些、阅读顺序是怎样的讲清楚，并设置会前任务。
如针对材料中的一些重点内容进行问题设定，要求哪些参会人员需要在什么时间之前阅读完材料并进行回答，以此促使技术提前阅读材料，给自己预留会前与技术沟通并补充评审材料的时间。
由此可见，如果一个产品能做好需求调研和需求评审前的准备工作，技术能在需求评审前认真熟悉评审材料并进行过思考。等到需求评审时，就只需敲定一些未被确认的事项及接下来的工作安排，这样的需求评审效率肯定非常高！
等需求评审时才会真的没有“硝烟”，而不是产品个人“脱口秀”造成的“全员静默”。在评审会前有充分沟通的前提下，需求评审会可能就沦为查漏补缺过流程了。
有没有过产品在上面讲的“激情四射”，宛若无人之境一般不与技术进行眼神交流、互动问答？又或者一问技术有没有问题，全场你看我我看你“大眼瞪小眼”，于是默认大家都听懂了而结束评审环节？
有没有技术看起来在需求评审时好像都听懂了，但是等执行的时候却发现，实际还有好多不清楚的地方？又或者听产品讲需求时会“神游天外”或者“昏昏欲睡”？
建议产品每讲完一个需求关键点后，就问下技术是否有问题、是否有建议等多与技术进行互动；如果没有人回复，就点一个比较相熟或者负责该部分需求写代码的技术，让其同义转化一下，以确认对方真的有听懂，而不是产品一人单方面的“演讲”，让技术也听的“神游天外”。
有互动的需求评审能让会议参与的相关人员时刻保持相对集中的状态，以防参会人被问到时，避免因没认真听而无法做出问答反馈所造成的尴尬。
这个环节可能产品和技术最担心的就是因“情绪失控”造成会议“场面失控”，产品过需求时要思路要比较清晰，才能减少被技术喷的次数，而技术也要以具体问题具体分析的态度向产品提问，而不是抱着“事不关己”的态度把需求评审环节当作过场。
作为产品的你是否有做好需求评审会的会议记录？是否有将评审会议记录同步给所有参会人和计划参会但无法参会的人？有没有做好会后确认工作？是否有明确会后任务的具体执行人、交付时间和验收标准？如果当前需求评审未通过，是否有确认二次需求评审的时间？
就此我提出以下建议：
首先，一定要将调研纪要整理好同步给所有产品相关人员，包括你的直属领导、销售、项目经理、UI、UE、技术、测试、运营等。这一步可以有效减少后期出现问题后“相互甩锅”的现象，特别是将结果同步了领导知晓，有助于整个进度顺利实施或争取资源。
其次，需要与主要的技术再次确认其是否已经明确了自己要做的任务内容、主流程情况等。必要的时候找平时沟通相对比较困难的技术，让其对自己负责的需求进行同义转化，简单复述一遍以确认技术真的已经明白了需求。
最后，每次需求评审结束后对需求评审结果进行复盘：例如，整个评审各个阶段是否顺利？有哪些可以改进的地方？遇到过哪些问题？如果再遇到了该怎么避免？哪些技术有一定的产品思维好沟通？哪些技术需要重点关注其对需求的了解程度等。
我换过比较多的公司，其中有一家公司在需求评审时就做得比较好：
第一点，有统一的参考模板，包含会议通知、会议纪要、需求开发确认书、功能清单、数据口径说明书、邮件汇报等。
第二点，会让项目的核心技术尽量全程参与需求评审过程，从需求调研到需求评审结束。
第三点，会充分了解客户各个层级对系统的需求，以用户故事的方式转达给技术。
第四点，团队合作遇到困难时会开会进行复盘，而不是相互指责或则甩锅。整个需求评审流程一环扣一环形成了闭环，所以经手的产品和项目很少有返工的现象，最多是微调数据口径，客户口碑还不错。
由此可见需求评审的成功与失败是和产品的成功与失败直接关联的。因为需求评审结束后形成的已确认材料，对接下来的研发工作是关键的指导性文件，团队所有人都会以此为目标进行自己的工作安排实现最终的交付工作，所以必须要做到团队成员通过需求评审实现对需求的认知一致。
想达到需求评审环节的认知一致，就需要需求评审在调研时、评审前、评审时和评审后都要做好。可以尝试使用PDCA循环来管理，事先有计划（Plan）、按计划执行（Do）、设定检查点（Check）、复盘并处理（Act）。
例如需求调研时，列好计划要调研哪些人、哪些问题、什么时间完成调研等，按计划执行调研工作，定期检查调研计划是否有按计划执行，输出调研报告并复盘调研过程是否顺利，有那些经验教训可以形成知识库等。
因此，只有项目团队在需求评审过程中达成了共同认知，才能对后面工作的展开形成有效的沟通环境，才是做好产品的底层逻辑。
以上是我对如何形成需求评审闭环的方法论供大家参考，因文字有限，仅列举部分，希望能对大家在需求评审时有所帮助。如有想详细沟通的可直接找我交流，非常欢迎大家找我分享或者进一步研讨。
