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