导语
作为产品经理，如论你是新手还是经验丰富的老手，都需要时刻谨记控制情绪，掌握沟通技巧；虽然沟通这个话题是老的不能再老的话题，也有很多有关沟通的文章，但是小酒认为把自己工作中遇到的沟通问题讲述给大家，并附上自己的反思，大家可以根据案例更好的明白遇到什么的问题应该怎么处理？
正文
故事背景
小酒是后台产品经理，主要负责电商的ERP系统，前几天与财务、仓储部门一起对接报缺需求，对接过程中，我们很多问题都在会议中做了结论，并确认了需求，大家都没意见，会后小酒发邮件认真的总结会议中各部门的每条需求，并让各部门负责人邮件确认，小酒心中暗喜，拖延很久的报缺业务流程终于确认了，会议中感觉大家都能清楚的知道自己想要什么，不要什么，终于可以下手梳理报缺流程了，小酒一口气把报缺业务流程图和原型都制作好了，兴高采烈的通知开发、测试、部门负责人评审需求，评审刚刚开始，报缺业务流程图刚评了五分之一，小酒就崩溃了，大家对那天对接的需求好像一点都不记得一样，各说其词，完全像没有讨论似的，小酒开始还能默默的听着，渐渐的失去了耐心，一遍遍的解释，那天需求是怎么对接的，怎么确认的......然而一点用的都没有，小酒只能干着急......
正确处理姿势
事后小酒冷静之后，做了总结，其实小酒自己犯了一个严重的错误，虽然经常警告自己，但是这次过于乐观了，仅管当时大家聊得很透彻，但每个部门都是站在自己的角度讲述需求，并没有时间或者意识去理解其他部门的需求，仅仅是清楚的表达出来自己想要的东西，所以小酒想应该在流程图出来之后，结合需求list在组织各个部门讨论，会议以讲解产品设计为主，把各个部门的需求串联起来，告知各个部门在某个流程中，他们需要怎么使用？可以得到什么样的结果？如何与其他部门对接，这样大家都会跟着产品的脚步走，然后一点一点的理解其他部门需求，并与自己的需求关联起来，这样各个部门会更深层的理解将来他们的需求会做成什么样子，整个流程是什么样子，自己在这个流程中扮演什么样的角色，有什么功能，有什么权限等等，会对将来的产品有个大致的框架，这样产品开发完成后，也会很快入手使用，降低产品使用的学习成本。
故事心得
小酒通过这件事，小酒整理出与业务部门沟通需求的注意事项，和大家分享一下：
1.了解业务部门的需求点，需坚持4w原则；弄清楚什么时间，什么地方，做什么，达到什么目的；业务方每提出一个需求，自己一定要多想想为什么。
2.如果一个需求关系到多个部门时，要与有关部门一起确认好规则制度以及权限，否则后期会出现一个功能多个入口的现象，这样会导致数据混乱。
3.需求讨论会结束后，一定把会议中确定好的问题和还存有疑惑的问题，邮件发送各个部门的负责人，并要求邮件回复确认，虽然有的业务部门对问题理解的并不深，但是一定让大家重视谨慎起来，因为在需求讨论初期，大家对需求的认知不深，很容易存在会后不总结不关心的现象，邮件回复确认，可以让大家有压力，有责任感。
4.与业务部门沟通初期，建议要求开发和测试，让他们提前参与业务讨论中，尤其是做后台产品，这样在后期需求评审时，可以降低业务理解成本和沟通成本；但是初次讨论，要把说话的机会让给业务部门，产品不要总想着这个需求不能做，那个需求复杂，初期需求讨论重点是要知道需求是什么，明白为什么，其他的可以放在下次讨论；而且同时要控制会议中，不要让开发讨论太多实现的问题，比如说有的需求会影响老功能，开发可能会担心开发成本等等；总之，不管参与会议的都是什么角色的人，要坚持一个原则就是弄清楚业务部门的需求是什么，明白为什么。
好啦，今天小酒就总结到这里，后期有了心得会继续更新哦O(∩_∩)O
