在《人月神话》中，Brooks强调了这样一个观点：增加人手并不会加快软件工程的进度。其中一个很重要的原因就是：增加人手会增加整个团队的沟通成本，这些增加的沟通成本会抵消掉新人带来的工作量。在我看来，这不是绝对的，我们有办法使增加的沟通成本低于增加的工作量，从而加快项目的进度。
先介绍一下这边文章的背景，我在今年的3月到8月间供职于杭州的一家海淘公司，作为公司新项目组的第一名开发人员，见证了项目从起步到发布第一个版本的整个过程。所以整篇文章是基于这个项目过程中的一些教训写出来的，而不是凭空臆造出来的。
首先，也是最重要的一点，任何可以用文档沟通的问题绝对不要用直接面谈去沟通。因为语言的沟通相比文字，有诸多的缺点：
1. 很多人的口头表达能力很差，理解能力也很差，从说出来到听进去的这整个过程都会浪费很多的时间。一个直观的例子，我司的测试工程师在每日的例行站会（公司早间的技术同步会议）上都会重复一些话，而这个他自己是没有意识到的。2.有些人为了证明自己的存在感，会在开会的时候说一些没有意义的废话，就是那些和当前目标没有多大关系的套话。3.不同的人对一些概念的理解不一样，通过口头的交流会放大这个问题，比如我最常听到的：“原来是这个样子，我一直以为。。。”，这就是理解上的偏差造成的。
而文字沟通有几个很明显的有点：可查证，防止出现浑水摸鱼的情况；思路清晰，文字相比语言更有条理；效率高，文字沟通是一个异步的过程，一方在写的时候另一方可以做别的事情。
第二点，告诉所有的员工，在问别人之前，先把你要问的问题想清楚。
很多人在问别人问题的时候会带一些个人情绪在里面，这在软件开发中是要不得的。比如一个前端发现后台给的接口文档“有问题”，凭着对自己的自信，在不经过反复验证的情况下便跑去质疑后台人员，结果是自己把接口里面的参数漏掉了一个。这就是没有搞清要问的问题。一个前辈曾经跟我说过，开发人员需要弄清自己的系统边界，在确保自己提供的边界没有问题的情况下，才能去质疑别人。比如，我们的后台人员需要在postman等工具上把自己的接口调通了，才能去告诉前端：“你是不是把参数名写错了”或者“你看看参数是不是漏掉了一个”，还有一个需要关注的点是：沟通的过程中要语气平和，不要相互抱怨，这在后台和前端人员调试接口的时候尤其重要。
第三点，在一些问题上达成共识。
我司的产品线比较长，其中的概念很多，有业务上的，也有技术上的。这些概念在日常沟通中出现的概率很高，需要尽量统一他们的名字，避免出现需要解释的局面。比如我们有一个微信上的销售小程序，有的同事把它叫做商城，有的同事把它叫做销售小程序，还有的同事把它叫做云商城，这五花八门的名字会增加沟通的成本，做到统一不过是很简单的一件事情。还有一个例子，前端之前和我说过，我司的某位后台给的接口文档中写过一个
叫做”integer"的参数类型，因为这个前端才开始工作没多久，不知道“integer"表示的是”int"（JavaScript根本没有Integer这个类型，C语言也没有），她为了这个还要跑过去和那个后台沟通。如果我们在准备接口文档之前统一一下参数类型的名字，这样的多余沟通不就可以省略掉。
第四点，给新人准备一份文档。
新人的加入需要老员工的引导，告诉他们一些业务、技术、公司方面的知识。这其中有很大的一部分可以通过文档的形式教会新人，而且文档的存在避免了新人对于一些东西的反复忘记询问再忘记再询问这样一个浪费时间的过程。举个最简单的例子吧，各个模块现在分别由谁负责、前端是什么架构、后台是什么架构、GitLab地址、开发测试生产环境的账号密码、数据库是哪一个、java等语言用的什么版本，这些很常见的问题，写一份文档也用不了多久，但是以后每当有新人进来，都可以用这一份文档帮助他快速融入项目中，它省去的沟通成本是相当可观的。
以上是在杭州的这四五个月时间里面对软件开发过程中团队沟通的一些思考，希望能警醒自己，同时帮助到一些人。
