在項目管理過程中我們可能都曾遇到類似這樣的問題，在進行項目階段性成果檢查時， 發(fā)現(xiàn)客戶的實際要求和開發(fā)的功能不相吻合，或者客戶所要求的某種屬性并沒有得到體現(xiàn)，或在設計過程中，
開發(fā)人員開發(fā)出的內容與設計要求大相徑庭等等問題。究其原因，都是由于沒有做好充分、有效的溝通。項目需要充分的溝通，以達到明確的項目目標、清晰的工作職責、明晰的項目需求等。溝通障礙可能會造成項目返工，影響項目進度和成本，甚至會導致項目的失敗。
有人說，在項目管理中，項目經(jīng)理的工作有80%是溝通，而剩下的20%則是在為溝通作準備，此話一點也不過分。所以，溝通已經(jīng)成為項目經(jīng)理日常工作的一個重要組成部分，貫穿項目生命周期始終，它直接影響項目的過程控制和項目的最終質量。
在實際的工作中，本人認為導致溝通問題的原因主要有：
一、不正確的溝通態(tài)度。第一種，項目經(jīng)理和項目組成員都是"高科技人員"，就導致"我以為"的錯誤，太過自信沒有認真確認溝通；第二種是，不敢溝通，不敢和客戶溝通、不敢和上級領導溝通尤其是跨部門的溝通，
害怕被拒絕， 害怕溝通中遇到的阻力；第三種懶得溝通，認為這么簡單的東西不用溝通，憑自己的理解就可以完成等等，導致出現(xiàn)偏差。
二、人的惰性。因為人的惰性，有些用戶可能并不會認真確認用戶需求文檔，只有到系統(tǒng)完全做出來了，才會提出有些內容是需求理解錯誤；有些開發(fā)人員也不會認真看設計文檔，而是直接就去開發(fā)； 項目相關的文檔不能及時地根據(jù)變化進行修改和更新等等。
三、缺乏正確的溝通技巧。因為沒有選擇正確有效的溝通方法導致和客戶溝通失敗， 因沒有一個暢通的溝通機制導致設計與開發(fā)產生偏差。所以，對于項目經(jīng)理應具備一定的敏感度和懂得依據(jù)具體的需要使用不同的溝通技巧知識。
當然，我認為溝通中更重要的是真誠的態(tài)度， 這樣才有可能和溝通對象建立良好的信任關系。
四、項目的時間約束。一方面項目的開發(fā)時間是有限制的，往往為了追求項目的進度而忽視或者是壓縮溝通時間； 而另一方面客戶的時間也是有約束的， 往往客戶是沒有專職人員全程去跟項目， 就導致常常會因為客戶沒有時間而無法進行正常的項目溝通導致項目推后。
那我們應該如何加強溝通呢？一是積極有效溝通態(tài)度。我認為項目經(jīng)理在整個項目中理所當然的承擔著溝通的信息收集傳遞和中轉的工作。項目經(jīng)理應積極主動地去與相關人員進行溝通，保證項目順暢進行，當溝通效果不理想，要通過及時上升問題的高度，尋求各級相關領導和職能部門的協(xié)助，通過
合理地借用外部力量來達到項目組的既定目標。
1、與客戶的溝通。
  用戶需求是信息項目的開發(fā)基礎， 正確清晰的了解用戶需求對項目開發(fā)起到事半功倍的效果， 那如何做好與客戶的溝通那，我認為有幾個方面：
