前言

大多数软件开发人员最希望做的事就是，躲在一个角落里，静静的写代码。但现实是残酷的，与他人交流和沟通是当前软件开发人员必备的能力。经常看到一个技术人员与一个产品经理争论，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讲

以一次失败的沟通，来聊聊技术人员沟通中常见的几个问题相关推荐

聊聊电商系统中常见的9大坑，库存超卖、重复下单、物流单ABA...
做为一名程序员,发展方向大致可以分为两个方面:一个是业务架构,一个是技术架构(中间件方向). 业务架构,取其核心关键词,主要是围绕这不同的业务场景.业务规则,完成业务系统的落地建设,为用户提供在线化的 ...
产品经理小技巧（一）—— 如何和开发人员沟通
作为一名产品经理,与技术人员沟通是其工作内容的重要组成部分,但是沟通的过程却常常产生激烈的思想碰撞.很多时候因为沟通遇到的问题产品经理会觉得技术人员是"不可沟通"的,技术人员会觉得 ...
阿里资深HR和你聊聊技术面试
你和高薪架构师差的不只是年龄前言最近作为面试官,参与了多场专场面试,短期内大量的面试,面对不同风格,性格迥异的面试者,让我对面试这件事本身产生了一些思考,结合自己的一些理解和技术领域特有的定级制度 ...
以我失败的职业经历：给初入职场的技术人员几个小建议
道哥的第 024 篇原创文章目录先说声抱歉,斗胆了为什么突然想写这篇文章不管怎样,一定要考研在小公司如何混在技术上,一定要往深度钻请教别人,一定要虚心趁年轻,多吃苦既要埋头干活,也要 ...
聊聊技术、利基市场、激情与梦想
Wake up every day with a feeling of passion for the difference technology will make in people's life ...
即使是一个技术人员，也需要知道沟通的重要性
先来讲一个笑话: 有一个人请了甲.乙.丙.丁四个人吃饭,临近吃饭的时间了,丁迟迟未来.这个人着急了,一句话就顺口而出:"该来的怎么还不来?"他听到这话,不高兴了:"看来我 ...
linux got分析,聊聊Linux动态链接中的PLT和GOT（３）——公共GOT表项
前文(聊聊Linux动态链接中的PLT和GOT(2)--延迟重定位)提到所有动态库函数的plt指令最终都跳进公共plt执行,那么公共plt指令里面的地址是什么鬼? 把test可执行文的共公plt贴出来 ...
私家车合乘系统 matlab,适用于预约拼车的合乘人员沟通方法及其系统的制作方法...
适用于预约拼车的合乘人员沟通方法及其系统的制作方法 [技术领域] [0001]本发明涉及拼车技术领域,更具体地涉及一种适用于预约拼车的合乘人员沟通方法及其系统. [背景技术] [0002]随着车辆的急 ...
《团队激励与沟通》第 5 讲——沟通的技巧重点部分总结
文章目录前言一.简答题二.排序题总结前言随着社会经济的发展,在软件开发的过程中需要团队合作,在团队中通过有效沟通和激励可以使工作状态更好,从而设计和开发出完善的软件产品.因此作为软件工程专 ...
《团队激励与沟通》第 3 讲——沟通概述与沟通过程重点部分总结
文章目录前言一.简答题总结前言随着社会经济的发展,在软件开发的过程中需要团队合作,在团队中通过有效沟通和激励可以使工作状态更好,从而设计和开发出完善的软件产品.因此作为软件工程专业的学生,需 ...

以一次失败的沟通，来聊聊技术人员沟通中常见的几个问题

前言

背景