前言
大多数软件开发人员最希望做的事就是，躲在一个角落里，静静的写代码。但现实是残酷的，与他人交流和沟通是当前软件开发人员必备的能力。经常看到一个技术人员与一个产品经理争论，PM:你这功能是怎么开发的？DEV:就是按你提的需求做的啊，是你需求有问题。OK，只要到了这一步，基本就会演变成相互质疑能力，不欢而散，甚至有可能变为真人PK。本文就结合模拟的一次失败的沟通，来聊聊沟通中常见的问题。
背景
不少人书读了不少，理论也都了解，但真正亲身经历时往往都抛到脑后，成为基因的傀儡。
这次模拟的失败沟通是在一个小型会议发生的，参会者不多，大概五六个吧，有一位是高层管理人员，其余都是软件技术骨干以及部门中层。本来一切都没有什么特别的，会议主要议题就是系统模块化的下一步工作。首先高层C和业务部门B表达一下市场对于模块话的需求，然后是A作为软件技术部门来介绍当前情况，目前系统的实际架构和本来的规划。
A：系统本身已经是模块化了啊
B：就提模块化了？那能直接卖么？
A：一脸无奈，然后试图解释目前的架构是怎么实现模块化，什么微服务啊，中间件，组件化啊，巴拉巴拉一大堆。
B: 也很无奈，表示你到底说了个啥，到底能不能单独卖？
A：能啊，但是需要目前系统业务支持，需要XX业务，需要XX基础信息支持。。。。又是一大堆。
B：那就是不能卖啊，还是没有达到模块化
A：咱们系统定位就是需要跟业务有一定耦合啊，与业务彻底解耦，也不是导致领域扩大，竞争者大幅增加。。。。
B：你只需要将精力集中在技术上，业务问题我们负责
A：业务和技术一定要相互配合啊，这样能降低反馈环节，提速增效。
B：。。。。。。总之你是错的
A：。。。。。总之你是错的
后面话题就彻底乱了，讨论了半小时最后也没有直接的结论。现在回想起来也是十分的搞笑，两人一直不在一个频道上，也不试图相互理解，但在特殊的环境下，视角会受到限制，进入到证明对方是错误的状态。
此次沟通中存在的主要问题
定义问题：双方对于要讨论的东西(模块化)没有一个统一的认识和定义。
PS：10分钟内，问1000个软件技术人员什么是模块化2遍，你会得到1500个答案。
视角问题：沟通仅从自己出发，对于对方的角色和视角认知不够。
姿态问题：总是在防卫，随时准备战斗。
方式问题：先给人贴标签，对人不对事。
场合问题：注意沟通的环境以及沟通对象不同，这次沟通是在会议上，尤其是由高层领导在场，谁也不想承认自己的错误，都试图在理解自己
怎么办
时刻警醒，注意区分X/Y 问题以及共同定义问题
Stack Overflow 上有个问题，问的是“怎么截取一个字符串的最后三位？”大家给了一堆答案。突然有个人问：“你为什么要截取字符串的后三位？”他说：“我要找文件的扩展名”。实际上，文件的扩展名不一定是 3 个字符，而且有专门的函数干这个事儿，不需要自己写。这里，取文件的扩展名，这叫 X，取文件名的最后 3 个字符，这叫 Y。他想知道 X，但不知道该怎么说，于是就说成了 Y，导致别人都去解决一个不存在的问题。这叫 X/Y Problem。
适时停下来，跳出证明状态
当进入互相证明状态时，唯一能拯救这次沟通的就是停下来，冷静一下，喝杯水或是洗个脸也好，重新审视一下自己的目的，根据场合和对象调整状态。
试图共情，共享，共利，共识
首先是共情，跟对方相互分享各自的情感，这是一种拉近距离最有效的手段，然后是相互共享自己的观点，在观点中寻求双方共同的利益点，然后不断地循环，一点一点地达成共识。
个人反思
反思并不是只是一次，而要多问几个为什么，一旦问到你觉得不舒服了，就知道已经来到了正确的地方。
比如本次的反思过程：
为什么会沟通不畅议题偏离？
层次0反思：注意统一沟通中信息的同步，本次没有及时发现沟通中大家对于模块化的定义是不一致的
为什么会进入到互相证明对方是错的状态？
层次1反思：事先的标签对方不懂技术/业务的标签，一直是说教姿态和以说服为目的。
为什么会认为对方是错的，自己是对的？
层次2反思：再一次验证卡耐基的《人性的弱点》的观点：人最关心的就是自己，一旦自己的观念没有被他人接受时，本能反应就是证明他们是错的。
为什么没有及时停下来？
层次3反思：过于想让别人来认同自己，缺乏自信的表现。存在焦虑和自卑的情绪。
改进
- 承认自己的水平有限，不断的完善自己
- 每次发言前要试图从对方的角度来审视自己
- 积极主动的认可别人，认可别人是一个良好的开端
引用
文中不少内容出自一下专栏，就不再一一列出了。
- 《技术管理36讲》的34讲
- 《左耳听风》的103讲
- 《朱赟的技术管理课》的08讲
