作者：贾毓

摘要：EAM

EAM（Enterprise Assets Management）－－企业资产和设备维护管理，是一种先进的管理思想。EAM的前身则是CMMS（Computerized Maintenance Management System，计算机化的设备维护管理系统），只是在管理的广度和深度上更进了一步，在IT的应用上更加先进。它要求企业把资产和设备进行全面的管理，从资产属性到使用属性、从采购、使用到维护，进行统一的标准的跟踪控制。以提高资产和设备的使用寿命及使用效率，降低企业的管理和维护成本，保障企业的经营能够正常顺利地进行。

项目团队之间的相互交流在软件项目开发/实施过程中是十分重要和必要的，没有及时地和完全的沟通，项目组中的成员就不知道其他的成员在做什么，他们就不能互相帮助他们也不可能知道工作的进展情况。没有完全的和坦诚的交流，没有任何一个小组可以作为一个整体工作，这就是说这个小组配合不默契。

下面我就在大型软件项目实施过程中如何进行沟通谈谈自己的一点看法。

沟通管理的三个要素是透明性、聆听和协商。

透明性

透明性是小组的一种风格，每件事情都需要开诚布公和坦率吗？是否有隐藏的议程和任务，出色的小组知道将要发生什么事情，他们可以预见问题，并迅速进行调整，他们知道什么时候谁需要帮助。在配合默契的小组中，所有的成员都经常保持联系，每个人都知道工作的进展和将要做的事情。

在一个小型小组中，相互的交流通常是非正式的、简单的交流，当小组有6~8个成员或者有的成员与小组的工作地点不同时，小组就容易失去工作的一致性。所以没有坦率的交流，人们就会变得多疑、沮丧，进而失去对工作的热情和活力。

软件的开发/实施小组需要经常聚在一起讨论问题、解决问题、制定工作计划。事实上，工作效率高的小组通常是每周聚会一次，相互交流一下一周以来的工作进展情况。尽管经常性的聚会要花费很多时间，而且看起来不是那么有必要的，但是这正是一个项目小组配合默契所必需的。

聆听

往往在完成一个项目中，困难的不是项目中有什么跨越不了的技术难点，而是项目干系人之间的交流，我们在和客户沟通的时候我们可能还能耐心听客户讲述他的需求，这一点我们基本上都能做得到，但是当我们项目组内部进行沟通时，大家往往急于把自己的观点表达出来而增大声音的分贝，这样的最终结果很可能就是争吵不休，严重的可能还会出现项目组成员之间进行人身攻击的现象，这是千万要不得的。这时候我们需要什么？我们需要的是聆听，我曾经在一本关于沟通技巧的书中看到这样一句话，“优秀的沟通者应该是非常善于聆听的人，因为他明白只有学会聆听别人，当他阐述观点的时候，别人才会真正聆听他的发言”，的确，这句话明白地告诉我们一个道理，解决问题通常是从良好的聆听开始的。

全身心投入的聆听对于一个软件开发/实施小组是非常重要的，也是十分必要的。为了真正理解一个复杂的问题，完全理解讲演者所讲的内容是很必要的。尽管通过聆听来完全理解一个复杂的问题是很困难的，但是如果我们不去认真聆听的话，那问题只能还是问题，永远也解决不掉。

尽管全身心地聆听所花费的时间可能比想象的要长，但从长远的角度来讲，这是十分有效的。“曲解”是软件开发/实施过程中产生问题的主要原因，所以在软件项目中，聆听是绝对必要和有效的。

协商

对于在项目中出现的问题我们如何去解决？我们彼此明白对方需要什么，但是双方可能在某些问题上有分歧，怎么办？这时候就需要通过协商来解决。有些人比别人更会协商，并不仅仅是他们运气好，也不是他们有经验或接受过训练，好的谈判专家学会了运用有效协商战略。

有原则协商十分有效的主要原因是它可以使矛盾的双方得到调和。当矛盾使双方不能达到一致时，一方的胜利就意味着另一方的失败，解决这一困境的唯一手段就是发掘矛盾双方所共同感兴趣的东西，也就是所谓的共性。有原则的协商就是以共性为中心，把双方的矛盾逐渐向共性上靠拢，只有当分歧逐渐消失时，双发才可能得到一个比较满意地解决方案，也就是所谓的“双赢”。

