談談IT項目中的溝通管理

談談IT項目中的溝通管理

--------------------------------------
作者：王輝
發布日期：2002-12-30
--------------------------------------

1 前言

在IT項目中，要做到一個項目迅速成功的完成，并能達到或者超過預先設計好的效果，是很不容易的，在完成所下達的任務當中，設計好的藍圖跟具體的實諸于實踐，既要有規定統一的制定計劃，還要有一套適時的監控執行方法，但同時又不能扼殺了整個項目開發中的創造性和自主性，這樣，就必須有一個靈活而且容易使用的溝通方法的過程，從而使一些的重要的項目信息時時最新，做到實時同步。
在IT項目中，許多專家都認為：對于成功，威脅最大的就是溝通的失敗。與IT項目成功的三個主要因素分別為：用戶的積極參與，明確的需求表達，管理層的大力支持。而這三要素全部依賴于良好的溝通技巧，特別是非信息技術人員。
溝通管理的目標是及時并適當地創建、收集、發送、儲存和處理項目的信息，標準的項目溝通包含溝通計劃、信息傳遞、實施情況報告、管理收尾共四個過程。
本文將談談一些本人在溝通管理實踐中的一些經驗。

2 制定溝通計劃

在項目立項后，第一步就要制定《溝通計劃》，《溝通計劃》應包括以下內容：

Ø 文件保存方式：在溝通計劃中首先明確信息保存方式、信息讀寫的權限，明確用戶信件、會議記錄、工作報告、項目文檔（需求、設計、編碼、發布程序等）、輔助文檔等的存放位置，及相應的讀寫權力。這樣用于收集和保存不同類型的信息，有必要制定和遵循一個規定好了的統一規章制度，將與項目有關的重要工作建檔。

Ø 聯系方式：應該有一個專用于項目管理中所有的相關的人員的聯系方式的小冊子，其中如項目組成員、項目組上級領導、行政部人員、技術支持人員、出差定房訂票等系統中相關的人員，座機、手機、職能等等，應相應的一一列上，做到簡潔又要明了 ，最好能有特殊人員的一些細小的標注，能夠做到在一打開小冊子的同時就能將所有的相關人員的資料了然于胸，正所謂知已知彼，這樣一來，很多在平時大費周章的事，就能在養成的良好的習慣中，輕松做到。 

Ø 工作匯報方式：明確表達項目組成員對項目經理或項目經理對上級和相干人員的工作匯報方式，明確什么時間，什么形式。比如項目組成員對項目經理通過EMAIL發送周報；項目經理對直接客戶和上級按月通過EMAIL發月報的方式；緊急匯報通過電話及時溝通；每兩周項目組進行一次當前工作溝通會議；每周同客戶和上級進行一次口頭匯報等等。
Ø 統一項目文件格式：對于一個項目本身統一的文件模板，是正規管理的一部分，所以必須統一各種文件模板，并提供編寫指南。

Ø 《溝通計劃》維護人：明確本計劃在發行變化時，由誰進行修訂，并對相關人員發送。

由于《溝通計劃》是同很多人員有相關的，必須保證計劃是有相關干系人參于制訂，并且保證《溝通計劃》是相當人員已經正解接收及理解。計劃是用來執行的，而不是為計劃而計劃束之高閣。

3 信息發送

對于項目管理的信息正確傳達到相應的人員，是相當重要并有一定的困難的，經常發生的事情是信息發送人感到自己把信息正確傳達了，但實際的結果卻是信息沒有傳達到或是被錯誤的理解了。太多的人還是不太習慣成堆的文件或者通篇的E-MAIL傳送的郵件，如果能利用非正式的方式或者是雙方會談的方式來聽取重要的信息，就來得又快又準確更能讓人接受，就象傳統里的一紙書信在某些場合還是比任一現代化的聯系方式來得好一樣，價值取向不同，溝通的方式也就在使用效果上全然不一樣了。 　　　　　　　　　　　　
我們在溝通中應遵循彼得.德魯克提出的四個基本法則：
Ø 溝通是一種感知
Ø 溝通是一種期望
Ø 溝通產生要求
Ø 信息不是溝通
本人在通過學習及結合實踐的過程中得到以下的感受。

3.1 溝通是一種感知

溝通一定是雙向，必須保證信息被接收者接到了。所有的溝通方式，必須有回饋機制，保證接收者接收到。比如：電子郵件進行溝通，無論是接收者簡單回復“已收到、OK”等，還是電話回答收到，但必須保證接收者收到信息，并回應信息已經接收到。
信息收到必須保證理解是正確的，很多事情信息收到了，但被錯誤的理解了，很多信息是傳達到了，但卻被錯誤理解了。
比如：A項目經理對B項目經理說“今天我要去投標，不過我這邊的現在人手少，你那邊可否抽些人過來幫我壯壯聲勢”。
B項目經理手中有一些程序員和系統分析員，而當前程序員有些空閑人手，系統分析員今天正好有些緊急工作，但B項目經理錯誤理解為A項目經理需要的人是系統分析員，到時協助答辯，所以回答“不行，今天正好有緊急工作，沒有辦法幫忙”。
A項目經理只好另想辦法。
以上就是典型的理解錯誤，發送方的正確表達、接收者的正確理解是非常重要的。比較簡單的方式是發送者進行信息發送，接收者進行理解后進行細化并進行二次表達，但這種表達卻是在確認自己理解了的同時去轉敘或者執行的結果，而不是復述。

