專案管理知識體系之溝通管理

溝通，是一種對所學知識的綜合應用，這是我最近又體悟出的乙個道理。溝通管理，是專案管理知識體系中非常重要的一部分，所以在學習專案管理的時候，也把相關的知識作為重點內容來研讀。但是，總感覺這部分內容可操作性比較差、比較難應用。

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

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

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

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

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

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

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

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

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

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

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

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

function imgzoom(id)//重新設定大小防止撐破** else } window.onload = function() { var imgs = $("content").getelementsbytagname("img"); var i=0; for(;i

專案管理知識體系之溝通管理

專案管理知識體系

專案管理知識體系

專案管理知識體系（PMBOK）

相關推薦