项目的沟通管理的目标是及时而适当的创建、收集、发送、存储和处理项目的信息。项目的沟通管理过程包括：
• 沟通计划编制，决定谁需要什么信息，什么时候需要以及如何把信息发送给他们。
• 信息发送，包括及时向个项目干系人提供所需信息。
• 绩效报告，包括收集并发布有关项目绩效的信息如状态报告，进展报告等
• 管理收尾，包括生成、收集和发布信息来使阶段或项目的完成正规化。
在这四点当中，最关键的阶段的应该是沟通计划的编制，在这一阶段我们必须清楚什么人需要什么样的信息，如果连你想与人交流什么都不清楚又谈何沟通？高层的经理也许只有几分钟，他可不希望你在那喋喋不休，为此对他们也许几张图表把当前项目进展等情况表述出来是最重要的，而项目经理、职能经理、项目小组长、项目成员以及财务部门各自想要的都不同，你这时该做的就是向我们在机械制图学中学习到的一样，在不同的视角下向他们提供不同的视图。

下面就沟通管理的四个方面分别举例来说明：

沟通计划的编制

  　在项目立项后，第一步就要制定《沟通计划》，《沟通计划》应包括以下内容：
　 文件保存方式：在沟通计划中首先明确信息保存方式、信息读写的权限，明确用户信件、会议记录、工作报告、项目文档（需求、设计、编码、发布程序等）、辅助文档等的存放位置，及相应的读写权力。这样用于收集和保存不同类型的信息，有必要制定和遵循一个规定好了的统一规章制度，将与项目有关的重要工作建档。在XX港口的EAM项目实施中，我们用一台普通的PC机作为我们的文档服务器，由文档管理员负责维护，按照不同的文档类型分类存放，日常工作中的工作日报、周计划、会议纪要、需求报告等等。普通的用户只能访问共享的只读权限的文件夹，文档管理员可以以读/写权限访问所有的文件夹，日常的工作文档等通过安装的内部电子邮件系统发送给文档管理员，由文档管理员分类归档，从而保证了实施工作的顺利进行和文档资料的一致性和安全性。
　 联系方式：应该有一个专用于项目管理中所有的相关的人员的联系方式的小册子，其中如项目组成员、项目组上级领导、行政部人员、技术支持人员、出差定房订票等系统中相关的人员，座机、手机、职能等等，应相应的一一列上，做到简洁又要明了，最好能有特殊人员的一些细小的标注，能够做到在一打开小册子的同时就能将所有的相关人员的资料了然于胸，正所谓知已知彼，这样一来，很多在平时大费周章的事，就能在养成的良好的习惯中，轻松做到。
　 工作汇报方式：明确表达项目组成员对项目经理或项目经理对上级和相关人员的工作汇报方式，明确什么时间，什么形式。例如在XX港口EAM系统实施中，项目组成员对项目经理通过内部电子邮件系统发送工作日报和周计划；项目经理每周五召开周例会，对项目进展情况向项目组成员和客户方经理进行通报，让所有参加项目的成员时刻明白我们的当前的工作进展情况和下一步该做什么；紧急汇报通过电话及时沟通；每月项目经理对项目状况向客户方领导进行大约10分钟的汇报等等。
　 统一项目文件格式：对于一个项目本身统一的文件模板，是正规管理的一部分，所以必须统一各种文件模板，并提供编写指南。
　 《沟通计划》维护人：明确本计划在发行变化时，由谁进行修订，并对相关人员发送。
　　由于《沟通计划》是同很多人员有相关的，必须保证计划是有相关干系人参于制订，并且保证《沟通计划》是相关人员已经正解接收及理解。计划是用来执行的，而不是为计划而计划束之高阁。

信息发送

