在项目管理过程中我们可能都曾遇到类似这样的问题，在进行项目阶段性成果检查时， 发现客户的实际要求和开发的功能不相吻合，或者客户所要求的某种属性并没有得到体现，或在设计过程中，
开发人员开发出的内容与设计要求大相径庭等等问题。究其原因，都是由于没有做好充分、有效的沟通。项目需要充分的沟通，以达到明确的项目目标、清晰的工作职责、明晰的项目需求等。沟通障碍可能会造成项目返工，影响项目进度和成本，甚至会导致项目的失败。
有人说，在项目管理中，项目经理的工作有80%是沟通，而剩下的20%则是在为沟通作准备，此话一点也不过分。所以，沟通已经成为项目经理日常工作的一个重要组成部分，贯穿项目生命周期始终，它直接影响项目的过程控制和项目的最终质量。
在实际的工作中，本人认为导致沟通问题的原因主要有：
一、不正确的沟通态度。第一种，项目经理和项目组成员都是"高科技人员"，就导致"我以为"的错误，太过自信没有认真确认沟通；第二种是，不敢沟通，不敢和客户沟通、不敢和上级领导沟通尤其是跨部门的沟通，
害怕被拒绝， 害怕沟通中遇到的阻力；第三种懒得沟通，认为这么简单的东西不用沟通，凭自己的理解就可以完成等等，导致出现偏差。
二、人的惰性。因为人的惰性，有些用户可能并不会认真确认用户需求文档，只有到系统完全做出来了，才会提出有些内容是需求理解错误；有些开发人员也不会认真看设计文档，而是直接就去开发； 项目相关的文档不能及时地根据变化进行修改和更新等等。
三、缺乏正确的沟通技巧。因为没有选择正确有效的沟通方法导致和客户沟通失败， 因没有一个畅通的沟通机制导致设计与开发产生偏差。所以，对于项目经理应具备一定的敏感度和懂得依据具体的需要使用不同的沟通技巧知识。
当然，我认为沟通中更重要的是真诚的态度， 这样才有可能和沟通对象建立良好的信任关系。
四、项目的时间约束。一方面项目的开发时间是有限制的，往往为了追求项目的进度而忽视或者是压缩沟通时间； 而另一方面客户的时间也是有约束的， 往往客户是没有专职人员全程去跟项目， 就导致常常会因为客户没有时间而无法进行正常的项目沟通导致项目推后。
那我们应该如何加强沟通呢？一是积极有效沟通态度。我认为项目经理在整个项目中理所当然的承担着沟通的信息收集传递和中转的工作。项目经理应积极主动地去与相关人员进行沟通，保证项目顺畅进行，当沟通效果不理想，要通过及时上升问题的高度，寻求各级相关领导和职能部门的协助，通过
合理地借用外部力量来达到项目组的既定目标。
1、与客户的沟通。
  用户需求是信息项目的开发基础， 正确清晰的了解用户需求对项目开发起到事半功倍的效果， 那如何做好与客户的沟通那，我认为有几个方面：
第一是，作为项目经理要充分的了解业务，有重点的进行沟通，做到有的放矢；
第二是，项目经理要用引导的方式与客户沟通，因为客户往往不是技术人员，并了解需求的表述要到怎样的程度，所以项目经理要引导客户讲出；
第三是，要及时让客户了解项目进展状况和遇到的问题，让对方在一定程度上了解项目的现实情况， 这样可以增进双方的相互理解，有利于项目工作开展；
第四是，要客户及时参与到项目的测试中来，通过让客户尽早介入体验项目成果，减少项目后期的修改运维工作量。
第五是， 提前做好沟通计划， 避免因为不能配合客户的时间，约不到客户，而导致项目推迟，无谓的增加项目等待时间。
2、与部门领导的沟通
  不同的单位项目组的组织机构矩阵不同， 但都需要与自己部门领导或相关之职能部门的领导进行沟通。我认为与部门领导的沟通时需要注意几点：
第一，当遇到问题需要部门领导给予支持时，要能够简明扼要的说明问题，明确需要领导哪方面的支持。
第二，问题应该怎样解决自己要先有思路，明确方案1、2、3，说明项目组倾向于选择哪个方案，原因是什么，然后再由领导作决策，而不是把问题直接扔给领导；
第三，不要一味的向领导妥协。有些问题一味的承诺不切实际的去做，会严重影响项目工作，所以应依据实际情况，对领导讲明原因，使项目顺利开展，这既是对工作负责，也是对领导、对项目组负责。
3、项目组内部的沟通
  有些项目经理认为，项目组成员每天都在一起，就不需要特别的沟通，其实这是不正确的，就算是项目组内部也应该建立沟通机制，因为项目的开发是项目团队整体努力的结果，如果项目组成员不能及时了解到其他的功能开发、变更情况，