3.2 溝通是一種期望

在項目管理中，項目不同干系人是有不同的溝通需要的。
項目組成員在具體的工作安排中他想明白那個職位是否符合他的意愿等等，上級要了解接收者的期望，向下屬傳達工作安排的同時還要了解他的意愿取向的問題，再采取相應的方法，調起其在工作上的熱情，從而促使其在工作的高效付出，在項目管理中如讓下屬有反抗情緒的產生或者低效的工作，則是一個項目經理在溝通上不得法的一個失敗實例。因此制定一個協調的溝通計劃就更為重要了。
而項目經理的上級和客戶更加關心是進度的問題：時間是否會延期、是否要添加成本、質量是否有保障等等。這對于項目經理來說，就應即時的反饋這些時間，特別是將會有延期、將添加項目成本、質量將會有問題的苗頭等等，更加必須提早匯報，使項目經理的上級和客戶能及時并適時調整工作計劃。

3.3 溝通產生要求

溝通是雙向的，溝通必須能夠符合接收者的利益，那樣才有說服力。這就要求雙方都要有良好的溝通方式，特別是良好的溝通又能達到雙贏的目的，一致的溝通有助于組織促進項目更新。
口頭的溝通能力同時似乎又是職位提升的關鍵因素。于是，溝通又必然的產生要求，比如：職位上成功，項目的早日完成，對問題作出恰當的回應，小到假期薪金等等都要溝通來達到目的。

3.4 信息不是溝通

當前是信息時代，必須分清哪些是溝通哪些是信息，對于用于溝通的信息必須明確簡練、醒目，避免沉沒于信息之海中。
信息也可用于溝通，但信息過于的生搬硬套，一個文字性的文件是并不能起到溝通的作用的，在項目中，項目經理并不是想集中于信息中而是想了解項目里工作的人員，并與之建立起相互信任的關系。而有效的發送信息，只能是依賴于項目經理和項目組成員的良好的溝通技能。
我們現在就能通過上面的四個法則來進行有效的溝通，達到保證管理中信息有效傳達的目的了。

4 實施情況報告

實施情況報告一般有三種形式：定期報告，階段審查，緊急報告。

Ø 定期報告：就是在某一特定的時間內將所完成的工作量向上級匯報。在實際的項目管理中項目人員對項目經理按周報告，對于客戶和項目經理的直接上級是按階段或月進行統一的進展報告，從項目管理上講，項目定期報告的主要內容就包括：當前是什么狀態？在什么階段？進度完成情況？當前有什么問題請上級（用戶）協助解決？下周（下階段或下月）的計劃是什么等等。

Ø 階段評審：在項目進行到重要的階段或里程碑似的項目發展階段，就要進行階段評審。階段評審的意義就在于評審當前的項目情況，迫使人們對其工作負責；階段評審可以提前發現問題，提前將問題解決在初期階段。不過階段評審也是最容易產生爭執的地方，這主要是針對于問題嚴重性的定級，項目經理或項目管理委員會必須在全面了解項目發展進展的情況下及時找到問題的重點，從而就事論事的解決問題的真正癥結所在，并進行后面的項目。

Ø 緊急報告：在出現意外情況下，進行緊急報告。緊急報告包括以下內容：當前發現的問題，相關影響，需如何解決（動用什么資源），問題緊迫性（必須什么時間內進行反饋）。

在實際的項目管理過程中，質量管理的質量保證部門也將進行質量審計，按階段提交質量審計報告。
項目干系人接到實施情況報告后也應即時的進行反饋，明確報告已經成功接收到。并讓項目干系人一道解決執行中的問題。

5 管理收尾

5.1 項目客戶驗收

項目收尾期間客戶將根據合同對項目進行驗收，一般是對最終成果《軟件系統》，項目文檔《操作手冊》、《安裝手冊》、《軟件光盤》、《維護計劃》或《維護手冊》進行驗收，雙方將產生雙方《項目開發總結報告》及《項目總結會議備忘錄》
不同的人都有不同的見解，這些報告都是極好的資源，對未來項目的平穩運行有很大的幫助。

5.2 過程文件歸檔

項目組內部將對項目過程中的計劃、需求、設計、源代碼、變更、會議紀要、客戶信件等文檔整理歸檔，為以后的查詢及參考作為一定的依據。項目檔案常常在結束多年以后還有用，良好的項目檔案能為當前的項目節省時間和金錢，有時還能對組織進行審計等快速提供有價值的信息。

5.3 項目總結

很多項目沒有能進行很好的總結，推脫的理由有項目總結時項目人員已經不足/不全、現在有新的項目要接沒有時間、寫了沒人看等等。這些理由全不是正確的，無論如何也要進行總結，只能總結當前，才能提高以后。
項目的成員應當在項目完成后，為取得的經驗和教訓寫一《項目總結報告》，總結在本項目中哪些方法和事情使項目進行的更好、哪些為項目制造了麻煩、以后應在項目中避免什么情況、那些事情應在后面的項目中堅持等等。為以后的項目人員更好的工作提供一個極好的資源和依據。

6 關于作者

王輝　從1994年開始工作，曾是一名ORACEL和DB2數據庫管理員、JAVA、VB及C程序員，現在深圳一家公司擔任項目經理?？梢酝ㄟ^ddxxkk@21cn.com聯系。
　　　　　　　　　　　　　　　　　　　　　　　　　                 

2002/10/08

原文轉自：http://www.anti-gravitydesign.com