小冰是入职两年的产品经理，也是我的同事.

管理项目、输出需求文档和原型、沟通都没问题；但让小兵苦恼的是自己总是会理解错业务的需求。

有一次甚至都开发完了，才发现需求理解有偏差。沟通之后，小冰才说了出来。

那天因为是一个推广活动，所以运营、合规、销售、产品、领导都一起开会讨论方案，小冰作为产品经理来撰写记录会议纪要。

因为人多嘴杂，运营抛出一个方案，大家七嘴八舌的讨论一番；

有的被否定，却又说了可以做；有的方案被大家通过，但觉得这个可以作为一个补充保留下来。

小冰听一句记录一句，最后会议就散了，小冰的本子上记录了满满的需求讨论方案。

经过分析，小冰连夜加班出了方案，和运营的某个同事确认方案的可行性后，召集技术进行开发。

等到快开发完成，领导发现开发出来的只是他们会议上讨论的备用推广方案，不是主打的方案。

而相应的海报和文案都是按照主打方案来做的，所以基本上可以宣告本次的推广方案已经失败了，之后领导狠狠的批评了小冰，并扣除了他全年的绩效。

无独有偶，类似于这种的事情，干过产品经理的人都遇到过。

然而通过上述的例子，作为产品经理，我们才能体会到，能正确记录和理解业务的需求才能避免我们的功夫白费，才能使我们输出的产品符合业务的需求，才能满足符合公司商业战略，更重要的是避免被扣绩效。

所以，在前期搜集需求阶段，尤其是这种直接会议的场合中，能准确和高效的撰写需求，才是检验一个产品经理是否合格的侧面反馈；也是上层领导考察你领导力的关键场合。

但有人可能说了，直接会议的方式，涉及到的部门众多，涉及到的关键人员也多，那么在会议上大家讨论的需求都不确认，这一句那一句的，怎么记录和确认呢？怎么才能高效理解，并输出高质量的会议纪要呢？

今天我们一起讨论下有几个办法能满足上述的疑问。

首先，明确会议的目的是什么？

一个需求或者一个项目的设立，都是应该有明确目的的。

比如说运营提出的推广方案，在这个阶段主要以拉新为准，在下个阶段以促活为准。

那么作为产品经理，在开会前应该明确方案的目的是什么，进而在会议上，专注于需求方对于这个目的提出的方案来做记录。

方案可以分1、2、3、4的记录，记录完成后，及时与提出方案的需求人员在会议上当面确认是否有遗漏。

还有另外一种情况。在会议中往往会出现不可控的现象，说着推广的方案，结果发散到了促活的点子上，而且往往中间还穿插着拉新的小点子，云里来雾里去的发散。

如果遇到类似这种情形，类似于不属于实现该目的的方案，建议听听就行，只要没形成完整方案，不用过多记录。

其次，会后再次与需求方确认本次会议记录的内容

会议有时候会持续很长，所以前期讨论的方案，会被后面大家讨论的更完整方案所覆盖；

此时作为产品经理在会后要及时将这种差异点和风险点暴露出来，如能当面确认则及时更改，如不能当面确认，会议纪要中需要写明或者标明差异点并与之确认。

一个方案的成型是需要多次打磨的。大家在会议上讨论的方案和本身可实行的方案往往是有差异的，有技术方面，有政策方面，也有资源方面的原因。

所以作为产品经理，在发出会议纪要之前，需要在会议纪要中标明，提醒业务部门。

然后，会议纪要的格式和方法

每个公司有每个公司的会议纪要的格式，但基本上就是参与人员、缺会人员、参会时间、会议内容，已决定的方案、待定的方案、异议方案等等。

参与人员：包括部门名称和部门人员；

缺会人员：涉及到该人员，但未参与会议；

参会时间：写明年月日时；

会议内容：将会议中提出的所有基于本次目的方案、提出人记录；

已决定方案：即会议上大家认可的方案；

待定的方案：即一些基于该目的的备用方案；

异议方案：即有意见的方案。

整理完会议纪要后，记得抄送相关业务部门领导和同事，确保各位信息同步；与关键需求人员沟通，确保回复邮件确认本次记录的会议纪要。

综上，本次会议纪要才算高效的撰写和记录

会议纪要的发出并不代表本次需求的确认，只代表高效的完成了本次会议的结果输出。

所以与业务打磨、与技术打磨、与自己打磨后，最终可能会产生与会议纪要中不一样的推广方案。此时我们才能根据该方案输出需求，进入开发，达成最终目的。

补充：作为普通人，我们没有乔布斯、张小龙般的才华，也不是拥有超级记忆力的天才。支持我们能在职场上走的更远的一定是谨小慎微的仔细，所以各位可参考上述几个方法，从高效的撰写会议纪要开始。