　　对于项目管理的信息正确传达到相应的人员，是相当重要并有一定的困难的，经常发生的事情是信息发送人感到自己把信息正确传达了，但实际的结果却是信息没有传达到或是被错误的理解了。太多的人还是不太习惯成堆的文件或者通篇的E-MAIL传送的邮件，如果能利用非正式的方式或者是双方会谈的方式来听取重要的信息，就来得又快又准确更能让人接受，就象传统里的一纸书信在某些场合还是比任一现代化的联系方式来得好一样，价值取向不同，沟通的方式也就在使用效果上全然不一样了。　　　　　　　　　　　　
　　我们在沟通中应遵循彼得.德鲁克提出的四个基本法则：
　 沟通是一种感知
　 沟通是一种期望
　 沟通产生要求
　 信息不是沟通
　　本人在通过学习及结合实践的过程中得到以下的感受。
1）沟通是一种感知
　　沟通一定是双向，必须保证信息被接收者接到了。所有的沟通方式，必须有回馈机制，保证接收者接收到。比如：电子邮件进行沟通，无论是接收者简单回复“已收到、OK”等，还是电话回答收到，但必须保证接收者收到信息，并回应信息已经接收到。
　　信息收到必须保证理解是正确的，很多事情信息收到了，但被错误的理解了，很多信息是传达到了，但却被错误理解了。
　　比如：A项目经理对B项目经理说“今天我要去投标，不过我这边的现在人手少，你那边可否抽些人过来帮我壮壮声势”。
　　B项目经理手中有一些程序员和系统分析员，而当前程序员有些空闲人手，系统分析员今天正好有些紧急工作，但B项目经理错误理解为A项目经理需要的人是系统分析员，到时协助答辩，所以回答“不行，今天正好有紧急工作，没有办法帮忙”。
　　A项目经理只好另想办法。
　　以上就是典型的理解错误，发送方的正确表达、接收者的正确理解是非常重要的。比较简单的方式是发送者进行信息发送，接收者进行理解后进行细化并进行二次表达，但这种表达却是在确认自己理解了的同时去转叙或者执行的结果，而不是复述。
2）沟通是一种期望
　　在项目管理中，项目不同干系人是有不同的沟通需要的。
　　项目组成员在具体的工作安排中他想明白那个职位是否符合他的意愿等等，上级要了解接收者的期望，向下属传达工作安排的同时还要了解他的意愿取向的问题，再采取相应的方法，调起其在工作上的热情，从而促使其在工作的高效付出，在项目管理中如让下属有反抗情绪的产生或者低效的工作，则是一个项目经理在沟通上不得法的一个失败实例。因此制定一个协调的沟通计划就更为重要了。
　　而项目经理的上级和客户更加关心是进度的问题：时间是否会延期、是否要添加成本、质量是否有保障等等。这对于项目经理来说，就应即时的反馈这些时间，特别是将会有延期、将添加项目成本、质量将会有问题的苗头等等，更加必须提早汇报，使项目经理的上级和客户能及时并适时调整工作计划。
3）沟通产生要求
　　沟通是双向的，沟通必须能够符合接收者的利益，那样才有说服力。这就要求双方都要有良好的沟通方式，特别是良好的沟通又能达到双赢的目的，一致的沟通有助于组织促进项目更新。
　　口头的沟通能力同时似乎又是职位提升的关键因素。于是，沟通又必然的产生要求，比如：职位上成功，项目的早日完成，对问题作出恰当的回应，小到假期薪金等等都要沟通来达到目的。
4）信息不是沟通
　　当前是信息时代，必须分清哪些是沟通哪些是信息，对于用于沟通的信息必须明确简练、醒目，避免沉没于信息之海中。
　　信息也可用于沟通，但信息过于的生搬硬套，一个文字性的文件是并不能起到沟通的作用的，在项目中，项目经理并不是想集中于信息中而是想了解项目里工作的人员，并与之建立起相互信任的关系。而有效的发送信息，只能是依赖于项目经理和项目组成员的良好的沟通技能。
　　我们现在就能通过上面的四个法则来进行有效的沟通，达到保证管理中信息有效传达的目的了。

绩效报告

实施情况报告一般有三种形式：定期报告，阶段审查，紧急报告。
　 定期报告：就是在某一特定的时间内将所完成的工作量向上级汇报。在实际的项目管理中项目人员对项目经理按周报告，对于客户和项目经理的直接上级是按阶段或月进行统一的进展报告，从项目管理上讲，项目定期报告的主要内容就包括：当前是什么状态？在什么阶段？进度完成情况？当前有什么问题请上级（用户）协助解决？下周（下阶段或下月）的计划是什么等等。
　 阶段评审：在项目进行到重要的阶段或里程碑似的项目发展阶段，就要进行阶段评审。阶段评审的意义就在于评审当前的项目情况，迫使人们对其工作负责；阶段评审可以提前发现问题，提前将问题解决在初期阶段。不过阶段评审也是最容易产生争执的地方，这主要是针对于问题严重性的定级，项目经理或项目管理委员会必须在全面了解项目发展进展的情况下及时找到问题的重点，从而就事论事的解决问题的真正症结所在，并进行后面的项目。
　 紧急报告：在出现意外情况下，进行紧急报告。紧急报告包括以下内容：当前发现的问题，相关影响，需如何解决（动用什么资源），问题紧迫性（必须什么时间内进行反馈）。
在实际的项目管理过程中，质量管理的质量保证部门也将进行质量审计，按阶段提交质量审计报告。
  项目干系人接到实施情况报告后也应即时的进行反馈，明确报告已经成功接收到。并让项目干系人一道解决执行中的问题。

