當談到項目管理，管理者更多的會討論和研究的話題是圍繞范圍，時間，成本，質量這四個主要的領域展開，相對的，也挺少會看到一些文章，深入討論溝通管理這個領域。溝通在團隊規模較小的時候， 問題總是不會太過重要，換句話說溝通成本還是相對能夠控制，但是當團隊規模的不斷變大，甚至是團隊的組成比較復雜的時候， 團隊之間溝通的成本就會逐漸增加，也會成為我們項目管理人員不得不面對和改進的重要問題。
想象一下這樣的情景，團隊成員經常會抱怨忙不過來，而當問起原因大多會有這樣的回答， “人員不足”。 管理人員也沒有經過論證，單純的把這個問題拋到到了上層， 作為團隊交付沒有達到預期的最好借口。人員緊急補充，交付逐漸增加， 但仍舊沒有達到預期，因為人員補充了1/3，但交付也許只增加了1/4。人員隨之進一步增加，但情況持續下滑， 隨著人員的增加，交付并沒有增加相匹配的量，直到有一天，即使增加了人員，交付也沒有什么明顯的變化， 甚至于還減少了。導致這個問題的原因是系統性的， 但是有一個很直接的原因就是因為溝通的成本增加比生產力的增加要快。
加入網易后，我就一直擔任網易云計算的項目管理工作，云計算大大小小有不同的模塊組十余個，總人數逾130人，而且這些模塊組還來自于多個不同的部門，雖是一個項目組卻不得不進行部門間的合作，論人數這可能未必是網易最大的項目，論技術復雜度和各模塊之間的協作，絕對是網易屈指可數的項目之一。
技術的復雜度加上組織架構上的特殊性，天然的決定了云計算這個項目所面臨的溝通成本不會低，大部分的隱性風險可能都會源于溝通的問題。
進入云計算項目起初，我經常會碰到林林總總的溝通問題，先讓大家看幾個案例。
案例1
PaaS層某服務leader有一天，急沖沖的跑了過來（雖然都坐在一塊區域，但人數多，往往最遠的團隊可能要相距50米，中間隔了2-3個會議室）。
PaaS某服務leader：“昨天我們線上服務某功能失效了，聽說你們底層昨晚升級，原本工作的接口現在不工作了，我們整整查了一宿，怎么改了接口也不通知一下，你們得要負責！”。
底層leader聽了不樂意了，立馬翻出一封系統發的上線通知郵件，“看，郵件上寫的清清楚楚，參數和以前不一樣了，請上層做好適配，這責任還得你們自己背！”。
“每天這種郵件那么多，怎么可能一一看過來”，PaaS某模塊leader，又不服氣的說。
“那通知已經發了，況且我哪知道你們誰用了，會不會出問題？”，底層leader也不示弱。
爭吵持續5分鐘，10分鐘，30分鐘…1個小時，始終沒有結論，但又怎么會有結論？
案例2
A為了完成任務依賴某一模塊的工作，于是向B提出需求任務，他們一合計沒什么問題，B也就接受了，同意1周后完成。為了不至于等待，A繼續其他任務的工作。
1周后，A向B詢問任務的進展，B回答，“為了要完成這個任務還需C的工作，需求任務也提給C了，他也正在開發中”。
“那啥時候能給？”A有點急。
“C一完成我馬上就能給你”，B說。
時間又過了一周，A又去問B進展。B回答，“C好像碰到點技術難題，一直沒完成，具體什么原因你去問問C吧？我這兒正忙著其他工作”。
A無奈找到了C，C告訴他，“的確碰到點技術問題，需要重新修改原本的設計”。
兩人一商量敲定了方案，約定就這么做，一周后完成。A心想這回總好了，心滿意足的回去了，但一周過去了還是沒動靜，A去問C進展，C說，“約定的方案當時沒叫上B，現在對接到B那邊又出了問題”。
A：“…”。
最終什么時間解決的也不得而知，A由于心力交瘁，再也不想管這檔子事兒了。
案例3
這是一個大塊的功能設計，涉及到多個模塊的工作，設計由核心模塊出，其他團隊配合。在設計評審會上，各方都參與了會議，雖然有不少爭論和討論，但最后也確定了設計方案，大家也表示沒有問題，會按設計完成。待到按時完成的時間，突然發現工作不起來。一查，原來當時出方案的時候，核心團隊并未了解其他團隊目前的設計和工作模式，其他團隊也并未完全搞懂整個設計的真實需求，大家也都只是在各自理解的基礎之上達成了表面的共識。當真的聯調的時候發現，以現在的實現無法達到最終的需求目標，而如果要達到最終的需求目標，其他模塊的實現目前也無法做到。
互相推責抱怨的聲音，又開始此起彼伏，不絕于耳。
以上的例子，讀者想必也會深有感觸，可能也會因為這些問題痛得深切，惺惺相惜而感動落淚，仔細總結一下就會發現，溝通的問題有如以下幾種類型：
信息不交換
信息傳遞不正確
信息傳遞損耗
信息傳遞中斷
信息傳遞鏈路太長
立場對立
溝通人員太多，溝通成本高，耗時長
對在云計算里摸爬滾打的經歷，我加以總結，并以三個維度（溝通模式，流程制度以及價值原則）來具體分享我的經驗， 也希望能給那些同樣面對大團隊溝通問題并困擾其中的管理者們一些借鑒和參考。
(本文于2016-02-18首次發布)
