沟通

随着融入工作的程度越来越深,沟通所花费时间的占比会越来越高。为了自己和他人都能用尽量短的时间进行沟通,需要集中注意力工作的过程中少被突发的沟通打断,我们有必要对沟通的风格、方法、工具做一些说明和约定。

为什么需要沟通

更好地完成自己的工作,需要上下游配合。良好的人际关系和沟通技巧,会得到更高意愿的配合。

做成更大的事,就需要联合其他人一起工作。协同工作需要共识,共识是沟通的结果。

承担更大的责任,需要获得信任。信任是多轮沟通并获得良好反馈的产物。

沟通模型

沟通过程模型

沟通过程模型是指信息发送方(可以是个人或群体)借助语言、文字、动作及表情等载体 (也称媒介),将知识、思想、情感等信息送达信息接收方(可以是个人或群体)的过程模型。

沟通过程模型
Image 7.1.1: 沟通过程模型

其中包括沟通双方,即发送方和接收方。

  • 发送方负责信息的传递,需确保信息的清晰性完整性,需要确认信息已被正确理解。
  • 接收方负责确保完整地接收信息,正确地理解信息,并需要告知收悉或做出适当的回应

媒介是指技术媒介,包括沟通模式,而噪声则是可能干扰或阻碍信息传递的任何因素。

  • 沟通媒介效率排名:当面语言 > 语音 > 电话 > 即时消息 > 邮件。
  • 但从保留的信息多寡和信息明确度来看,越来越少。所以邮件常用来留底案,应付纠纷。
  • 从对工作安排的侵入性考虑,异步的邮件、即时消息,比当面或电话友好。

基本沟通模型中的步骤为:

  1. 编码。发送方把思想或观点转化(编码)为语言。
    • 发送方的编码需要考虑接收方的话题背景、知识背景、情绪水平、认知水平。话题背景就是新加入者能够快速理解话题的上下文背景。知识背景常出现在跨部门沟通上,产品经理既会和运营沟通,也会和开发沟通。这两类人的知识背景很有大差异,需要做好名词的转化和解释。
    • 从传达信息的效率来看,文字大于其他表现形式。
  2. 传递信息。发送方通过沟通渠道(媒介)发送信息。
    • 信息的传递可能受各种因素的干扰,如距离、不熟悉的技术、不合适的基础设施、文化差异和缺乏背景信息等。这些因素统称为噪声。 沟通漏斗模型
  3. 解码。接收方把信息还原成有意义的思想或观点。
  4. 告知收悉。接收到信息后,接收方需告知对方已收到信息(告知收悉),但这并不一定意味着同意或理解信息的内容。
  5. 反馈 / 反应。对收到的信息进行解码并理解之后,接收方把还原出来的思想或观点编码成信息,再传递给最初的发送方。

于是可以看到,一个消息的生命周期包含五个状态:已发送,已收到,已理解,已认可,已转化为积极的行动。这中间每个状态都比前一个更难。

  1. 已发送 (Transmitted): 当你发送一封电子邮件或者留下一个语音电话留言,你正在传送信息给他人。这并不表示对方已经读取或听到了,电子邮件和电话也只是帮助我们快速传递信息却不能保证对方准备读取它。这仅仅是信息已发送的状态。
  2. 已收到 (Received): 当对方检查新邮件或者打开语言留言的时候,信息已收到。但这并不表示对方有任何意图去读取、理解或解决电子邮件中的问题。换句话说,对方收到电子邮件,仅此而已,没有任何问题已得到对方确认。
  3. 已理解 (Understood): 正确的消化和理解信息中的内容是简单接收信息中关键的一环, 通常理解需要一定的上下文背景知识,需要对其中某些内容提出问题,或向发送者进行确认或澄清等步骤。
  4. 已认可 (Agreed): 理解了传达的信息并不代表对方已同意这个观点。或许对方明白了你的意思,但完全不同意或者认为这是个糟糕的主意。所以在两个聪明的有主见的人之间达成一致是一项复杂而又消耗时间的事情,尤其是两个人的观点又都不能非常明白清晰的向对方阐述的时候。尽管如此,达成一致仍然是做出项目决策和有效沟通的关键一环。
  5. 已转化为积极的行动 (Converted to useful action): 尽管正确的理解和达成一致的认可是多么的困难,更加困难的是让对方转化为实际的积极的行动,而且是方向正确无误的行动。这是整个过程中最难的一环,通常需要反复的沟通、一定的监督或帮助下才能较好的完成。

