摘 要：在項目中往往都會遇見這樣的情況，不同的人對同一個問題有不同的理解，從而增加溝通成本降低執行效率，就像缺乏潤滑的機器。本文主要討論的內容就是讓參與項目的干系人能夠按照合理的方式進行溝通，快速達成統一認識。就如同把高效的干系人管理手段當成潤滑劑注入項目這臺機器，讓項目能夠高效運轉。
一、引言
作為項目的參與者都希望正在參與的項目能夠像一臺保養良好的機器，各個部件緊密配合，能夠高效平穩地運轉。那么有效的溝通管理讓項目干系人都能夠有效的為項目出力，就成為了項目成功與否的一個關鍵因素。通常不同的項目干系人因為職位、文化、技術等不同的立場，導致對同一個問題的理解也不盡相同。如果不能及時達成一致，則需要花費更多的時間和精力。就如同缺乏潤滑的機器，運作緩慢，甚至陷入停滯的狀態。本文想探討的就是找到項目溝通中常見的問題，并采用行之有效的辦法使溝通變的高效順暢，就像把潤滑劑注入機器，讓機器重新恢復快速運轉。
二、導致項目運轉不良的常見問題
現在的項目團隊組成往往呈現復雜化的趨勢，在IT項目中這種現象尤為顯著。從職責上區分，有需求人員、開發人員、測試人員、質量保證人員、項目管理者等；從所處的立場區分，有客戶、項目組、投資人、高層管理人員等；從各自擅長的領域上區分，有業務、技術、管理等。不同的項目干系人的在項目的不同階段對項目要求的也不盡相同。而在如此復雜的溝通環境中，總會出現這樣那樣的問題。其實人與人的溝通過程就如下圖所示的IT項目中的必不可少的編碼解碼過程。信息發出者會根據自己的理解組織語言文字然后傳達給接收方，這就如同編碼過程；信息接收方則會按照對自己的方式理解信息的具體內容，這就如同解碼過程。一條信息能不能被正確地理解，是不是能夠按照統一協調的方式進行編碼和解碼就顯得尤為重要了。下面我們就來看看3個典型容易導致編碼和解碼方式不能順暢進行的問題。
圖1：溝通模型
（一） 先入為主
先入為主又是溝通中經常遇見的另一個問題。美國社會心理學家洛欽斯曾經做過一個經典的實驗。他杜撰了描述一個名叫詹姆的人的兩段文字，一段是描寫他在路上與各種人交談打招呼，另一段是描寫他安靜地喝飲料看書。把打招呼作為第一段進行閱讀的時候，78%的人認為詹姆是一個外向的人。而反之把安靜看書的這段放在前面進行閱讀的時候，只有18%的人認為詹姆是外向的人。這就是心理學中常說的認知過程中最初形成的印象起著非常重要的作用，這被稱之為首因效應，也就是常說的先入為主。
現代心理證明當不同的信息結合在一塊的時候，人們總是傾向于重視前面的信息。即使信息不一致，往往也會把后面的信息當做偶然而非必然，不經意間根據前面的信息解釋后面的信息，以便形成整體印象。在項目的溝通中這種情況也是時常發生的。例如，技術或者業務方案討論時，大部分人都會按照自己最初的想法進行設計和規劃；再比如，人力規劃的時候，依舊按照以前了解的情況進行任務分配等。當預設立場也就是先入為主的觀念在腦海中慢慢形成的時候，溝通中就難免出現各種誤會了。
（二） 講不清、沒聽懂
在溝通中的另一類典型的問題就是表達的人沒有說清楚，接受信息的人沒有理解真正的問題。這里我們再看一個網上流傳很久的經典小段子，程序員買瓜的故事。一個程序員的老婆給他打電話說：“下班順路買個西瓜，要是看到西紅柿就買兩個。”結果呢，這個程序員買了兩個西瓜回家。按照他老婆或者說大多數人的思維，對這句話的理解應該是，順路買一個西瓜，要是有西紅柿就買兩個西紅柿。但是程序員呢，就把這句話當成了編碼里常見的條件語句。他是按照下面的編碼方式理解的。
函數名 順路買西瓜（）{
If（沒有西紅柿） {
買一個西瓜；
}
else If（看見西紅柿）{
買兩個西瓜。
}
}
如上面的函數所示，這段代碼如果真的能編譯執行，那么在看見西紅柿的情況下，就是買了兩個西瓜。
我們可以看到在這個問題上程序員的老婆講清楚了嗎？沒有，她沒有明確地說出她還需要買西紅柿的需求，埋下了誤會的隱患。程序員聽懂了嗎？顯然也是沒有，程序員沒有理解他老婆的真正需求。這類聽不懂或講不清的問題往往成對出現，很難說清到底是誰沒講清楚，或是誰沒有真正聽明白。而最容易發生這個問題的階段就是在需求分析階段，當業務人員與技術人員進行需求討論的時候，就是不懂技術的人與不熟悉業務的人要把技術業務問題一起討論清楚，因為相互的不了解出現誤解的概率就很高了。大家也都會有這樣的經驗，當客戶進行實際體驗或是驗收的時候，客戶滿腹牢騷：“這就不是我想要的東西”，而技術人員委屈地說：“都是按您的要求做的啊！”。
（三） 沒有及時正確的反饋。
不知道大家有沒有碰到過這種情況。A在評審B的代碼的時候，根據自己的經驗跟B說了對一個問題的看法，覺得某個業務函數調用的太頻繁，可能會造成性能下降。B在梳理業務需求之后發現這就是客戶的要求，沒有必要改。但是B只是回復“知道了”并沒有修改，覺得這個既然是客戶的要求，就是理所當然的。結果在交付代碼時A發現這個代碼沒有修改不同意交付。從而引發了出不少爭執。
上面的情況就是接受信息方，并沒有對信息發送者進行清晰及時的反饋。這樣作為發送方，也沒有辦法對于后續應該的動作進行正確的規劃。拿上面的問題來說，如果B回復“這是客戶的要求，性能下降，也是在客戶允許的范圍內，所以不用修改。”這樣A就可以根據技術業務數據進一步判斷不需要修改代碼的合理性。所以即使是拒絕或者否定對方的信息，也需要清晰及時地進行反饋。才能保證信息的傳遞形成一個有效的閉環。
除了上面3個比較典型的問題之外文化的差異、成長環境的不同、看問題角度的不同等因素都會造成溝通的誤會。在項目推進中應該盡可能避免這些誤會的出現。
三、通過對溝通的規劃形成有效的體系
大家看到了上面的幾個問題，一定會問我們怎么才能既能進行高效的溝通，又能避免溝通中出現的各種誤會呢。在這里要說的是，溝通離不開見招拆招去隨機應變，但是更需要的是對溝通進行合理有效的規劃，從而形成完整的溝通體系。依靠體系去識別溝通中的人和事，也要依靠體系引導溝通向預想的方向發展，更需要依靠體系保證項目目標最終能夠實現。
（一） 溝通離不開“以人為本”的基礎
溝通始終離不開的核心因素就是人，所以“以人為本”就成為的溝通的基礎。因為我們是討論項目中的溝通管理，我們就先來了解一個概念“項目干系人”。項目干系人是參與項目或利益可能受項目實施而受消極或積極影響的人或組織。對項目來說，關鍵的聯系人有，客戶、投資人、組織高層、PMO、項目經理、職能經理、業務伙伴等。每個干系人對項目都有著不同的利益訴求，也有著不同的權利和義務。下圖就是在項目的干系人管理中常用的權利利益矩陣，通過這個圖告訴我們對應不同的利益和權力，應該采用什么樣的溝通策略。
圖2：權利利益矩陣
清楚需要進行溝通的項目干系人所處的位置后，就可以進行“看人下菜碟”式的有針對性的溝通方式了。從這張圖上最需要重點關注的肯定是位于D區的干系人，他們對項目既有很高的權利，對項目的結果也非常在意。比如客戶、最終用戶、項目核心技術業務人員或是項目經理以及團隊的直接領導就屬于這類人。所以要重點管理，及時匯報，盡可能采取有力的行動保證這個區域的人對項目進展情況隨時了解，力爭滿意，以便對項目繼續推進形成積極的影響。
B區的人雖然權利小，但是自身利益受項目影響大，所以非常關注項目結果。因此要隨時告知項目的進展用以維系滿意程度。因為大部分項目成員是屬于這個區域的，所以如果低估了他們的利益，可能產生嚴重的后果。
C區的人權利雖然大，但是自身利益受項目影響較小。如公司股東、高管之類的人。因此爭取他們的支持對項目來說也是至關重要的。對于他們的管理策略就是保證合理的匯報內容以適度的溝通頻率，讓其對項目保持滿意狀態。
對于A區的人來說，給予足夠的尊重，爭取他們的支持，降低可能的敵意，就足夠了。在整體精力有限的情況下，用最少的努力維持合理的關系即可。
（二） 溝通少不了“洞悉一切”的慧眼
前面說過溝通中因為這樣或是那樣的原因，會產生很多的誤會。既然是誤會，就說明沒有搞明白對方的真正意圖。所以想方設法看清楚對方的真正目的就顯得尤為重要了。
做過項目尤其是IT項目的人大多都有過項目進行過程了，客戶又要追加功能的情況。遇到這種問題的時候，項目組大多數人的反應就是反感，容易與客戶發生爭執。但是客戶畢竟是客戶，事情又不能不做，做了又影響項目的進度和質量，于是乎陷入兩難的境地。
想破解這個難題，除了尊重對方的態度、柔和的溝通技巧之外，想根本解決這個問題，那就需要首先搞清楚客戶的真正隱含需求是什么。而這種需要才是客戶衡量項目的真正標準。表面上客戶變更的原因可能是不一樣的：有的因為重要的功能發生遺漏，有的因為外部承諾的變化，有的因為可以提升上線后的工作效率等等。但是對于客戶以及項目組來說，項目都只有三個核心因素，范圍、進度、資源。那么就可以縮小范圍從這三個因素中找到客戶真正最在意的那個。如果進度是必須保證的，那么對于項目的范圍上是不是可以進行優化或者刪減。如果范圍是不能變的，進度上能不能合理地延長。另外資源上可不可以得到補充。總之在搞清楚客戶的真實意圖之后才能明白對項目的實際影響，進而找到合理的平衡點，提出有效的解決方案。即便可能超出項目組的決策能力之外，也能利用這些實際的真實信息，幫助項目外的高層領導作出合理的決策。
解決需求以及技術分歧的時候也是同樣的道理，一定要搞清楚對方真正想要的東西，才能提出雙方都能接受的共贏方案。
（三） 溝通省不掉“按部就班”的計劃
說到溝通，很少有人覺得自己有問題。因為每個人每天都需要不斷跟不同的人進行溝通。所以每個都都有自己的溝通習慣。再加上我們上面所說到的各種問題產生的影響。
使得很多時候會發現溝通的各方不在一個頻道上，整個溝通變的生澀。都說無規矩不成方圓，想要讓項目的溝通變成“按部就班”的穩定狀態。就需要我們把溝通的計劃定下來。
項目溝通計劃是確定利害關系者的信息交流和溝通要求。項目干系人都必須準備該項目“語言”進行溝通。并且要明白：每個項目干系人所參與的溝通將會如何影響到項目的整體。誰需要何種信息、何時需要以及相應如何將其交到他們手中就好通過溝通方式和手段。因而溝通計劃對于項目的成功很重要。溝通計劃的依據包括：溝通要求、溝通技術、制約因素三個方面。確認項目溝通要求的信息一般包括：項目組織和各利益相關者之間的關系；該項目設計技術知識；項目本身的特點決定的信息特點；與項目組織外部的聯系等等。
好的溝通計劃具有可行性。考慮問題的影響因素是否全面和解決問題的方法是否可行決定了計劃的可行性和可操作性。計劃需經過各方的認可，方可公布。是執行和控制的有力保證。
四、能幫助我們的幾個溝通技巧
說了不少溝通的規則，那么我們再來看看溝通的技巧。溝通的技巧能夠讓我們把溝通做的更平順更圓滑更容易讓人接受。
（一） 同項目組內部溝通
項目組內部首先要做到及時準確，因為是項目組內部，為了保證溝通的及時性，溝通的方式可以不用非常正式。但是溝通中必須保證雙方都能準確理解對方的真實意圖。當然事后需要通過正式的方式確認。其次對于項目中重要的工作內容，需要多次確認強調，保證計劃順利實施。當然處理具體問題的時候，切記要對事不對人。保障進行內部溝通時內部人員敢于發言，這樣才能收集到項目內部的真實信息，并據此制定真正可執行的項目計劃。
（二） 和外部客戶溝通
和外部客戶溝通要保證能夠建立起一條順暢而且標準的內外部溝通渠道。內外部信息交換都需要經過這條通道。凡是不通過該通道的信息可以視為無效信息。這樣能夠減少信息收集的難度，也能盡可能保證信息的準確。在對外溝通的時候，一定要記住，對于決策性的溝通內容，一定要通過雙方都接受的正式方式進行確認。確保溝通結果能夠按照雙方真正理解的方式，在項目中得到執行。
（三） 與公司高層溝通
公司高層通常比較忙，所以沒有時間聽大段的匯報。溝通前一定要明確想通過高層獲得什么樣的資源、或是解決什么樣的問題、亦或是想了解什么樣的內容，只有明確的目的性才能保證溝通能夠圍繞目標簡潔明了。雖然表達觀點簡潔明了，但是在高層產生疑問時就要用充分的分析和論據進行說明。這就需要充足的準備工作，可以提起進行沙盤推演，以免因為緊張而沒有把問題闡述清楚。
（四） 其他的技巧
首先要做到的就是真誠，而且真誠要勝過一切技巧。在溝通的時候，用心去體會對方的立場以及想法。其次要耐心聆聽，努力去做一只“空杯”。不要預設立場，接納對方的觀點，海納百川有容乃大。還有kiss原則，這里是Keep It Short & Simple的縮寫。意思很直接，就是告訴我們溝通的信息需要簡潔明了。畢竟不是寫作文，項目溝通追求的就是高效準確。
五、案例淺析
最后我們來看一個案例，如何處理一個棘手的項目變更。
正當一個項目正在緊張趕進度的時候，客戶方負責人H突然提出更改項目方案，修改部分接口設計，將系統的一部分提前上線。此方案對項目組非常棘手，需要改變很多，增加額外工作量，而且新老系統同時運行風險極大。可不論項目經理M如何解釋，H依然堅持。冷靜下來之后M向自己的高層領導S匯報了這一情況。S利用自己與客戶高層良好的關系，對項目情況進行了了解。原來對方的高層負責領導剛剛發生變化，新上任的高層領導覺得這個項目極為重要，不允許有閃失，但周期長任務重，擔心一次性上線有風險，而決定分批上線降低項目整體的風險。在獲悉真實情況后，M通過自己的高層領導將項目變更的風險向對方的高層領導進行說明，爭取了一次寶貴的雙方高層領導都參與的項目說明會。會前安排項目骨干將項目的實際情況以及如果按此方案實行所帶來的巨大風險通過數據加以細致分析并形成匯報材料。在會上把握住對方最在意的是項目能否平穩順利上線運行，而縮短時間相對次要的心理，站在客戶的角度盡可能充分論證。在對方態度軟化以后，隨即提出解決方案，重新規劃項目工作計劃，需要多投入一部分資源，從而達到項目整體可以提前進行試運行降低項目整體風險的目的，不過需要客戶追加一部分預算。客戶方在權衡利弊之后同意了該方案。
在這個案例里，我們可以看到，項目經理在解釋無效的情況下，冷靜地利用自己的高層領導搞清對方的真實意圖。進而充分準備，論證了客戶的方案其實風險更大，并沒有達到降低風險的目的。最后，在獲得客戶理解的基礎上，提出了雙方都能接受的合理方案。從而化解了一個棘手問題。
六、總結
項目溝通是個復雜的管理任務。通過本文，我們可以知道，要對項目干系人進行有效的識別，深挖需求。進而針對性的建立合理的溝通規則和體系。避免出現不必要的誤會。希望能讓良好的溝通成為潤滑劑，向項目這臺機器平穩高效地運轉，最終建成直沖云霄的通天塔。
