在《人月神話》中，Brooks強調了這樣一個觀點：增加人手並不會加快軟件工程的進度。其中一個很重要的原因就是：增加人手會增加整個團隊的溝通成本，這些增加的溝通成本會抵消掉新人帶來的工作量。在我看來，這不是絕對的，我們有辦法使增加的溝通成本低於增加的工作量，從而加快項目的進度。
先介紹一下這邊文章的背景，我在今年的3月到8月間供職於杭州的一家海淘公司，作為公司新項目組的第一名開發人員，見證了項目從起步到發布第一個版本的整個過程。所以整篇文章是基於這個項目過程中的一些教訓寫出來的，而不是憑空臆造出來的。
首先，也是最重要的一點，任何可以用文檔溝通的問題絕對不要用直接面談去溝通。因為語言的溝通相比文字，有諸多的缺點：
1. 很多人的口頭表達能力很差，理解能力也很差，從說出來到聽進去的這整個過程都會浪費很多的時間。一個直觀的例子，我司的測試工程師在每日的例行站會（公司早間的技術同步會議）上都會重復一些話，而這個他自己是沒有意識到的。2.有些人為了證明自己的存在感，會在開會的時候說一些沒有意義的廢話，就是那些和當前目標沒有多大關系的套話。3.不同的人對一些概念的理解不一樣，通過口頭的交流會放大這個問題，比如我最常聽到的：“原來是這個樣子，我一直以為。。。”，這就是理解上的偏差造成的。
而文字溝通有幾個很明顯的有點：可查證，防止出現渾水摸魚的情況；思路清晰，文字相比語言更有條理；效率高，文字溝通是一個異步的過程，一方在寫的時候另一方可以做別的事情。
第二點，告訴所有的員工，在問別人之前，先把你要問的問題想清楚。
很多人在問別人問題的時候會帶一些個人情緒在里面，這在軟件開發中是要不得的。比如一個前端發現后台給的接口文檔“有問題”，憑着對自己的自信，在不經過反復驗證的情況下便跑去質疑后台人員，結果是自己把接口里面的參數漏掉了一個。這就是沒有搞清要問的問題。一個前輩曾經跟我說過，開發人員需要弄清自己的系統邊界，在確保自己提供的邊界沒有問題的情況下，才能去質疑別人。比如，我們的后台人員需要在postman等工具上把自己的接口調通了，才能去告訴前端：“你是不是把參數名寫錯了”或者“你看看參數是不是漏掉了一個”，還有一個需要關注的點是：溝通的過程中要語氣平和，不要相互抱怨，這在后台和前端人員調試接口的時候尤其重要。
第三點，在一些問題上達成共識。
我司的產品線比較長，其中的概念很多，有業務上的，也有技術上的。這些概念在日常溝通中出現的概率很高，需要盡量統一他們的名字，避免出現需要解釋的局面。比如我們有一個微信上的銷售小程序，有的同事把它叫做商城，有的同事把它叫做銷售小程序，還有的同事把它叫做雲商城，這五花八門的名字會增加溝通的成本，做到統一不過是很簡單的一件事情。還有一個例子，前端之前和我說過，我司的某位后台給的接口文檔中寫過一個
叫做”integer"的參數類型，因為這個前端才開始工作沒多久，不知道“integer"表示的是”int"（JavaScript根本沒有Integer這個類型，C語言也沒有），她為了這個還要跑過去和那個后台溝通。如果我們在准備接口文檔之前統一一下參數類型的名字，這樣的多余溝通不就可以省略掉。
第四點，給新人准備一份文檔。
新人的加入需要老員工的引導，告訴他們一些業務、技術、公司方面的知識。這其中有很大的一部分可以通過文檔的形式教會新人，而且文檔的存在避免了新人對於一些東西的反復忘記詢問再忘記再詢問這樣一個浪費時間的過程。舉個最簡單的例子吧，各個模塊現在分別由誰負責、前端是什么架構、后台是什么架構、GitLab地址、開發測試生產環境的賬號密碼、數據庫是哪一個、java等語言用的什么版本，這些很常見的問題，寫一份文檔也用不了多久，但是以后每當有新人進來，都可以用這一份文檔幫助他快速融入項目中，它省去的溝通成本是相當可觀的。
以上是在杭州的這四五個月時間里面對軟件開發過程中團隊溝通的一些思考，希望能警醒自己，同時幫助到一些人。