读《沟通的方法》

Posted 2021-10-26 dotNET跨平台

众所周知，沟通在工作和生活中是一项非常重要的技能，但很多人却用不好这项技能，最近中秋假期，看完了得到 CEO 脱不花写的《沟通的方法》，觉得很有收获。

脱不花没有上过大学，能有今天的成就，超强的沟通能力是一个很重要的原因，她自己也说，她是一名职业的沟通者。

不管你是技术人员还是非技术人员，读读这本书，总会对你有些帮助和启发。

本书的特点：

• 每一个章节的开头都会有几个小问题？可以让我们带着思考去进行阅读，读完后，再和自己事先的答案比较下，能加深理解和记忆；

• 书中有大量的案例，读起来很轻松，不枯燥；

• 每个沟通的技巧都总结出了相关的公式和套路，有这样一些框架和套路，更容易去进行实践和落地；

• 沟通肯定会涉及到双方，每章节都会采用不同视角进行解读，比如批评，既有以领导视角讲解怎样批评人，也会从普通员工视角讲到怎样接受批评。

我们平时的工作中随时随地都存在着沟通，比如：

• 向上汇报工作，向下安排工作；

• 被安排作为新人的入职引导人，需要对新人进行辅导；

• 你有一个很好的建议，希望公司或团队能够采纳；

• 前后端的开发人员之间需要进行联调；

• 作为一个团队负责人 ，需要激励每个成员，解决他们工作中的障碍；

• 团队内部的会议；

• 年终和团队成员进行绩效面谈等。

上面列举的这些，在书中都有相应的解答，下面说说我感触较深的几个点。

倾听

沟通的起点是倾听，书中将倾听放在第一个部分介绍，可见其重要性。这个看似简单的操作，要做好还是挺难的，之前在倾听上就犯过这样一些错误：

• 多人沟通，遇到一个自己比较熟悉的领域或者觉得对方讲的细节有遗漏或不清晰时，容易抢话；

• 看似很认真的在听，其实没动脑子，照单全收，就什么都没吸收；

书中建议我们使用结构化倾听，意思是在倾听时，要分辨对方的讲述是带着情绪，还是在讲事实，对方会有什么样的心理预期和期待。

当碰到一些低级错误时，很容易上头，情绪化的词语就会蹦出来，会非常影响沟通，比如：

• 怎么老是犯这种低级错误；

• 最近经常迟到啊；

作为倾听者，当发现对方有情绪时，首先要做的是让情绪先降下来，这是沟通的开始，同时作为一个讲述者，也需要时刻注意自己的语言中是在讲事实，还是带着情绪。

说服

在软件产品的开发中，经常会有一个技术方案怎么选型，一个 UI 设计怎么确定，存在着反复的讨论，最终如果所有参与人员都是认可的，事情才会进展的顺利。如果你是这个方案的提出者，就需要有能力说服其他人，让他们都觉得你这个方案是最优的。

说服不是靠资历、职级进行强压，或者采用一些手段进行忽悠，而是要让对方觉得：

• 这个技术方案考虑的场景确实很多，不服不行；

• 你们的目标是一致的，利益是相同的，我愿意支持这样做。

如果你的上级对你没那么信任，就很容易遭受到否定，所以需要提前做好功课：

• 搜集资料，提供数据支撑；

• 整理一些其他行业标杆的成功案例；

• 做一个最小可行性的验证示例。

最终做到书中所说的「说话有分量」。

批评和表扬

如果你是一个团队的管理者，那么批评和表扬应该就是你的工作日常了。

批评要选适当的场合和时间，而且需要注意的是批评不是责备，目的让对方知道怎样正确地做事，而不是只说怎么老是犯错。

对方意识到问题并知道解决方法后，还需要有一个反馈机制进行监控，确保下次不会再犯，或者目前采取的措施是在往一个好的方向发展。

在批评的最后要确保双方的信息是没有偏差的，否则就南辕北辙了。可以让对方谈谈他的想法和理解，如果信息没有偏差那么谈话就可以结束了。

有时候，管理者的一个小小的鼓励会给团队成员带来巨大的动力。

表扬的一个前提是，管理者要对团队成员足够的了解和熟悉，有的人喜欢一对一鼓励，有的人喜欢公开的表扬。如果搞反了，可能起不到应有的效果，而且表扬要及时。

绩效面谈

我自己也有在做绩效面谈类似的事情，但相比较书中的介绍，没那么正式，现在一年会有一到两次和团队成员的面谈，主要是想了解他们在工作中的一些情况，比如：

• 遇到什么困难没有？

• 觉得团队氛围、工作内容和预期匹配吗？

• 未来有什么样的规划？

• 对团队或公司有啥意见或建议？

看了这一章节后，我觉得下面的几点可以尝试实践下：

• 提前和每个人预约好时间，避免集中对所有人持续面谈，比如集中在一两天完成所有的面谈，第二天的效果肯定没第一天的好；

• 让面谈者准备些问题，在过程中给与解答；

• 涉及到对面谈者的评价，提前整理好相关数据；

• 最后的结尾需要让面谈者来说。

会议

相信每个人都开过会，相信每个人在开会时都有这样一些经历：

• 会议中一个人一直讲，最后问下大家有没有什么问题，在一片沉默中散会；

• 会议讨论大家很积极，天马行空，一会就偏离主题了；

• 本来预计 2 小时的会议，最后开了一上午；
  

• 会议的结果不能转化成一个行动。

在一个研发团队中的会议大概有两种：通知型和讨论型。

通知类型的，管理者简明扼要地下达指令就可以了，如果谁有疑问当场提出，进行解答，保证所有人都能够理解。

讨论型的，管理者一定要注意，自己只是起到一个抛转引入的作用，更多的是要让每个人都参与进来。可以提前将会议内容、时间等发到群里，让参会者能提前做好准备。

总结

读完一本书不能够让我们有质的改变，需要理论结合实践，在平时工作生活中去尝试使用书中的方法，遇到问题再进行分析、复盘，然后改进，继续实践，如此迭代，才能说吃透了一本书的内容。

本文在讲工作中的沟通，突然想到，我们团队开发的零代码搭建平台不就是一个沟通的工具吗？以前跟客户沟通需要画 UI 原型、需要统一语言、需要花大精力开发完初版后才能进行演示等等，那么有零代码搭建平台的加持，就能快速解决这种沟通问题了。