对发送方而言,发一封电子邮件,或来到某人旁边谈话的时候,只是一个沟通的开始。发送方有责任跟踪发出消息的状态变化。如果沟通未达目的,可以参考检查这个模型的哪一步出现了问题。

非暴力沟通

非暴力沟通是一种谈话和聆听的方式以及看问题的方法。非暴力沟通的四个要素:观察、感受、需要、请求

将其组织成一个句子说出来,大致会是这样的:“我观察到……。所以我感受到……。我的 xx 需要(或愿望)导致我有这样的感受。为了改善生活,我的请求是……”

四个元素不是非得说出来,或是以这种方式说出来,关键是其中的内容都集中在 “看到、感觉、需要、请求”,而不是指责 “做了什么、的行为让我不爽、毁了我的 xx 需要、所以应该 / 必须如何做”。

  • 不带评论的观察 将观察和评论混为一谈,别人就会倾向于听到批评,并反驳我们。
  • 区分感受和想法 如果我们通过批评来提出主张,人们的反应常常是申辩或反击。反之,如果我们直接说出需要,其他人就较有可能作出积极的回应。
  • 提出具体的请求 我们提出的请求越具体越好。如果我们的意思含糊不清,别人就难以了解我们到底想要什么。

    通知开会说明时间和地点;索取技术要求文档明确指出要求完成时间;提软件开发需求的同时介绍项目阶段或已经签订的交期。

    • 是提出请求而不是命令。 如何区分命令和请求:请求没有得到满足时,提出请求的人如果批评和指责,那就是命令;如果想利用对方的内疚来达到目的,也是命令。
  • 倾听使身心痊愈 如果一个人想要别人了解他的处境,听到的却是安慰和建议,那么,他就有可能觉得不太舒服。

    哪些行为会妨碍我们体会他人的处境:

    • 建议:“我想你应该……”
    • 比较:“这算不了什么。你听听我的经历……”
    • 说教:“如果你这样做…… 你将会得到很大的好处。”
    • 安慰:“这不是你的错;你已经尽最大努力了。”
    • 回忆:“这让我想起……”
    • 否定:“高兴一点。不要这么难过。”
    • 同情:“哦,你这可怜的人……”
    • 询问:“这种情况是什么时候开始的?”
    • 辩解:“我原想早点打电话给你,但昨晚……”
    • 纠正:“事情的经过不是那样的。”

    试图分析问题妨碍了我们与他人的联系。如果我们只关心别人说了什么,并考虑他的情况符合哪种理论,我们是在诊断人 —— 我们并没有倾听他们。

  • 感激和赞扬 赞扬也可能造成人与人之间的隔阂。当赞扬者的身份是裁判或者表达感激是为了谋求某种回报时,对方对赞扬、感激就会心存疑虑。

找谁沟通

也就是上文模型中接收方的选择。

为了有效沟通,一定要找对人。如果一个评审,需要给评审结论签字负责的人没来,其他人也就不必继续会议了,会议发起人应当直接决定改期。如果一个跨部门会议,对方的拍板人未到,安排了一位代表,但没有明确授权做决定或是在会议中表现出不做决定、回去汇报再定的态度,会议发起人也应当避免继续做无效的沟通。

项目增加一个新需求,项目经理是软件工程师兼任的,召集了几位相关的开发工程师讨论如何实现新需求。够了吗?如果测试工程师直到接到测试委托申请单时(甚至更晚)才知道这个需求,原先的测试计划就失效了。

总之,找到能满足你沟通目的的那个(些)人,再进行具体的沟通。

接口人

沟通参与者为N的时候,沟通的通道数为 。为了降低沟通的复杂度,就产生了接口人。

通过分割沟通参与者为更小的组织,组织间通过接口人传递信息,可以大幅减少沟通通道数。

交互接口人
Image 7.1.2: 交互接口人

建议的沟通原则

