如何沟通：掌握正确的沟通流程

写这篇文章的直接动机是我在社区和工作中听到、看到的一些问题，在B站视频《我是学生我很闲求带我贡献Github装逼》中，一个自称哈工大的研究生发了一个看似态度很好，但实际上非常不尊重别人的comment，我只能说太tm真实了，我甚至能脑补出伸手党的语气：怎么啦，我好意参加项目，好声好气求人都不行？

对，不行。

与提问的智慧

通常，人们会推荐他们去读一读《提问的智慧》这篇文章。如果你访问GitHub有困难，也可以读读HITSZ-OSA的标注版本。这篇文章从提问前、提问时、解答答案这三个方面给所有人以建议，是一篇非常好的入门文章。
我不想重复这篇文章的内容，但是我想从我自己的经验来谈谈我在社区和工作中遇到的问题。首先我会给出一个两个分属不同小组的开发人员沟通失败的案例，分别从他们的角度看看他们的想法和行为出现了什么偏差，最后给出一个我自己的经验总结。

从一次争吵说起

故事、人物纯属虚构，这里不假定小红或小明的族裔、性别等等，这个名字只是为了写作之便

同学A和同学B分属于同一产品的两个不同的小组，同学小红的服务A为同学小明的服务B提供后台支持。在功能测试中，测试人员发现某个功能在A服务发生未捕捉的错误时，似乎会出现显示不正确的情况（事后证明是测试人员未刷新页面，实际上这个功能没有问题），于是提出了一个Bug并指派给了小红，小红为了解决这个Bug，在未对代码进行确认的情况下，设想了一套解决方案：在A服务向B服务报错时，B服务将这条请求的所有操作回滚。为了让小明实现这个方案，发生了以下对话：

小红：小明，我想请教你一个问题，你看看这个你能不能做
小红：测试提了一个BUG，在前端向服务B请求的时候，我这边服务A报了个错，然后这个请求记录就出现不正常的情况了，我想问问你能不能在服务B这边做一下，如果服务A报错，就把这个请求的所有操作回滚
小明：为什么是这样？你看过原来的设计吗？这个是需求要求的吗？在原来的设计中，这里是单向的异步任务，这里应该是服务A生成有一条错误记录，而不是回滚服务B。我记得需求也是生成错误消息而不是无事发生吧？
小红：但是错误记录是后面生成的，这里服务A是在最前面就抛错了，我没有捕获这个错误

其实这个时候已经很明确了，小红没有听懂小明的意思，也没有查看过之前的设计

小明：服务B这里依赖了其他组件，无法做回滚
小红：那好吧，你不做的话我也没办法，因为这里是服务A在最开始就报错了，没有进入后面的流程
小明：你是不是没有理解我之前的方案然后又重复了你说的话？
小红：是啊
小明：那就没什么好说的了，你先想明白再说吧（态度很差，摔门而去）

这个时候小明已经很生气了，因为小红没有听懂他的意思，只知道自说自话，小明觉得小红在浪费他的时间

最后，小红反馈小明太过敏感，太过严格，情绪化严重，不配合别人工作。

小明反馈小红擅自修改设计，不听别人解释，不了解背景就提出方案，不尊重别人的工作。

让我们看看他们都在想什么

小红想的	小红说的	小明说的	小明想的
我的方案需要小明修改，我需要向他确定能不能做	小明，我想请教你一个问题，你看看这个你能不能做	/	我的模块出问题了？还是这是在给我派活？
我向小明描述想让他做的事就好了	测试提了一个BUG，在前端向服务B请求的时候，我这边服务A报了个错。然后这个请求记录就出现不正常的情况了，我想问问你能不能在服务B这边做一下，如果服务A报错，就把这个请求的所有操作回滚	/	Bug链接在哪？我完全不了解背景但听起来是A服务的问题为什么是我来做？
你就告诉我能不能做就好了为什么还要问这么多问题？不能做就我这边做呗。难道是没听懂我说的？	/	为什么是这样？你看过原来的设计吗？这个是需求要求的吗？在原来的设计中，这里是单向的异步任务这里应该是服务A生成有一条错误记录，而不是回滚服务B。我记得需求也是生成错误消息而不是无事发生吧？	我想先了解背景，比如你的方案是不是从原有设计稿出发的
我觉得你没听懂我说的我再重复一遍	但是错误记录是后面生成的，这里服务A是在最前面就抛错了，我没有捕获这个错误	/	这个决定和设计稿不符有什么情况能推翻我刚才说的设计吗？
	/	服务B这里依赖了其他组件，无法做回滚	这里依赖太多，回滚成本大
不行就算了，我再看看	那好吧，你不做的话我也没办法，因为这里是服务A在最开始就报错了，没有进入后面的流程	/	什么意思？是因为我不做所以才不行？是你的方案有问题吧
	/	你是不是没有理解我之前的方案然后又重复了你说的话？	你是来征求我的意见还是来甩锅的？