项目的管理收尾

1) 项目客户验收
　　项目收尾期间客户将根据合同对项目进行验收，一般是对最终成果《软件系统》，项目文档《操作手册》、《安装手册》、《软件光盘》、《维护计划》或《维护手册》进行验收，双方将产生双方《项目开发／实施总结报告》及《项目总结会议备忘录》不同的人都有不同的见解，这些报告都是极好的资源，对未来项目的平稳运行有很大的帮助。
2) 过程文件归档
　　项目组内部将对项目过程中的计划、需求、设计、源代码、变更、会议纪要、客户信件等文档整理归档，为以后的查询及参考作为一定的依据。项目档案常常在结束多年以后还有用，良好的项目档案能为当前的项目节省时间和金钱，有时还能对组织进行审计等快速提供有价值的信息。
3) 项目总结
　　很多项目没有能进行很好的总结，推脱的理由有项目总结时项目人员已经不足/不全、现在有新的项目要接没有时间、写了没人看等等。这些理由全不是正确的，无论如何也要进行总结，只能总结当前，才能提高以后。
　　项目的成员应当在项目完成后，为取得的经验和教训写一《项目总结报告》，总结在本项目中哪些方法和事情使项目进行的更好、哪些为项目制造了麻烦、以后应在项目中避免什么情况、那些事情应在后面的项目中坚持等等。为以后的项目人员更好的工作提供一个极好的资源和依据。

结束语

项目管理涉及的范围还很多，本篇只就项目的沟通提出了一些看法。要想做好项目管理工作也不是一朝一夕的事情，它需要多个部门的配合，公司整体资源的优化。在项目管理领域还有许多问题值得去探讨，请多给出批评指正的意见。

参考文献：
1、 罗伯特·K·威索基．有效的项目管理．李盛萍 常春．电子工业出版社，2002年8月
2、 詹姆斯.P.刘易斯．项目经理案头手册．王增东 任志忠 胡永庆．机械工业出版，

　　200１年1１月

3、 刘积仁 康晓东 饶友玲．软件开发项目管理．人民邮电出版社，2002年2月

    /**
   * 对经过escape函数加密的url中的字符串进行解密
   * @return 解密后的正常字符串
   * @param src
   * 参数说明 例如：%u5339%u914D%u8BBE%u5907或者\u5339\u914D\u8BBE\u5907
   */
    public static String unescape(String src) {
         StringBuffer tmp = new StringBuffer();
         tmp.ensureCapacity(src.length());
         int lastPos = 0, pos = 0;
         char ch;
         while (lastPos < src.length()) {
            pos = src.indexOf("%", lastPos);
            if (pos == lastPos) {
               if (src.charAt(pos + 1) == ‘u’) {
                  ch = (char) Integer.parseInt(src.substring(pos + 2, pos + 6), 16);
                  tmp.append(ch);
                  lastPos = pos + 6;
               }
               else {
                  ch = (char) Integer.parseInt(src.substring(pos + 1, pos + 3), 16);
                  tmp.append(ch);
                  lastPos = pos + 3;
               }
            }
            else {
               if (pos == -1) {
                  tmp.append(src.substring(lastPos));
                  lastPos = src.length();
               }
               else {
                  tmp.append(src.substring(lastPos, pos));
                  lastPos = pos;
               }
            }
         }
         return tmp.toString();
      }

大家一起共享！

网上段子1：在追查三鹿事件责任人时，三鹿说是奶农责任，奶农说是奶牛责任，奶牛支吾了半天，说出了一个字：草。草很委屈，含泪道：怪也怪我妈生了我，终于揪出幕后凶手——草他妈。草他妈极其冤枉地大声哭道：怪也得怪我妈生了我，最终挖出真正罪魁祸首:草他奶奶。

网上段子2：蚊子饿极，见一小姐双乳高挺，遂一头扎入猛咬，发现嘴里全是硅胶，于是仰天长叹：“唉！食品安全太成问题了，上哪能吃到放心奶啊……”

虽然看着是笑话，或许看完后我们是笑笑罢了，但是这笑话创作者背后的无奈和对这个社会的讽刺溢于言表，可能比直接攻击某些不作为的机构来的更能让人记忆犹新滴！古人尚且知道民以食为天，但是目前的食品安装状况如此，你让老百姓做何感想？

我最后也想问一句：什么时候老百姓能够真正和谐生活在社会主义的祖国？？？深思中。。。。。