在《汉语词典》中,沟通有如下定义:
沟通本指开沟以使两水相通。后用以泛指使两方相通连,也指疏通彼此的意见。
沟通是通过一定的载体将思想、信息和情感在人与人之间进行传递或交换的过程,群体间的沟通最终也会落到人身上。 著名组织管理学家巴纳德认为「沟通是把一个组织中的成员联系在一起,以实现共同目标的手段」,没有沟通,就没有管理。
沟通不良几乎是每个企业都存在的问题,企业的机构越是复杂,层级越多,其沟通就越发困难。 一线的许多意见在上传过程中,被层层过滤掉了;高层的决策传达,在落到一线同学时可能表述完全不一样了。 沟通在组织中的主要作用是上传下达,相互协调,以维系组织存在,保持和加强组织纽带,创造和维护组织文化,提高组织效率。
沟通由四个要素组成:沟通目的、沟通对象、沟通内容和沟通方式。这四个要素是相辅相成的关系,缺一不可。这四个要素回答了四个问题,为什么要沟通;和谁沟通;沟通什么;怎么沟通。
沟通从种类上来分,可以分为语言沟通或非语言沟通、口头沟通和书面沟通、正式沟通和非正式沟通,向上沟通、向下沟通和平级沟通等。
在管理上执行一个动作或者做某个事情需要有目的,不要做无效的管理。就沟通而言,第一是要明确沟通的目标。 结合团队战略目标,将沟通目标融入战略目标中,基于此开展沟通内容和沟通目标的准备,以减少不必要的沟通事项,降低沟通时间成本和人力成本,毕竟任何动作都会有成本。
很多时候,沟通的当事人并没有非常清晰的目标,只有一个大概的逻辑,目标很模糊。在这样的情况下进行沟通,比较容易造成混乱和无效沟通。所以,技术管理者作为沟通的主体,就必须先帮助当事人确立清晰的目标
在确定目标的基础上,我们需要正式就具体的沟通做好准备,一般包括:
沟通内容和沟通对象强关联,比如一线开发可能准备的沟通内容是具体的工作计划,具体的目标,对老板的沟通可能是技术方向的规划,阶段性成果以及一些管理思路等等。
准备好沟通后下一步是执行沟通。
沟通过程本质上是一个信息传输的过程,信息传输的模型如下所示:
沟通过程中主体是发送者、接收者和渠道,主要操作是编码、传输和解码。
发送者:沟通的发起者,本次信息传输的主导者; 编码:整理信息,以自己的理解和技能把信息、思想与情感等内容用相应的语言、文字、图形或其他非语言形式表达出来的过程; 渠道:信息传输的载体,常见的渠道包括:语言、电话、文档、传真、电子邮件、各种 IM 工具等; 解码:接收者对所获取的信息的理解过程; 接收者:信息接收者、信息达到的客体,可能是一个人也可能是一群人,也可能没有人。
如我们想给比较多人的讲一个事情,一种性价比比较高的方式就是写文档或电子邮件发给这些人看,这个写文档/邮件,发给接收者阅读并理解整个文档的过程就是一次信息传输的过程,也就是一次沟通的过程。
在信息传输过程中,有较多的噪声会影响整个传输的效果,比如我们刚才说的写文档,编码的过程就是我们将想法、思想和逻辑转化成文档的过程,而每个人写文档的能力,对于问题的理解不一样,从而写出来的文档参差不齐,这里的差异就是我们编码中的一种噪声。
在语言沟通过程中,除了讲,还要听,做彼此的倾听者,沟通过程中随时调整沟通的方式和方向,以求达到沟而相通的目的。 从信息传输的模型来看,这里的倾听其实就是为了更好的解码,更好的接收传递过来的信息,而调整沟通的方式和方向是为了优化编码的方式,以适配对方的解码逻辑。 汉字其实很形象地表述了听的逻辑,听的繁体字写法是「聴」,拆开来看,它要求我们听的时候要用耳朵、眼睛和心来聆听,这样你才能准确地理解他人的意思。而简体字的「听」拆开是「口」和「斤」,这仿佛在告诉我们现代人听不再用耳朵, 而用的是「口」, 而且是根据对方的「斤」两来决定到底听还是不听。
特别说一点,技术管理者在与下属沟通过程中,需要不断地增加沟通的可能性,引导下属的想法和目标,以平等的态度,梳理逻辑,让沟通状态从混乱变为清晰,从而达到沟通的目的。
沟通完成后,需要对沟通做一些回顾,以检验和巩固沟通的效果。沟通回顾包括两部分,沟通中问题和待办的跟进和沟通效果的检验
在一次沟通过程中,可能会有一些事项需要沟通后再来确认或完成,针对这些事项需要明确具体的执行人和完成时间。 对于一个组织而言,应该要有一个统一的地方或一个系统来跟进这些任务,看是否完成或达到预期。如常见的项目管理工具或者在一些文档系统中以任务列表的方式集中起来,不定时查看。
沟通回顾在整个沟通中是非常重要的一个环节,无论沟通前的准备有多么的充足,沟通中的交流有多么顺畅和精彩,没有跟进和效果的沟通就等于没有沟通。
在整个沟通过程中有一些问题我们可能会遇到比较多:
在一个组织的内部沟通中,沟通双方存在着共同利益,以及一致的目标,所以只要沟通机制没有问题,就很容易达成共识。
构建正式沟通机制是为了保证内部沟通在正式环境中,能够顺畅而有效地沟通。例如,内部的周会、月会、年会,以及各种内部的正规会议和讨论中,规范内部的目标、工作方案,以及合理化建议的渠道,并且有非常明确的奖罚制度。一个完善的正式沟通机制有如下好处:
在企业内,会议是一些人有组织、有领导地为了某种目的而进行讨论和商议的集会。 无论是大会还是小会,开会的目的都是为了通过讨论解决某个问题或做出某项决议。一个高效有序的会议,不仅能够提升工作效率,还能增强员工的参与感和创造力。
开会的最佳意义在于讨论和互动。只有在你真正需要参会人员之间的互动,需要大家分享彼此的意见和知识,并最终形成一项决议的时候,才有开会的必要。
以下是我们常见的几种会议类型。
所谓例会,都应有相对明确的主题,相对固定的参会人员,相对结构化的会议流程。 管理例会是管理者组织的由管理者及其下一级参加的会议,其主要有如下目的:
管理例会可以在各级组织召开,尽量管理者和其直接下属来开,跨多级可能会出现跨级管理的问题。
明确了会议目的,下一步我们需要明确会议内容。会议内容由于企业的不同,组织层级的不同,团队规模的不同,沟通的内容差异较大,这里我们抽象一下,以问题的形式,列出一些常规的沟通内容。
项目晨会属于进度会议的一种,其主要作用如下:
项目晨会和管理例会不同,会议中角色除了组织者和参与者,可能还有模块组织者,特别是一些大的项目团队。各自的职责如下:
由于项目中的事情比较多且杂,不可能一个个细项都在晨会上讲和讨论,我们需要有一些原则来控制会议,让整个沟通更高效。会议原则如下:
需求规划会一般存在于有良好的需求迭代节奏的组织,其组织内有计划的对于需求进行规划,评审,然后进入迭代,开发测试并交付。
这里的需求规划是指需求已经在产品内部评审过,马上要进入迭代,研发同学对于产品需求的技术合理性、业务价值进行评审的过程。
需求规划会主要的作用说得直白一点就是卡需求,为什么要卡呢?这并不是为了难为产品同学,而是因为需求一旦进入研发阶段,整个事情的投入成本就会急剧增加,如果不合理的需求,或者价值不大的需求占用了较多的资源,可能会导致其它重要或者价值更大的需求的资源变少。技术管理者为了让整个技术团队的 ROI 更高,为了后续研发效能,在需求规划会上评估需求需要看以下一些项:
项目管理过程中除了项目晨会、需求规划会还有迭代回顾会,项目总结会,项目问题解决会等等,这些会议的目的都是为了项目过程去发现问题,解决问题,在项目结束后总结问题,提炼问题为下次项目做准备。
在会议之外,我们还需要构建定期的当面交流以补充会议机制中缺少的一些内容,如一些人文关怀,一些需要深入了解和聊聊的点。
每个技术同学都希望得到指导,希望有人告诉他方向在哪里,有哪些可以提升的地方,希望在和上司的探讨中有所受益。
在 1v1 沟通前我们依据前面的沟通逻辑,要针对沟通目标、沟通对象、沟通内容做好准备,我们可以从 HR 那里拿到关于沟通对象的基本信息,把这个基础上,准备一个沟通记录表,记录表大概结构如下:
姓名 | 岗位 | 面谈时间 | 持续时间 | 面谈目标和记录 | 下一步计划 |
张三 | 前端 | 2022/2/10 | 30 min | 1. 关注当前前端技术, 2. 最近正在对跨端架构做深入了解,3. 有一些管理预期 | 观察,适当给予带小团队机会 |
面谈目标和记录将目标和记录放一起是由于两者是一个过程,在面谈开始前管理者先把目标和问题记下来,然后在面谈过程中会有一些输入,基于这些输入确认目标是否达成或问题是否解决。
在 1v1 沟通中,管理者更多的站在一个帮助者的角度,平等的沟通,从对方的角度来发现问题,解决问题。关注其日常状态,个人成长,职业发展、家庭状态和身心健康。
在 1v1 沟通中有一个简单的 GROW 教练模型,如下:
1v1 沟通在管理工作中是常见的一种沟通方式,当一个技术管理者到一个新的团队,需要和这个团队的每个成员聊聊,如果团队太大,可以考虑往下两到三级,至少要两级。初次的 1v1 交流主要是为了认识一下,熟悉一下。在初次 1v1 沟通后,对于下级或核心的同学需要保持固定频率的 1v1 沟通,固定的 1v1 沟通为工作交流,进展同步,计划跟进沟通为主。
在个人沟通的基础上,组织层面的当面沟通也是非常重要的一环节。 组织的当面沟通其实也是会议的一种,这里单独拎出来是为了强调这种沟通方式。 和常规的会议不一样,其主要是为了交流,像茶话会,闭门会议、座谈会之类的,其着重突出交流,可以没有结论。
从组织的角度来看,周报是组织流程化管理的一部分,是正式沟通地一种手段或方式,其目的是为了更好的向下管理和向上反馈。作为管理者可以通过周报了解一线的情况,如项目的进展,工作的动向;作为普通员工可以通过周报系统性地表述一线的状况。
从个人成长的角度来看,周报是个人反思成长的载体,是自我管理的一种方式,其核心逻辑是:在过去一周你的时间花在了哪里,解决了什么问题,过程中有什么思考,个人有哪些成长。
周报在我之前的文章中有细讲,可以看看:
这里重点提一下,谁来写周报,每个人都要写,特别是管理者,通过写周报了解组织内发生的事情及进展,发现组织内本周的问题。
周报需要有地方承载,其承载的地方可能是某个 IM 平台的附带插件系统,或者某个文档系统,甚至是邮件。其中文档系统是一个相对系统化的地方,除了周报这种过程性的文档,一些结果类,标准类的文档也可以统一起来。
内部文档沟通机制我们经常称之为知识平台,知识库。一般会有两个主要的作用:
一个较完善的内部文档沟通机制需要回答以下问题:
1. 文档放哪里?
文档放哪里主要是指文档的载体是什么?各家公司各有不同,有些是用的类似于飞书之类的云上文档,有些用的是开源 WIKI 系统或者在开源系统上优化后的版本,有些是自主研发的系统,最终是要把所有的文档以系统化的方式全部管理起来。当然,也有直接弄个共享盘,大家一起使用的。
3. 怎么快速找到需要的文档?
除了以上的 4 种正式沟通机制以外,我们常见的还有汇报机制、公文机制、备忘录机制等等,这里就不详细展开了。
内部正式沟通机制的建设不是一个一蹴而就的过程,需要不断进步和迭代,需要内部所有人员一起努力和不断摸索前进。 在构建过程中,我们可能会遇到沟通不畅的情况,甚至会遇到各种意想不到的反对或者针对,此时我们不能放弃构建,也不能放弃沟通。作为一个管理者必须正视内部正式沟通不良的现象,积极面对,及时地解决构建过程中可能出现的问题。
在正式沟通机制的基础上,我们还需要一些不那么正式的沟通机制,以补全整个沟通机制。
随着信息化的发展,即时通信工具发展迅猛,像微信、企业微信、钉钉等都成了我们工作中沟通交流的主要手段之一。 虽然 IM 有聊天记录等功能,但是作为一个组织的正式沟通机制却是有所欠缺的。
但是我们可以基于 IM 做一些非正式的沟通机制,如组建群,不同的群体组不同的群,以达到部分沟通的目的。 而作为一个技术管理者应该如何拉这些群呢?有一些常规逻辑:
养成事事有交代的习惯,比如请假或休假之类不在公司的情况,可以在大群同步一下,让大家知道你休假了,你手上的工作谁来对接,如何联系到你,大概格式如下:
卡神 7.25 ~ 7.27 休假,工作交接给 XXX(或者工作不交接),不定时查看钉钉,急事电联:134XXXXXXXXX
以上这个示例也有同学问了,我可以在钉钉上设置状态,为什么要再在群里发一往遍呢? 这两个操作本质上不同的,一个是主动反馈,告诉大家你的状态,让大家可以快速知道你的状态;另一个是被动查询,只有当需要的时候才来看一下,或者根本就没注意到,没法提前安排或者需要问一圈才知道找谁 来解决问题。
有本书叫《别独自用餐》,这是一本讲经营人际关系的书,但是这里我们并不是要讲人际关系,只是想用这个标题。
在非正式沟通机制中,技术管理者可以经常拉一些同学一起去吃个晚饭,或者喝一顿小酒,都是极好的,据说酒能让人看别人顺眼一点,趁酒意正浓之时,说点掏心窝子的话,互相吐吐槽,倒倒苦水。
这里就仁者见仁,智者见智,各路神仙,各显神通。
非正常沟通机制除了上面的两种,还包括电子邮件、社交活动、小型聚会等等,不仅形式灵活多变,沟通时候的内容和形式也比正式沟通更加自由,更加有利于内部人员分享信息、交流心得、增进感情;也更加有利于达成内部的统一思想和目标,明确共同的利益和方向。
无论沟通模式或工具发展到什么程度,面对面沟通仍然是不可取代的。 良好的沟通,需要知行合一的价值观:尊重他人,请认真对待每次沟通和反馈。
你好,我是潘锦,超过 10 年的研发管理和技术架构经历,出过书,创过业,带过百人团队,也在腾讯,A 股上市公司呆过一些年头,现在在一家 C 轮的公司负责一些技术方面的管理工作。早年做过 NOI 和 ACM,对前端架构、跨端、后端架构、云原生、DevOps 等技术始终保持着浓厚的兴趣,平时喜欢读书、思考,终身学习实践者,欢迎一起交流学习。微信公众号:架构和远方,博客: http://www.phppan.com