第一是，作為項目經(jīng)理要充分的了解業(yè)務，有重點的進行溝通，做到有的放矢；
第二是，項目經(jīng)理要用引導的方式與客戶溝通，因為客戶往往不是技術人員，并了解需求的表述要到怎樣的程度，所以項目經(jīng)理要引導客戶講出；
第三是，要及時讓客戶了解項目進展狀況和遇到的問題，讓對方在一定程度上了解項目的現(xiàn)實情況， 這樣可以增進雙方的相互理解，有利于項目工作開展；
第四是，要客戶及時參與到項目的測試中來，通過讓客戶盡早介入體驗項目成果，減少項目后期的修改運維工作量。
第五是， 提前做好溝通計劃， 避免因為不能配合客戶的時間，約不到客戶，而導致項目推遲，無謂的增加項目等待時間。
2、與部門領導的溝通
  不同的單位項目組的組織機構矩陣不同， 但都需要與自己部門領導或相關之職能部門的領導進行溝通。我認為與部門領導的溝通時需要注意幾點：
第一，當遇到問題需要部門領導給予支持時，要能夠簡明扼要的說明問題，明確需要領導哪方面的支持。
第二，問題應該怎樣解決自己要先有思路，明確方案1、2、3，說明項目組傾向于選擇哪個方案，原因是什么，然后再由領導作決策，而不是把問題直接扔給領導；
第三，不要一味的向領導妥協(xié)。有些問題一味的承諾不切實際的去做，會嚴重影響項目工作，所以應依據(jù)實際情況，對領導講明原因，使項目順利開展，這既是對工作負責，也是對領導、對項目組負責。
3、項目組內部的溝通
  有些項目經(jīng)理認為，項目組成員每天都在一起，就不需要特別的溝通，其實這是不正確的，就算是項目組內部也應該建立溝通機制，因為項目的開發(fā)是項目團隊整體努力的結果，如果項目組成員不能及時了解到其他的功能開發(fā)、變更情況，
而導致相關功能開發(fā)的信息不對稱而影響了整體的開發(fā)。二是使用正確有效的溝通方法。溝通方式可以分為書面溝通和口頭溝通， 也可以分為正式和非正式。項目經(jīng)理應該依據(jù)項目的實際情況和場景來選擇不同的溝通方式。
書面的溝通大多是用來進行通知、確認和要求等活動，包括郵件、周報、正式函件、文書等。書面溝通時語言文字可以多次修改完善、內容準確可信、信息準確性高，但往往不夠直接，在一定程度上可能會影響到信息傳遞的意義?？陬^溝通一般包括會議、面對面交談、電話、討論等。
這個方式比較直接，簡單有效，比較容易被大多數(shù)人接受，但它無法像書面溝通一樣留下"字據(jù)"，所以不適宜用類似確認這樣的溝通。如何有效地利用這些方式使得能夠清晰有效的溝通得到預期的目的：一是可以通過制定有效的溝通制度和溝通機制，如定期召開制定工作規(guī)劃、制訂溝通計劃、項目周報等方式來保證信息的有效溝通，遏制人的惰性；
二是應采用多種溝通方式并用的方式，來保證溝通的信息確保傳達到位；三是利用一些工具來協(xié)助加強溝通，比如通過郵件、網(wǎng)絡、相關管理工具等等。
三是良好的沖突管理策略。項目中難免會有沖突發(fā)生，沖突解決得好不好，對于項目成功影響非常大。有人說項目是怎么做出來的，是可以用來存儲空間多比例尺數(shù)據(jù)、專題屬性數(shù)據(jù)、系統(tǒng)數(shù)據(jù)等。
在服務器端，地理數(shù)據(jù)和GIS 功能服務都被設計成"地理信息資源"，有相應的URI 和允許的HTTP 操作（即RESTful API），例如執(zhí)行DELETE http://mysite/layer/2/feature/36 請求， 即可刪除Layer 2 中ID 為36 的要素。
4、REST 風格的地理信息Web 服務實例
  通過對體系結構和關鍵技術的分析與設計， 基于IIS 服務器，Visual Studio 2008 開發(fā)平臺， 以及WCF REST Starter KitPreview 2、OpenLayers、SharpMap、SQL Server 等軟件或組件， 實現(xiàn)了一個REST 風格的地理要素（Feature）Web 服務及其客戶端。
