項目管理就是指把各種系統、方法和人員結合在一起，在規定的時間、預算和質量目標范圍內完成項目的各項工作。項目管理的內容涉及到諸多方面，比如項目的計劃、控制、度量等等，而在這些過程當中，溝通是貫穿始終，必不可少的一個工作，我記得上次在清華光環管理培訓中心的調研面試中，面對老師的提問“你認為溝通應該占項目經理日常工作的百分之多少？”，我說“項目經理日常工作的80%”，“那剩下的20%做什么？”我說“剩下的20%就是準備溝通的內容，以期達到溝通的目的”。雖然答復有些許夸張，但是溝通確實已經成為項目經理日常工作的一個重要組成部分，而且是貫穿項目整個生命周期的一項持久工作，這項工作的好與壞直接影響項目的過程控制和最終的項目質量。　　　
　　一、積極有效的溝通　
　　溝通管理的目的就是要保證項目信息及時、正確的提取、收集、傳播、存儲以及最終進行處置，保證項目組內部的信息暢通。在這過程當中，項目經理責無旁貸的成為信息傳輸的中心和中轉站，同時又要避免成為信息流通的瓶頸。我認為項目的溝通主要包括與業務部門的溝通、與部門領導的溝通、項目組內成員之間的溝通（包括與項目組中外部資源的溝通）、與外聯公司的溝通和與其他兄弟部門（包括CS中心、NFSJ中心）之間的溝通等等。　　　
　　1、與業務部門的溝通　　　
　　與業務部門的溝通一般從項目前期階段就開始了，在這工作當中，我想有以下幾點需要注意：。充分分析業務部門的需求，以及需求的重點部分，溝通做到有的放矢；
　　。讓對方在一定程度上（即有利于項目組工作開展的程度上）了解項目組的現實情況，有困難一定先提出來，增進雙方的相互理解；
　　。在需求溝通中，業務的專家地位可能不很明顯，項目組在有條件的前提下可以更加深入的參與業務需求討論，甚至引導需求，即技術引導業務；
　　。在項目過程當中形成前期積極進行需求挖掘、中期合理安排客戶體驗、后期協調驗證測試的良性循環；
　　。如果溝通效果不理想，要及時上升問題的高度，尋求各級相關領導和職能部門的協助，合理的借用外部力量達到項目組的既定目標-項目成功。
　　這里我舉BYXM部一位項目經理的項目作為案例加以說明，《XX項目》，這個項目涉及的對賬系統決算規模380（人天），理論工期7.8月，實際工期2.2月。涉及：6個系統。預估版本缺陷密度為46（ZX平均15.3）。最后該項目得以成功完成，并順利投產。業務反饋極佳，并發來感謝信，在上次中心滿意度調查中也給予了很高的分數。其實該項目實際情況是：時間非常緊，任務也很重，而且需求不明確，配合公司由于商務問題不能及時支持，可以說困難重重。但從項目開始到結束，項目組在項目經理的領導下與業務代表時刻保持著緊密的溝通，對于存在的各種問題從不拖延解決，每天將項目各階段的進度情況發與項目干系人了解，保證各方面信息的一致性。項目組成員包括業務人員短期內成為了一個團結而緊密的團體，業務人員也能夠了解項目組成員為此付出的努力，并打下了良好的客戶基礎。
　　其實很多情況下，業務人員對我們的項目最后的交付成果不滿意，關鍵是在缺乏溝通的背景下，我們最后的交付成果和他們的預期產生了偏差。而如果在項目整個生命周期中能不斷的安排業務來進行討論、分析和體驗，那么就可以主動的調整和完善業務代表對我們項目、對我們系統的預期值，這樣最后的項目不論多么困難，業務也都是有心里準備的，同時在這個溝通的過程當中，他們一定也會體諒到我們的實際困難，看到了我們為此做出的盡可能多的努力，這樣的項目最后的業務部門反饋的結果一定不會差。
　　2、與部門領導的溝通　
　　與部門領導的溝通在項目管理過程當中是不可避免的，由于目前中心的矩陣結構管理模式中，職能部門的權限要大于項目經理的權限，所以項目經理在項目管理中一定會不斷的和各職能部門經理打交道，同時項目經理還要定期的向本部門領導匯報項目情況，尋求項目支持。我認為與部門領導的溝通有以下幾點需要注意：
　　。尋求支持的郵件一定要簡練的描述清楚問題的關鍵所在，需要領導哪方面的具體支持，最好根據具體問題給領導1-3個選擇，并指出項目組傾向于哪個選擇，原因是什么，而不是把問題直接扔給領導；
　　。一定要清楚各級領導的權限和角色，解決問題時一定是要找到關鍵路徑上的關鍵領導，避免信息同時發布多個領導，造成領導之間的溝通成本加大，影響問題的解決效率，增加領導協調解決問題的難度；
　　。對于有些問題，不要一味的向領導妥協，不要一味的承諾實際不可能完成的項目工作，這既是對工作的負責，也是對領導、對項目組的負責。　　　
　　3、與項目組成員之間的溝通
　　對于項目經理來說，規模較大的項目主要是與各應用的專業經理以及架構師之間的溝通。這里我用自己帶的一個項目來說明一些需要關注的問題。
　　《XX項目》在系統測試階段，開發經理和測試經理關于提交的測試問題數量存在爭論，開發經理認為測試部門提交問題重復，且數量過多；而測試經理認為項目辦對于測試部門給出了測試標桿值，她是按照這個來執行的，而且她認為開發經理一味偏袒開發人員，且拒絕修改的問題答復過于簡單。針對以上這些情況，我首先了解了一下標桿值的問題，這個值是項目辦根據每個應用以往的歷史數據給出的每百功能點發版前的問題數參考值，比如該項目涉及的參數管理應用是百功能點13點多個問題，但這只是一個參考值，所以測試經理以此作為依據進行問題數目的控制是不必要的。同時我去測試經理那里了解了一下實際情況，部分問題確實是相同問題，但是BYCS部的要求是回復的時候可以選擇相同問題回復，但是不要直接打回拒絕修改且寫明是相同問題，這也是L總在測試部門內部一再強調的，所以碰到這種情況測試經理堅決不會同意關閉。同時我在開發這邊了解到，開發人員對于一個公用模塊提多個問題非常反感，修改一處程序而填寫問題清單的時候要填寫多條記錄，而且開發經理反饋實際上其它測試人員提交的重復問題并不多，而測試經理本人提交的很多，感覺測試經理有意而為之。針對這種情況，我和開發經理、測試經理溝通之后做了如下要求：首先為了保證測試進度和質量，測試方面發現問題該提就提，但是沒有必要以測試標桿給出的值作為測試標準，要以實際情況為準；其次，開發人員和測試人員多溝通，從源頭上避免一個公共模塊提多個問題的情況，但如果一旦問題提交了，開發人員就按照相同問題處理，不要拒絕修改，這個我也告知了開發經理對于項目的有效問題數不會有影響。同時由于考慮到個人面子問題，我和測試經理單獨做了溝通，請她避免提交過多相同類型的問題，提交之前可以先和開發經理打個招呼。另外我也請兩位專業經理考慮，由于項目所涉及應用之后的所有牽頭配合項目都是兩位專業經理配合工作，到底是一個和諧的工作氛圍還是一個充滿火藥味的工作氛圍對雙方更好？目前項目系統測試已經完成85％，問題解決效率平均不超過2天，問題數也控制在百功能點8個左右，開發部門和測試部門均較為滿意這樣的結果。
　　從這個案例當中，我認為關鍵在于項目經理接收到各方面信息之后，不要急于做出結論，因為這個結論很可能是以偏概全或者根本就是錯誤的，要對信息進行有效的確認。同時在溝通過程當中項目經理要做到立場的合理切換，有時候要站在項目的立場上、有時候站在專業經理的立場上。最后一點就是要堅持項目管理過程當中的公正、公平原則，對項目所涉及應用不偏不倚，只談問題的解決不談其余的個人問題。