我重复我的话是想让你理解我的话	是	/
		那就没什么好说的了，你先想明白再说吧（态度很差，摔门而去）	找我开涮是吧？？

事后复盘

经过进一步排查发现，这个BUG实际上是无效BUG，测试人员因为没有刷新页面，误以为没有生成错误记录。实际上是A服务的子流程抛错，错误记录已经正确生成。

在这个案例中，我们可以看出小红有几点做的不好：

没有确认Bug就臆想解决方案，没有遵循正确的工作流程
提出解决方案时没有了解之前的设计（RTFM），没有遵循正确的设计流程
不理解小明在方案上的解释，反复重复自己的观点希望小明理解，没有遵循正确的沟通流程

小明也有不足之处，在最后摔门而去，是非常不礼貌的行为，不利于之后的继续合作。

经验之谈：如何沟通一个解决方案

这里对于工作流程和设计流程不做太多介绍，在《提问的智慧》一书和其他开源共享指南中，你可以找到很多出色的指南。这里我主要谈谈沟通流程。

沟通流程

原则：表达自己的观点，理解对方的观点，确认双方的共识和分歧。

目的：双方对问题形成一定划定，确定下一步行动项。下一步的行动项可能是更大规模或者其他形式的沟通，最终形成决策。

要点：

对自己要说的事情
- 准备好背景材料，一并提供
- 用自己的话尽量准确地描述问题所在
- 询问是否漏掉了什么关键信息
对对方的回应
- 倾听，确认你所同意的部分
- 询问是否理解正确
- 向自己不明确、不理解的部分提问
重复上述流程，最后形成对问题的界定
- 结论
  - 讨论后，我们认为的实际问题是什么
  - 我们在问题上形成了什么样的共识
- 行动项
  - 在共识中，有一些我们不了解的情况需要进一步沟通或推进
  - 我们的共识可能有错误，需要召集更有经验/权限的人进行决策

如果一切顺利：小红与小明的沟通

这里我们发挥一下想象，如果小红和小明都遵循了沟通流程，他们的对话可能是这样的：

小红：小明，我这里遇到了一个Bug，但我不确定是不是我这里的问题，我想请教你一下（附上Bug链接）
小红：服务A似乎在没有生成记录之前就抛出了错误，导致后续的记录出现了问题，我想问问这个地方能不能由服务B进行回滚
小明：你可能需要先看一看设计稿（设计稿链接），我印象里这里的设计是单向的异步任务。
小明：服务B会依赖其他组件，做回滚的复杂度很高。
小红：好，我先看看设计稿再和你沟通，谢谢你的帮助

在小红看过设计稿后，小红认为这里可能确实缺少了回滚的流程

小红：我看过设计稿了，这个流程似乎是初始化的流程，我还是认为由回滚的必要
小明：稍等，我看一下服务B的设计和代码

小明确认服务B是有设计和编写初始化失败的回滚的

小明：我们对初始化失败有做处理，这个Bug似乎不是这里的问题，你有尝试复现吗？
小红：还没，你是说可能这个Bug是无效的？我尝试复现一下

小红无法复现问题，排查后发现是这个Bug实际是测试人员失误，确为无效Bug。

从以上的沟通中，小红展示了独立解决问题的思路和正确的沟通方式，即使工作流程（未先确定Bug是否属实）有问题，也能在小明的提醒下即时发现，而不是埋头研究其他解决方案。这就是正确沟通的威力。

写在最后

让我们用《提问的智慧》中的两段话来结束这篇文章。

对小红：

低声下气不能代替你的功课
有些人明白他们不该粗鲁或傲慢的提问并要求得到答复，但他们选择另一个极端 —— 低声下气：我知道我只是个可悲的新手，一个loser，但…。这既使人困扰，也没有用，尤其是伴随着与实际问题含糊不清的描述时更令人反感。
别用原始灵长类动物的把戏来浪费你我的时间。取而代之的是，尽可能清楚地描述背景条件和你的问题情况。这比低声下气更好地定位了你的位置。
有时网页论坛会设有专为新手提问的版面，如果你真的认为遇到了初学者的问题，到那去就是了，但一样别那么低声下气。

对小明：

如何更好地回答问题
态度和善一点。问题带来的压力常使人显得无礼或愚蠢，其实并不是这样。
试探性的反问以引出更多的细节。如果你做得好，提问者可以学到点东西 —— 你也可以。试试将蠢问题转变成好问题，别忘了我们都曾是新手。
尽管对那些懒虫抱怨一声 RTFM 是正当的，但能指出文件的位置（即使只是建议个 Google 搜索关键词）会更好。
如果你决定回答，就请给出好的答案。当别人正在用错误的工具或方法时别建议笨拙的权宜之计（workaround），应推荐更好的工具，重新界定问题。