4.1 RESTful 地理要素服務實現(xiàn)
  首先， 在后臺SQL Server 數(shù)據(jù)庫中新建了一個用于存儲圖層要素數(shù)據(jù)的表Scribble，其字段包括Id、The_geom、Type、Title、strokeColor、Author、MinX、MinY、MaxX 和MaxY 等，其中The_geom 字段存儲要素的坐標數(shù)據(jù)，
采用Well-Known Binary（WKB）的方式。然后，在VS.NET 平臺下利用WCF、ADO.NET 實體數(shù)據(jù)模型等框架進行了服務的邏輯代碼實現(xiàn)， 服務采用IIS 作為宿主。
1）HTTP GET <baseURI >/scribbles?f ={format}&maxfeatures={num}&bbox ={bbox}& where ={exps}&location ={loc}&polygon ={coords}&text={text}， 用來查詢Scribble 圖層中的Scribble 要素，并返回相應形式的表現(xiàn)。
其中，format 代表返回格式，包括XML、JSON、GML、KML 和GeoRSS；maxfeatures 指定返回結果的最大數(shù)目；bbox 指定矩形框范圍；where 指定屬性查詢表達式；location 指定一個坐標位置；polygon 指定一個多邊形范圍；text指定默認字段包含的文本；如果沒有查詢字符串，將返回圖層內所有Scribble 要素。
2）HTTP GET <baseURI>/scribble/{id}.{format}，用來請求對應id 的Scribble 相應格式的表現(xiàn)，format 包括XML、GeoJSON、GML、KML、GeoRSS、HTML 和圖片格式。例如，圖2 和圖3 分別是id 為13 這個Scribble 的GeoJSON 和HTML 格式的表現(xiàn)。
3）HTTP POST <baseURI >/scribbles. {xml/json}; body ={newXML/newJSON}，用來添加新的Scribble，并返回該feature 相應格式的表現(xiàn)和它的URL，body 中是要新建的Scribble 的表現(xiàn)數(shù)據(jù)，支持XML 和JSON 格式。
4）HTTP PUT <baseURI >/scribble/{id}. {xml/json}; body ={newXML/newJSON}， 用來更新對應id 的Scribble 數(shù)據(jù)，body 中就是期望的新狀態(tài)表現(xiàn)數(shù)據(jù)，同樣支持XML 和JSON 格式。
5）HTTP DELETE <baseURI>/scribble/{id}，用來刪除對應的Scribble。
4.2 客戶端實現(xiàn)舉例
  利用HTML、JavaScript 腳本和OpenLayers 開源組件實現(xiàn)了一個Ajax 創(chuàng)建和上傳要素客戶端，界面。首先，可以查詢不同格式的所有Scribble 數(shù)據(jù)集合； 其次， 在圖上畫出點、線或面并設置相應屬性后會生成該要素的JSON 字符串，
然后點擊上傳便可添加新的要素到服務器； 并且可以連續(xù)畫出多個要素后一起上傳。
5、結語
  REST 架構風格的地理信息Web 服務優(yōu)勢明顯， 是否將替代傳統(tǒng)的RPC 式的架構現(xiàn)在還不得而知， 但是由于其簡單易用， 能夠達到Web 級的規(guī)?？缮炜s性， 而且容易進行互操作、Mashup，服務的開發(fā)者們現(xiàn)在更傾向于開發(fā)這種服務。
目前，網(wǎng)絡中REST 風格的Web 服務越來越多，據(jù)著名的Web 2. 0 網(wǎng)站programmableweb. com 統(tǒng)計，目前可用的REST APIs 占67%，而SOAP APIs 占20%[7]。ESRI、Yahoo 等公司都已經(jīng)或開始采用了REST 風格的Web 服務。
本研究所實現(xiàn)的REST 風格的地理信息Web 服務非常有限，目的是為了探索REST 服務在GIS 領域的應用，結合微軟最新的開發(fā)框架進行實現(xiàn)， 希望在后續(xù)的研究工作中能進一步擴展。