通则

  1. 尽量采用异步沟通,给对方回复前思考的时间。
  2. Issues 优于 email;email 优于即时通信。工作的常态应当是不被即时通信工具打断的
    • 基于话题组织的信息流是最高效的形式。

      到 2022 年底,70%的团队将依靠工作流协作作为团队成员之间沟通,协调和共享信息的主要手段,取代电子邮件。 ——Gartner

  3. 如果提及一个对象 (a merge request, issue, commit, webpage, comment, etc.),请附上一个超链接。
  4. 当别人要求你在某个时间前回复或完成某项任务时,判断是否可以在 2 分钟内完成。
    • 如果可以,完成并回复。
    • 如果不能,评估该工作的耗时,并回复。

      “收到” vs “我计划在 xx 时开始/完成/回复你”

      后者好得多。因为对方可以把这件事暂时抛之脑后,或是因为你回复的时间与计划冲突而选择另行安排该工作。

  5. 说事实,不评价。

    例: “在你发给我的资料里,我还没搞清楚怎么做到 xxx 的描述” vs “你发我的资料有点乱,里面没有xxx”。

    如果你的目的是 xxx,后者无助于达到目的。

    形式、态度、内容应是为沟通目的服务而选择的。

  6. 具体化。尤其是传递数值信息时。
    • 减少沟通次数

      “这轮发现的缺陷数有所降低。”

      “多少?”

      “12个。”

      “上次测试时是多少?”

      “19个。”

      如果是面对面沟通,这个对话没问题。如果是email或者企业微信,可能会多出几分钟到几十分钟的查看/回复时间。

    • 影响决策

      “备选型号虽然好,但是成本高了3倍。”

      “那不变了。” // 因成本的巨大差异直接作出决定。

      vs

      “备选型号虽然好,但是成本高了3倍。原来那款1毛钱,新的3毛2。”

      “总成本多少?”

      “230。”

      “两个型号差别在哪里?对产品性能有什么影响?” // 成本已经不再是决策考虑因素,开始转而探究其他。

      ……

    • 增加说服力

      “很多客户反馈这个产品不好用。”

      vs

      “在xx合同中,用户说xxx;xx合同和yy合同的用户也表达过类似的意见。”

  7. 如果一件重要的事不只是事实描述,而是包含了情绪和态度的表达,选择当面沟通。这样表达更充分,不易引起歧义或猜疑。

    注:根据加州柏克莱大学心理学教授马伯蓝比教授 (Albert Mebrabian) 提出的 7/38/55 法则:旁人对我们表达内容的信任程度,7% 取决于说的话本身,38% 取决于语音语调,还有 55% 取决于身体语言。 当一个人说话的语调、面部表情和肢体语言,与其说话的内容不一致时,人们倾向相信语调、面部表情与肢体语言,而不是他所说的话。

  8. 当接收信息的时候,把重点放在说了什么(内容),而不是怎么说(表达方式、态度、语气)
    • 区分感受需要,尝试识别隐藏的需要。

      “我觉得你不喜欢我了。”

      vs

      “我希望你每天多花半个小时陪我聊天。”

    • 如果沟通的目的不是接收信息,而是建立关系,则不适用。请采用前文关于倾听的方法。
  9. 编码信息时,应根据收件人考虑自己所能做出的假设。不确定时先澄清假设。编码只能基于接收方的常识(主要体现为词汇、熟悉的概念)。

    例:报故障时,能否假设对方知道我的运行环境?分析和回复故障反馈时,能否假设对方的运行环境是和本地相同或相似的?

    跟业务和客户沟通时,说“API 验证权限不了”、“ 调用 gRPC 服务失败”,对方是否知道系统为什么出了问题?

  10. 参考有效沟通流程模型 有效沟通流程模型

企业微信

  1. 工作讨论首选企业微信,而不是微信。
  2. 即使用微信、企业微信这样的工具给他人发消息,也不应预期对方能在短时间内回复。需要即时回复的消息,就不该采用异步方式沟通。
  3. 企业微信是异步通信方式,一般来说,4 小时内回复是可接受的。
  4. 根据讨论的话题,尽量选择群聊而不是私聊。这样做可以更容易让其他人加入讨论。

