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