沟通并不是必要的

最近半年公司在开发一个新项目，人手少，工期紧，大家压力都很大。因为项目比较复杂，现成可供参考的资料又少，常常需要大量的会议来同步知识，而这占用了本来就捉襟见肘的时间，让工期的紧迫现状雪上加霜。

（一）

我在项目组的角色介于开发和技术管理两者之间，常常需要和各种角色打交道。今天是一名 golang 工程师。他负责的字段修改完成了，让我来评审。粗略看了一下，改了十几个文件。对方约我电话会议，我加入进去，对方表示想和我过一下修改的内容。按照我平时的人设，一般来说都不会拒绝这样的提议，但是今天我毫不留情的拒绝了这个提议。

看到这位年轻的工程师一脸的问号，我觉得应该稍微的解释下。

这次代码修改的原因，是服务层没有严格的遵守之前的协议：字段名称映射必须遵守 camel case -> snake case 。这导致部分查询接口失效。这次修改的目的，就是修复所有与协议冲突的字段。

因为目标是遵守协议，所以其实我并不需要查看代码来了解修改的细节，以判断自己是否需要修改 app 端相关代码。只需要查看自己代码是否遵守协议即可。

只要我们保证自己遵守了协议，那么并不需要频繁的对接口，看代码，也能保证系统正常运转。

（二）

纯以效率而论，软件开发领域，沟通的效率其实远不如协议。

以上面的事情为例，项目组若干，每个项目组负责不同系统的员工若干，任何一次技术上的变动，若是要通知到相关利益人，花费的时间和精力甚至高于实际的变动。很多公司要求此类变动必须发送邮件而且标注重要，邮件里面也要讲清楚如何修改如何测试，但这只是简化了同步知识的过程，具体的实施依然要各种会议，电话满天飞，沟通成本并没有下降。比如，这位golang工程师要求过一下变动的细节，这就是沟通成本。这样的会议，稍有控制不当，就奔着1个小时去了。

但是大量的变动，如果事先有简单的协议约束变动的细节，则根本不必需要频繁的沟通。还是上面的事情，如果golang工程师的变动遵循协议，那么，我只需要关注自己的代码即可。

就像盐是咸的，糖是甜的，我并不需要每次都要品尝才能确定盐是盐，糖是糖。因为协议规定了这个就是盐，那个才是糖。

（三）

虽然是很简单的道理，但是实现起来，却是困难重重。

比如两个系统每每数据不一致，大部人的想法是，加强沟通。而不是想着，定一个协议，遵守协议。毕竟，打个电话发个消息多即时啊。做协议，随便一个 topic 几个钟头就没了，做完了还得邀请别人评审，评审完了还得发给相关人员去实施。

所以大部分的项目其实没什么章法的，文档其实是没有的，或者只是个摆设。项目为什么这样做，为什么又改了，线索都在聊天工具里。只要当初负责的人不在了，就再也找不到第二个懂得人。

从这个层面看，其实很多公司项目根本不如开源项目有章法。因为开源项目天生要克服人员分散的现状，不得不订立严格的协议来规范变动，反而成了管理变动最好的示范，形成了很多有效的合作模式。而很多公司项目因为人员固定，反而太过于依赖所谓的沟通来克服问题，知识无法沉淀，效率无法提高，最后变成屎山项目。

这样来看，其实尽早尽快的定制协议，反而是磨刀不误砍柴工的好事。而且从技术上来说，每一次沟通，也都是为了确定一个协议，只不过这个协议是短期的，临时的，没有文档化的。那既然如此，倒不如正式的确立一个协议，然后反复的巩固改进并且推广。

（四）

团队的成员越多，沟通的效率越低，所以如何提高沟通效率是一个非常热门的话题。

但是不妨换个思路，所有的沟通都是必要的吗？我觉得不是。

很多时候，我们沟通的目的都是为了达成一个协议，但是往往我们并没有意识到，应该将这个协议正式化，从而形成一个可以指导后期协作的框架。而是止步于沟通，并且在下一次出现相关问题时，继续用沟通的方式来解决问题。于是当人员越来越多，沟通成本越来越过，最后发现，团队里成员大部分的时间都用来参加各种会议，而不是做具体的工作。

就像今天早上这么一波，如果我们没有协议，如果我没有坚持说“看协议就行”，那我就得再花一个小时重新达成之前达成过的协议。而这一个小时，我本来可以去做更有价值的事情。

（完）

于 2022 年 8 月 21 日，陕西渭南家中