溝通，是一種對所學知識的綜合應用，這是我最近又體悟出的一個道理。

溝通管理，是項目管理知識體系中非常重要的一部分，所以在學習項目管理的時候，也把相關的知識作為重點內容來研讀。但是，總感 覺這部分內容可操作性比較差、比較難應用。

前段時間，個人在項目管理俱樂部活動上，作為嘉賓分享了個人對溝通管理的一些理解，現在想來很是慚愧，因為那次活動直到結束，我也沒有很明顯的感覺到自己講的主題，盡管在之前做了好長時間的準備，盡管有幾個朋友做了良好的評價，但我還是不能保證能有一種我的觀點深入在場人的心。現在想來，我倒更愿意把那個時候對溝通管理的理解劃作為第一階段，也就是了解了一些溝通的基本形式、初步認識到溝通的重要性的一個階段。

溝通的重要性是大家都能說出來的，也是許多人都已經認識到的。但是，要實際去做才會有效果。如果要實際做，不僅僅是如何做的問題，還有一個做什么的問題。很多關于項目管理的書籍上都寫了，項目管理者要花費70%以上的時間溝通，但是，并沒有任何一種項目管理的書籍用70%的篇幅來告訴我們如何進行溝通。

項目管理是一個知識體系，越來越被更多的人重視。也只有對項目管理的知識有比較深入的理解，才可能去應用這些知識去進行實際的溝通。比如，當因某個團隊成員落后于大家的進度而使里程碑的實現延誤，作為項目管理者，要去與他溝通，那么我們是應該批評責怪還是找到問題的所在？理智的講，我們要選擇后者，可實際中，往往是前種結果發生得多一些，或者先責備再找問題。可我們知道，計劃的延誤與很多方面有關。

首先是里程碑的制定是不是合理。有一個“零缺點里程碑”的概念，所謂零缺點，并不代表軟件中沒有錯誤，也不表示沒有遺漏的功能，而是指團隊的成品經過測試驗證達到了事先規劃的品質水準，這就要求對一些要求要有明確的敘述。同時，每一個里程碑應有專屬的宗旨，比如手機研發過程中，軟件會對應GCF或者某次CDG測試，那么滿足這些測試的要求的相關模塊是有較高優先級的，不關鍵模塊的要求在里程碑中可以訂得低一些。

其次是團隊的建設方面，任務分配和相互協調是否到位。研發的過程本來就是動態的，充滿合宜與沖突、憤怒與喜悅，團隊的行為是變幻莫測，基本上不能以組員的心情愉快與否、日程落后與否、或是表面上的行為與事件來判斷整個團隊行為是否正常。目標的確定要達到團隊共識，并且要讓整個團隊共同承擔達到里程碑的責任，除非每個人都達到，否則就算沒有人達到里程碑。

再次是平時對項目進展的關心程度是否到位。落后不是一天造成的，落后不是到了到了里程碑的時候才出現的，也不是到檢查點前一天才發生的，它每天都在發生，每小時都會發生。當然，關注的方法有很多，團隊成員彼此之間的工作時程有上下游和回饋的關系，彼此互相依賴彼此的進度，于是形成了實施檢查點的動機，而不一定要是靠管理者的鐵腕來強制。

還有就是是否關注到團隊成員的技術水平，安排的任務是不是很明顯超出了他的能力范圍。如果在手機的研發過程中讓一個剛畢業的學生負責打電話模塊，就是一種不合適的安排。

所有的這一切，任何一點出了問題，都應當是項目管理者的責任，而與開發人員無關。如果我們希望能通過開發人員的優異表現而掩蓋自己的管理漏洞，這實在是一種不情之請，也太冒險。

作為“拖后腿”的當事人，他已經承受了懊惱、自責。相信我們團隊中的每一個人都會很自覺地反省自己的過失，不管是由于自己的懶惰、低效率還是知識欠缺而造成不好的后果，他都會很自覺地承擔。看到過這么一段話：一般來說，只要是健康的團隊，不論成員的素質高低或是延誤的情形嚴重與否，發生延誤的組員都會覺得不好意思，而主動試著解決它，他會嘗試修正對自己的期望，改善自己的工作效率或工作方法。管理者應該幫助他，責難他是愚蠢的行為，就好像責怪某一片葉子怎么可以從樹上掉下來一樣沒有意義。

所以這個時候，我們應該與團隊人員一起去找出問題的真正原因。

這樣看來，如果一個人沒有里程碑、計劃、團隊建設方面的管理知識，相信會本能地去責怪團隊成員，或者即便不責備，也只是讓團隊成員反省，從開發人員的角度找原因，那么，事情發生的真正原因也許就不會被發現。整個溝通就不算很有效。

從這個意義上說，溝通管理，也是一種知識體系。這些知識，構成了溝通的基礎，沒有這些基礎，講溝通管理就是海市蜃樓。而如果我們僅掌握了其中的一點或一面，溝通都不會做得很好。換句話說，如果想真正做好溝通管理，各方面的知識都要懂才行。

來源：計世網