當(dāng)談到項目管理，管理者更多的會討論和研究的話題是圍繞范圍，時間，成本，質(zhì)量這四個主要的領(lǐng)域展開，相對的，也挺少會看到一些文章，深入討論溝通管理這個領(lǐng)域。溝通在團(tuán)隊規(guī)模較小的時候， 問題總是不會太過重要，換句話說溝通成本還是相對能夠控制，但是當(dāng)團(tuán)隊規(guī)模的不斷變大，甚至是團(tuán)隊的組成比較復(fù)雜的時候， 團(tuán)隊之間溝通的成本就會逐漸增加，也會成為我們項目管理人員不得不面對和改進(jìn)的重要問題。
想象一下這樣的情景，團(tuán)隊成員經(jīng)常會抱怨忙不過來，而當(dāng)問起原因大多會有這樣的回答， “人員不足”。 管理人員也沒有經(jīng)過論證，單純的把這個問題拋到到了上層， 作為團(tuán)隊交付沒有達(dá)到預(yù)期的最好借口。人員緊急補(bǔ)充，交付逐漸增加， 但仍舊沒有達(dá)到預(yù)期，因為人員補(bǔ)充了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)的團(tuá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è)計由核心模塊出，其他團(tuán)隊配合。在設(shè)計評審會上，各方都參與了會議，雖然有不少爭論和討論，但最后也確定了設(shè)計方案，大家也表示沒有問題，會按設(shè)計完成。待到按時完成的時間，突然發(fā)現(xiàn)工作不起來。一查，原來當(dāng)時出方案的時候，核心團(tuán)隊并未了解其他團(tuán)隊目前的設(shè)計和工作模式，其他團(tuán)隊也并未完全搞懂整個設(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)驗， 也希望能給那些同樣面對大團(tuán)隊溝通問題并困擾其中的管理者們一些借鑒和參考。
(本文于2016-02-18首次發(fā)布)