而导致相关功能开发的信息不对称而影响了整体的开发。二是使用正确有效的沟通方法。沟通方式可以分为书面沟通和口头沟通， 也可以分为正式和非正式。项目经理应该依据项目的实际情况和场景来选择不同的沟通方式。
书面的沟通大多是用来进行通知、确认和要求等活动，包括邮件、周报、正式函件、文书等。书面沟通时语言文字可以多次修改完善、内容准确可信、信息准确性高，但往往不够直接，在一定程度上可能会影响到信息传递的意义。口头沟通一般包括会议、面对面交谈、电话、讨论等。
这个方式比较直接，简单有效，比较容易被大多数人接受，但它无法像书面沟通一样留下"字据"，所以不适宜用类似确认这样的沟通。如何有效地利用这些方式使得能够清晰有效的沟通得到预期的目的：一是可以通过制定有效的沟通制度和沟通机制，如定期召开制定工作规划、制订沟通计划、项目周报等方式来保证信息的有效沟通，遏制人的惰性；
二是应采用多种沟通方式并用的方式，来保证沟通的信息确保传达到位；三是利用一些工具来协助加强沟通，比如通过邮件、网络、相关管理工具等等。
三是良好的冲突管理策略。项目中难免会有冲突发生，冲突解决得好不好，对于项目成功影响非常大。有人说项目是怎么做出来的，是可以用来存储空间多比例尺数据、专题属性数据、系统数据等。
在服务器端，地理数据和GIS 功能服务都被设计成"地理信息资源"，有相应的URI 和允许的HTTP 操作（即RESTful API），例如执行DELETE http://mysite/layer/2/feature/36 请求， 即可删除Layer 2 中ID 为36 的要素。
4、REST 风格的地理信息Web 服务实例
  通过对体系结构和关键技术的分析与设计， 基于IIS 服务器，Visual Studio 2008 开发平台， 以及WCF REST Starter KitPreview 2、OpenLayers、SharpMap、SQL Server 等软件或组件， 实现了一个REST 风格的地理要素（Feature）Web 服务及其客户端。
4.1 RESTful 地理要素服务实现
  首先， 在后台SQL Server 数据库中新建了一个用于存储图层要素数据的表Scribble，其字段包括Id、The_geom、Type、Title、strokeColor、Author、MinX、MinY、MaxX 和MaxY 等，其中The_geom 字段存储要素的坐标数据，
采用Well-Known Binary（WKB）的方式。然后，在VS.NET 平台下利用WCF、ADO.NET 实体数据模型等框架进行了服务的逻辑代码实现， 服务采用IIS 作为宿主。
1）HTTP GET <baseURI >/scribbles?f ={format}&maxfeatures={num}&bbox ={bbox}& where ={exps}&location ={loc}&polygon ={coords}&text={text}， 用来查询Scribble 图层中的Scribble 要素，并返回相应形式的表现。
其中，format 代表返回格式，包括XML、JSON、GML、KML 和GeoRSS；maxfeatures 指定返回结果的最大数目；bbox 指定矩形框范围；where 指定属性查询表达式；location 指定一个坐标位置；polygon 指定一个多边形范围；text指定默认字段包含的文本；如果没有查询字符串，将返回图层内所有Scribble 要素。
2）HTTP GET <baseURI>/scribble/{id}.{format}，用来请求对应id 的Scribble 相应格式的表现，format 包括XML、GeoJSON、GML、KML、GeoRSS、HTML 和图片格式。例如，图2 和图3 分别是id 为13 这个Scribble 的GeoJSON 和HTML 格式的表现。
3）HTTP POST <baseURI >/scribbles. {xml/json}; body ={newXML/newJSON}，用来添加新的Scribble，并返回该feature 相应格式的表现和它的URL，body 中是要新建的Scribble 的表现数据，支持XML 和JSON 格式。
4）HTTP PUT <baseURI >/scribble/{id}. {xml/json}; body ={newXML/newJSON}， 用来更新对应id 的Scribble 数据，body 中就是期望的新状态表现数据，同样支持XML 和JSON 格式。
5）HTTP DELETE <baseURI>/scribble/{id}，用来删除对应的Scribble。
4.2 客户端实现举例
  利用HTML、JavaScript 脚本和OpenLayers 开源组件实现了一个Ajax 创建和上传要素客户端，界面。首先，可以查询不同格式的所有Scribble 数据集合； 其次， 在图上画出点、线或面并设置相应属性后会生成该要素的JSON 字符串，
然后点击上传便可添加新的要素到服务器； 并且可以连续画出多个要素后一起上传。
5、结语
  REST 架构风格的地理信息Web 服务优势明显， 是否将替代传统的RPC 式的架构现在还不得而知， 但是由于其简单易用， 能够达到Web 级的规模可伸缩性， 而且容易进行互操作、Mashup，服务的开发者们现在更倾向于开发这种服务。
目前，网络中REST 风格的Web 服务越来越多，据著名的Web 2. 0 网站programmableweb. com 统计，目前可用的REST APIs 占67%，而SOAP APIs 占20%[7]。ESRI、Yahoo 等公司都已经或开始采用了REST 风格的Web 服务。
本研究所实现的REST 风格的地理信息Web 服务非常有限，目的是为了探索REST 服务在GIS 领域的应用，结合微软最新的开发框架进行实现， 希望在后续的研究工作中能进一步扩展。