技术人如何做到高效沟通?
talk is cheap, show me the code
这是技术人经常说的一句话。意思是光说不练是简单的,但是代码实现确实很复杂的。
这句话是 linus 的语录,表明代码才是实现逻辑的关键。
但是随着我们这一行的慢慢发展,我在工作中逐渐发现,对于一些需求而言,需要返回和产品以及技术沟通,才能真正弄清楚我们到底要实现什么?
常见的一个需求沟通场景是:
- 产品:这周我们要实现一个 A 功能
- 技术:为什么要实现 A 功能?
- 产品:背景是这样的:….
- 技术:好的,我要做一下技术调研,明确一下技术复杂度
- 技术:这个功能是否需要或者是否有其他的替代方式,感觉这个需求比较鸡肋
- 产品:这是用户反馈的
- 技术:我们是否可以有别的实现的方式?
- …..
通过上面的例子,在一个产品功能落地的时候,往往是需要不断进行沟通的,从这个功能的背景,需求来源,是否合理,技术难度,优化迭代等等很多方面去进行考虑,这就需要我们不断进行沟通考量。
今天这篇文章就是讨论技术人员的职场软技能——如何做好沟通?也借此篇文章不断优化自己的沟通能力
沟通的原理
当我们与人进行沟通的时候,首先要明确一点,沟通建立的原理。
就拿 TCP 协议来说,当 C/S 双方进行沟通的时候,首先要建立起沟通的桥梁,然后是使用双方都能编解码的信息进行通信。对于人与人之间的沟通也是,也是需要建立起沟通的桥梁,例如直接对话,电话,聊天软件,然后就是使用双方都能理解的语言。这里我举几个例子,让你明白我这句话的含义:
- 中国人和中国人之间的对话
- 中国人和英国人之间的对话
- 技术和小白之间的对话
对于如何建立起沟通的桥梁而言,如果沟通双方都不能理解对方的语言,那么就形成了对牛弹琴,例如一个不会英文的中国人和一个不会中文的英国人之间是信息不通的。这也是沟通的前提,为什么很多外企都需要在招聘上写道:擅长英语口语交流。这是前提。
对于一个技术和一个小白而言,可能也会存在很多沟通障碍,例如我说:这个系统可能需要用到分布式部署的方式,要解决高并发的问题,QPS 要到 1000 左右,部署的话采用云的方式是最好的。如果我是一个职场小白,对于分布式/QPS/云部署 这些概念我是一窍不通的,那么我可能要改变我说话的方式:对于我们这个系统的设计,要解决多用户使用的问题,例如同时支持上千个用户的任务请求,秒级别的在线人数要到 1000 的处理量,部署的方式最好购买云服务器,例如阿里云。
在上面的两个对话中,我们可以清晰的知道,对于沟通而言,需要因人而异的。也就是要学会换位思考,站在别人的角度上思考沟通的方式,沟通的话术
当然,有人可能要说了,我怎么能比较清晰的知道这个人到底什么知道,什么不知道呢?
是的,对于每个人而言,我们不可能 100% 知道这个人的知识储备,于是,反馈机制就很重要,就类似 TCP 协议中的重传机制(这个例子可能不好),对于我说的每一句话,对方是否知道,是否知道我的意思了。
这里还是借上面的机制来说明:
- 我:这个系统需要分布式的方式来进行部署,要解决高并发的问题。
- other: 什么是分布式部署啊
- 我:可以理解为多台机器协同的方式,这样比较稳定
- other:什么是高并发呢?
- 我:可一理解为,同一时刻可以满足多人的任务请求,例如 1000 人同时在线且在提交请求。
这个时候通过一问一答的方式,就建立起了反馈机制。这样可以解决信息的偏差问题
最后一点就是信息的完整性
对于领导或者同事的任务要求,最好是保证其原来的面貌。对于一个公司而言,信息往往是从上到下的,从一个理念到具体的实现,往往情况就是通过一层层的传导,信息的原貌会逐渐破坏。
例如下面这个经典的图:
所以在传导信息时,最好加上信息的源头,现在的聊天软件,例如微信的引用功能,就能让我们知道每句话的理解来自哪里。
沟通中的阻碍
在日常工作中,你可能经常会听到某人说,这个人挺好沟通的。对于沟通的一方而言,其实比较关注的是我如何能在最小代价的情况下,获取到信息,那么导致这些阻碍主要是哪些方面
那么如何提升准确性呢?我将从以下几个方面来阐述:
- 信息的不准确
- 信息太多
- 表达方式
- 二手信息
信息的复杂度
对于首次发起沟通的人来说,你可能在沟通之前需要思考一下,如何构建自己的语料。如果你自己都不能明确知道你将要说的话,那么我建议你在说话之前先整理一下将要进行沟通的语料。
常见的方式就是用文本化的方式整理出来,这也就是为什么很多公司在进行产品设计的时候,需要产品故事(pstory)、用户故事(user story),需求详设等等,这些文本化的东西都是针对不同的受众而言的。
对于一个复杂的需求而言,如何去文本化,如何拆解,是很重要的,也很考验我们的语言组织能力。当然,如果你认为个人的对话能力有限,就采用文本的方式进行沟通,如何提升自己这方面的能力呢?其实就是多练,多沟通。
当然,对于你的领导同事而言,你可能有一些个人的想法需要包装,害怕太直接导致沟通受阻,于是就提升了信息的复杂度。
在我以前的工作中,当一个需求来的时候,我很多时候其实是不太了解其中需求的难度的,于是我通常会直接说明,需要时间去调研分析,而不是支支吾吾害怕暴露自己的技术水平,因为对于技术人员来说,技术是永远学不完的,没有谁能什么都懂。有话直说,这是最高效的沟通方式,也是对对方的一种尊重和信任,这样下来,事情往往更好解决。
信息的交互
相信很多技术人都会遇到一个情况,那就是开会的时候,你的领导在介绍完一个技术或者说明一些部门情况时,往往会说一句:大家还有甚么问题吗?这个时候很多人都会沉默不语。
这个时候信息的交流就变成了单向沟通,时间一长,对于部门的问题是很大的。
所以,对于这种情况,要能站在对方的角度上思考问题,降低表达自己真实想法的门槛,培养让大家畅所欲言的自由环境,引出一个问题,然后让大家思考表达,这样也许会更能了解大家的想法。
信息的来源
由于信息在传递过程中会有一定的损耗,导致信息即使在没有主观意识上的修改之外,也会存在变化,故到信息的源头去,向当事人求证,会让这个世界更加和谐,也会让你变得更加有智慧。
信息的透明
我们知道,在网络通信中,信息是有被篡改的风险的,如果当你想要向别人传达信息时,一定要保证信息的公开透明,而不是让其他人帮你传递信息
沟通的方式和技巧
好的沟通有多种表现形式,最常用的组合是:尊重,倾听和情绪控制
尊重
尊重是沟通的前提,在你和对方进行沟通时,一定要尊重对方的观点:
- 我可以不同意你的观点,但是我会捍卫你说话的权利:即便对方的观点你暂时是不同意的,也要尊重对方想要表达的欲望,这也是一个沟通的过程,当沟通多次后,你会发现,可能一开始你不同意的观点也是有可取之处的。
- 赢得对方的尊重首先要尊重对方:在你表现出对他人的尊重后,你也能赢得对方的尊重。
沟通的目的不是去为了反驳或者附和对方,而是思维的碰撞,沟通是为了获得更完整更全面的认知。
倾听
在 《沟通的艺术》这本书中将倾听定位为沟通的第一要则,足见其重要性。
我们之所以要倾听,是因为倾听可以让我们获得更多的信息,对对方有更多的了解。倾听能让对方感觉到自己被尊重,才会和你分享更多的信息。
情绪控制
能否控制好自己的情绪至关重要。如果不能控制自己的情绪,那么将让沟通难以进行。具体应该怎么做呢?
不要过早或者过度打岔和反驳:对于有些观点,知道事情的来龙去脉是很重要的,所以要听完别人的话后在进行分析理解,给予反馈
求同存异,冷静客观:每个人的知识储备,生长背景,经历和性格不同,所以在看待问题时,自然会有很大的差异,所以要懂得尊重差异,客观公正地思考问题,并给出建议和方法。
切勿冲动给出一些观点或者说出过激的话,因为言语的杀伤力是很大的,难以估计
当然,人是情感动物,有时候在你和别人对话时,你不知道当时这个人所处什么样的情绪之下,有时候你不经意的一句话可能会让对方难以接受,所以要慎言慎行,察言观色,当发现沟通难以进行时,应及时反馈领导或者终止沟通,待环境变好时再进行。本人就是个急性子,所以也还在修行当中。
引起对方的兴趣
当你想让别人能够对于你的话题或者观点重视时,你就要引出一些让对方感兴趣的话题。例如我在一次团队分享时,我为了引起大家对 CodeReview 的重视,我的分享标题是:《Codereview 是如何降低我们的开发效率的》,文章一开始阐述了 CodeReview 需要我们关注的点,如何难以进行导致我们开发效率变低,引出 CR。然后再阐述 CodeReview 的优点,最后表明了 CodeReview 在长期发展下,反而提高了我们的开发效率和代码的稳定性。
直达主题,强化观点
当你想表达一个观点事,最好是强调重点,而不是一开始从细节上谈实现。但很多时候产品需求都是很模糊的。而且很多时候,整个世界都是模糊的、有歧义的。有的人这么说,有的人那么说。你都不知道自己该信谁。所以亚马逊要求员工有一个能力就是,你一定要有把模糊的理解变成准确理解的能力,因为如果不这样,你是写不出代码来的。
确定自己的目标,学会抓重点,知道自己要什么和不要什么,这样你要的才会更鲜明。当一些事情变得简明和鲜明起来时,你才会表现出有力量的观点和话语。而这些被强化过的观点和话语,只需要一句,就会在对方脑子里形成一个小爆点,要么击中了对方的软处(扎心),要么会让对方产生深度思考。
基于数据和事实
第三是用数据和事实说话。你跟别人沟通,要尽量少说“可能、也许、我觉得就这样”等字眼,你最好通过数据和证据,通过权威的引用和证词,通过相关的实例和亲身的事例来让你的观点有不可被辩驳不可被质疑的特性。当你的信息出现了这样的特性时,接收信息的人,基本上来说,就会无条件地相信。别人会无条件地相信你说的话,你想想这是一种多么牛的沟能方式!
沟通的技术
- 逻辑学
- 信息 X/Y 的问题
- 纬度
- 共同点
待补充