Email

  1. 每个话题独立发送一封邮件。在一封邮件里包含多个话题会导致回复的延迟或者漏回复某个话题。
  2. 即使自己不需要做任何动作,也应回复(To自己的)邮件。这样对方才能区分你收到与否。视上下文回复“收到”、“OK”、“谢谢”、“done”都可以。
  3. 转发邮件时,请在正文里写明需要收件人做什么。比如“FYI”、“请你跟进此事”、“请你帮忙看下这个问题是什么原因”、“请知悉”。这可以让收件人迅速判断邮件的重要性和责任人。
  4. 邮件是异步通信方式,一般来说,24 小时内回复是可接受的。
  5. 如果需要对方更快地回复,可根据时间要求选择企业微信、电话联系对方,告知需回复的邮件主题。

演示文稿

  1. 每一页讲稿的标题应当是该页的 take-away message,而不是话题或者主题。

    例:应采用“今年销售额增长超过 2 倍”作为标题,而不是“销售额增长”。

会议

  1. 每个内部会议都建议建立一个 GitLab issue。如果一件事重要到需要2个或更多人走进会议室,那么它也足够重要到应当开个 issue 记下来。
    • 会前由召集人填写议题后,在会议通知邮件中包含该 issue 链接。
    • 会中实时编辑 issue 内容,形成会议纪要。决议中的待办事项用 - [ ] 方式添加 checklist。
    • 会后跟踪 checklist 完成情况。仅当清单所有项被完成或经追加讨论拒绝后,close 该 issue。
  2. 项目例会建议安排在周二、周三、周四,避开周一或周五。进度汇报的内容需要时间准备,会议决议的待办事项需要时间执行。
  3. 会议中级别高的人尽量少发言,尽量最后发言,这样才能让大家畅所欲言。否则一旦定调,后面就是一言堂。
  4. 大会上对议题进行宣布、通过;小会上对不决的实现进行细致讨论。

电话

  1. 如果一件事通过异步方式反复沟通 3 次未果,打电话。
  2. 如果需要多人同时参与,可以用企业微信的群视频通话。
  3. 多人电话时,建议用耳机。

安排任务

  1. 安排任务要介绍背景(来源、目标、目的)。一个任务的执行过程是方法和路径的选择,讲清楚最终要处在什么状态,对于执行人从当前状态出发选择路径是有帮助的。

    例:“这个按钮改成红色。” vs “因为xxx(一致性、设计规范、心理学等等),这个按钮改成红色。预计能提高xx指标。”

    安排任务时,你面对的是人,不是工具人。

  2. 从宏观到微观,一层层逐步推进,渐进式形成共识。避免过早地陷入细节的权衡。 关注点推进模型

表达方式

  1. Git中存储的文字内容,用 Markdown 而不是 RTF 写。这样容易复制粘贴、合并。
  2. Git中的markdown内容,使用 Unix style (lf) line endings,而不是 Windows style (crlf)。为此,你需要在仓库的 .gitattributes 中增加 *.md text eol=lf
  3. 写超链接时,不要用类似"这里" 或 "点击这里"的字样作为锚文本。链接的锚文本应当是连接对象的相关文字

    例:请查看部门员工手册,而不是 请点击这里查看部门员工手册。

  4. 表示时间
    • ISO dates 表示日期来避免误解。 使用 yyyy-mm-dd 的形。

      例:用2015-04-13。不用 04-13-2015, 13-04-2015, 2015/04/13 这样的形式。

    • 生产服务器上使用 UTC 时区。
  5. 如果邮件里出现列表,请使用 numbered list。这样对方回复时可以用序号指代。
  6. URL 中优先使用-而不是_。优先使用小写字母。
  7. 尽量不用缩写。你无法假设对方知道缩写的具体含义。

    例:写 merge request,而不是 MR

References

  1. GitLab Communication
  2. 产品经理需要了解的沟通过程模型
  3. 团队管理中的有效沟通
  4. 团队管理中的有效沟通(续)
  5. 腾讯 CDC:如何有效进行跨团队、多角色的沟通?
  6. [阅读]《非暴力沟通》书摘及感想

results matching ""

    No results matching ""