大家好，我是张鼎，长期在软件行业负责产品策划。作为一名这个行业的从业者，避免不了的一件事就是每天需要和程序员进行沟通。而很多时候，这件事情又让人觉得颇有难度甚至沟通不好时令双方都有些抓狂。今天我就在这里分享一下我对这个事情的心得。
根据我的观察，不能有效和程序员沟通的核心问题在哪里呢？我认为都是双方的理解偏差造成。
沟通中的理解偏差
1、必要的细节沟通时并没有确实的被传达到
多数时候造成理解偏差是因为必要的细节沟通时并没有确实的被传达到。比如产品经理说「我们需要有一个新功能，…。那么这个新功能后天可以做好吗？」。做好是一个模糊概念。产品经理的脑海里通常做好就是「功能完备后天完成后可以立即上线」。而在部分程序员的脑海里上就是「新功能，在后天可以把这个内容做出来一个功能实现版本，这当中并不包括BUG测试、细节修改等后续的内容」。双方从一开始理解目标时就已经产生偏差，后续的结果自然而然和预期不一致。
2、程序员被大量的额外事情干扰，没有专心理解问题点
通常程序员不论内向还是外向，都喜欢在写程序的时候不被打搅。因为编写程序或解决问题的思路有些时候需要一定时间的静心思考才能完成。一直打扰他们，他们的烦躁指数就会直线升高影响后续沟通的效果。
3、BUG这口锅程序员们有时候很冤
用户在使用某一产品或服务的时候，出现问题是在所难免的。这个时候如果直接将用户所提交的问题一股脑的给到程序员，然后美其名曰是「这个就是一个BUG，你需要帮我解决」。如果最后判断出来是因为产品特性或者是之前就不存在的需求造成。他们就会很不爽。因为一般来说，在程序员的认知世界里，BUG就是代码的缺陷。不是代码缺陷的问题你来冤枉我，这锅太冤了。
理解了这三点内容后，我们再来看看实际沟通的时候，有没有一些方法可以改善这3点，避免不愉快的事情发生。
我准备了5条建议给大家参考。
和程序员沟通的五条建议
1、直观描述清楚需求与目标结果
尽量直观描述描述清楚需求和目标结果，少用一些可能引起误会或者模糊性的词语，比如「应该」、「可能」、「好像」、「差不多」等等。换成更明确的内容，比如「后天这个新程序，需要完成开发和测试，后天晚上就能上线」、「我要一杯超大杯热摩卡，不要奶油」。
2、能用文字或画面描述的尽量不用口头说明
好记性不如烂笔头，口头传达总是会有一些内容无法面面俱到的。所以在遇到一些需求的时候，千万别怕麻烦，该写的说明文字、需求文档，尽量要求自己写的全面详实会更节省时间。
相信我，你写的内容不会白费，程序员绝对会开始写代码之前认真看一遍的，然后他们有所疑问的地方或需要再次确认的地方会再来找你。比一次次的口头说明效率要高很多。
3、全身心投入时候尽量少打扰程序员
程序员们通常效率最高的时候，是在有思路并可以安静连贯做事情的时候。如果看到程序员一动不动的在那里盯着程序编辑器一动不动，尽量不要立即去打扰他。可以利用IM约一个时间找他。或者是固定一个时间找他。让他有整片时间能够完成好手头的事情。当然十万火急的事情就别遵循这一条了，解决问题最重要。
4、戒急戒躁真诚沟通一定能解决
与程序员沟通，要提前做好两个准备：
(1)坚信对方是好人
(2)坚信对方是一起和你解决问题的伙伴
是好人，就必然善良。是一起与你解决问题的伙伴，就必然很乐意一起解决问题。只要心平气和的和他们沟通，他们多半是可以共同一起解决难题的。你着急的时候，其实程序员也着急。
5、对处理BUG少一份质疑多一份沟通
这点需要对从用户那边收集来的BUG要有判断的能力，通常BUG来自于三种情况：
A.产品特性决定。有一些特殊的规则限制。
B.这个就是之前产品没有的功能或特性，是新需求。
C.代码缺陷造成的问题。
而用户一般没有办法搞清楚这三者的区别。
但实际上处理方法完全不一致，通常A是直接向客户解释反馈即可，B需要在评估过后向用户说明，如果确实需要做则再向程序员提出开发需求。C才是程序员需要去处理的真实BUG问题。
如果我们能在拿到这些反馈的时候就能够多花一点时间进行判断到底是那一个问题，就可以节省大量的与程序员沟通往来上的时间。对你和程序员都轻松。
以上就是我的思考，欢迎各位同学与我交流，一起学习成长进步。
