项目管理中做好沟通的方法

1、项目沟通方法
1)正式沟通与非正式沟通
(1)正式沟通是通过项目组织明文规定的渠道进行信息传递和交流的方式。它的优点是沟通效果好，有较强的约束力。缺点是沟通速度慢。
(2)非正式沟通指在正式沟通渠道之外进行的信息传递和交流。这种沟通的优点是沟通方便，沟通速度快，且能提供一些正式沟通中难以获得的信息，缺点是容易失真。
2)上行沟通、下行沟通和平行沟通
(1)上行沟通。上行沟通是指下级的意见向上级反映，即自下而上的沟通。
(2)下行沟通。下行沟通是指领导者对员工进行的自上而下的信息沟通。
(3)平行沟通。平行沟通是指组织中各平行部门之间的信息交流。在项目实施过程中，经常可以看到各部门之间发生矛盾和冲突，除其他因素外，部门之间互不通气是重要原因之一。保证平行部门之间沟通渠道畅通，是减少部门之间冲突的一项重要措施。
3)单向沟通与双向沟通
(1)单向沟通。单向沟通是指发送者和接受者两者之间的地位不变(单向传递)，一方只发送信息，另一方只接受信息方式。这种方式信息传递速度快，但准确性较差，有时还容易使接受者产生抗拒心理。
(2) 双向沟通。双向沟通中，发送者和接受者两者之间的位置不断交换，且发送者是以协商和讨论的姿态面对接受者，信息发出以后还需及时听取反馈意见，必要时双方可进行多次重复商谈，直到双方共同明确和满意为止，如交谈、协商等。其优点是沟通信息准确性较高，接受者有反馈意见的机会，产生平等感和参与感，增加自信心和责任心，有助于建立双方的感情。
4)书面沟通和口头沟通
5)言语沟通和体语沟通
2．提高与改善项目沟通管理的方法
沟通的有效性，主要看发送者转交接受者态度的状态及其程度。人际沟通是否成功，取决于领导者(发信者)所要向下级人员提供的信息与下级人员通过理解而获得的意义是否相一致。为了增加沟通成功的可能性，必须保证领导者(发信者)提供的信息(下达的指令)与下级人员(接受者)对信息(指令)理解的最大限度的吻合性。
1)改善有效沟通的方法
(1) 重视双向沟通，双向沟通伴随反馈过程，使发送者可以及时了解到信息在实际中如何被理解，使受讯者能表达接受时的困难，从而得到帮助和解决。
(2)多种沟通渠道的利用，一个项目组织，往往是综合运用多种方式进行沟通，只有这样，才能提高沟通的整体效应。
(3)正确运用文字语言。
2) 提高有效沟通的方法
(1)沟通前先澄清概念，经理人员事先要系统的思考、分析和明确沟通信息，并将接受者及可能受到该项沟通之影响者予以考虑。
(2)只沟通必要的信息。
(3)明确沟通的目的，经理人员必须弄清楚，作这个沟通的真正目的是什么?要下级人员理解什么?明确了沟通的目标，则沟通内容就容易规划了。
(4)考虑沟通时的一切环境情况，包括沟通的背景、社会环境、人的环境以及过去沟通的情况等，以便沟通的信息得以配合环境情况。
(5)计划沟通内容时应尽可能取得他人的意见。
(6)要使用精确的表达，要把经理人员的想法用语言和非语言精确地表达出来，而且要使接收者从沟通的语言或非语言中得出所期望的理解。
(7)要进行信息的追踪和反馈，信息沟通后必须同时设法取得反馈，以弄清下属是否真正了解，是否愿意遵循，是否采取了相应的行动等。
(8)要言行一致的沟通。
(9)沟通时不仅要着眼于现在，还应该着眼于未来。
(10)应该成为一个“好听众”。成为一个“好听众”，才能明确对方说写什么。



事前多沟通 时候不尴尬
案例
　　Wadcom是一家跨国电信设备公司，在中国设有分支机构。公司在中国的组织结构如图1所示。
　　2000年7月，Wadcom公司与中国的运营商A公司签订了全国29个城市的IP电话设备供货合同，合同总值超过1.5亿元人民币，计划一年完成。
　　为此，Wadcom公司成立了专门的项目团队，由销售工程经理Harrison担任项目经理。项目团队的其他成员如表一所示。项目的干系人还包括A公司在国内29个城市负责确保现场安装环境的工程师，以及A公司聘请的负责系统测试的工程师。
　　7月20日，Wadcom公司中国区总裁Peter召开了第一次项目大会，开发团队中的Grant和Art以及生产项目经理Nick 和订单管理经理Jerry通过电话参加会议。会上宣布了项目团队的组建事宜。
　　随后的一周，Harrison和助手Jane一起完成了项目说明书和项目计划的起草，并提请相关人员确认。之后，项目正式启动。
　　项目初期进展得很顺利。很快，Harrison和Jane就制定出了项目时间计划、资源管理计划和风险管理计划等。
　　此时，位于美国总部的开发团队项目经理Art提出，希望销售工程师能够提供更多的用户需求细节以便提高开发效率和准确性。为此，Harrison制定了为期一个半月的每周开发例会，要求Art和售前工程师Bing以及相关人员参加。
　　紧接着，订单管理经理Jerry告诉Harrison，由于事先没有沟通，出于“零库存”的考虑，公司没有过多备件，需要延长交货时间。Harrison与生产项目经理Nick讨论后得知，交货时间可能比预期要晚两个月。显然，这是无法接受的。因此，Harrison将此问题提交给Peter。Peter要求Harrison制定了为期两个月的每周两次的订单状态报告和协调会议，并要求相关的高层经理参加，尽量缩短交货时间。
　　在即将交货的前两周，在一次和A公司的研讨会上，Harrison突然得知A公司项目中有些辅助的备件现场没有，这将影响施工进度。无奈之下，Harrison 要求系统安装和支持队伍在两周内到现场做实地勘察，并将所需的材料和备件统一上报。由于工期紧迫，这些辅助备件不得不在国内单独采购。因而，Harrison需要组织采购工作会议，并设置采购的工作程序。
　　此外，由于A公司各省局的相对独立性，项目的培训和准备工作比预期更为复杂。虽然合同中规定了较详细的内容，但Harrison还是不得不参与本应属于A公司的一些具体工作。
　　最后，所有货物运到安装现场比预期晚了近一个月。在此期间，项目相关的培训工作也结束了，项目进入现场安装阶段。
　　Harrison本以为项目前期那些繁杂的会议可以减少了，然而很快他就发现新的问题接踵而来。由于恰逢国内春节时期，A公司各省局全部封网，项目不能按计划进行。Harrison需要重新计划各地的实施日期，这给原本紧张的工期又增加了压力。另外，由于工期的延误，负责施工的技术人员已开始忙其它工程，Harrison还得重新与负责技术支持的经理磋商安排。
　　经过近3个月的安装和调试，系统开始试运行。按照合同规定，尾款要等到验收合格才能支付，双方都组织了各自的测试队伍。3个月后，系统通过测试，项目在2001年9月底结束。
　　在一些大型项目中，通常涉及的项目人员众多，并且会有多个职能部门参与。如何将这些职能人员组成一个有效的项目团队，是项目成功的关键因素之一。
　　管理需要沟通
　　管理学指出，通常，管理者要用70%的时间用于与人沟通。而对于项目经理来说，需要花费90%或更多的时间来进行沟通。
　　就像上文的案例中，Harrison不但要与公司内部的销售、开发、生产、安装、培训等多个部门打交道，还需要与公司外部的客户打交道。因而，沟通就不是一件容易的事情。
　　在上面的案例中，由于项目经理在沟通管理方面做得不够，“麻烦”接踵而至。先是库存不足需要延长交货时间，然后又出现安装现场缺乏辅助备件等问题。原本项目经理制定好了项目计划，安排好了项目进度，却总是被一些“突发事件”搞得措手不及，最终还影响了项目进度。
　　沟通管理的六要素
　　那么，如何在项目中进行行之有效的沟通管理呢？一般说来，要从以下六个方面来考虑。
　　首先，项目经理应该将沟通本身加以计划，也就是要有具体的沟通计划。虽然在各类项目管理教材中有许多关于沟通管理的论述，但是真正的IT项目环境中，大多没有具体的沟通管理计划，一般都只是简单罗列了项目的干系人。沟通计划的制定至少要包括以下几个方面：
　　1、项目干系人的列表。最好以团队为基础建立干系人列表。
　　2、确定以团队为基础的项目干系人的信息需求和沟通需求，即何人何时需要何种信息。一般来讲，由于大的项目沟通渠道实在太多，以团队为基础能够大大减少这种渠道。
　　3、信息分发的渠道和方式。对于重要的项目一定要有定期的项目绩效报告和问题状态报告。
　　4、项目定期会议，最好是每周例会。这样，项目干系人知道有了问题在何时能够得到讨论和解决，并可避免突发组织会议找不到人的局面。
　　5、特殊问题的沟通对策。
　　其次，项目经理要尽量利用好干系人的首次会议，将项目的内容做较为详细的交待，并提请所有干系人对项目可能出现的问题提出建议。
　　在本案例中，需求不清和备件不足的问题如果很快被识别，就不会出现临时组织会议的复杂局面。因此，除了项目成立大会外，项目经理最好再召开一到两次全体项目干系人大会（或以团队为基础的会议）。也就是说，在解释了项目的背景并分发相关的信息以后，留给项目干系人一到两周时间仔细考虑可能面对的问题，并及早识别加以解决。这与风险识别并不完全一样。有时候，识别的可能是风险，有的时候可能根本就是一种实际情况，如案例中公司备件不足的问题。
　　第三，项目经理要严格控制会议的次数和内容，全面管理自己的时间分配。在上文的案例中，Harrison组织了很多的例会，与不同的项目团队交流。此时，项目经理要明确自己的职责，要努力将会议的时间限制在一定范围。并且，会议最好要形成具体可行的活动内容，并指派具体的实施人员。
　　第四，项目经理要理解沟通的不同层次，同时要利用这些层次为自己的项目服务。即使项目经理本身就是一个高级管理人员，他通常也无法解决所有的问题。因此，项目经理需要定期与高层管理人员进行交流，需要高层解决的问题一定要及时上报。
　　第五，沟通的目的一定要非常明确，项目经理要对沟通的内容进行管理，要注意防止跑题。跑题的情况通常在项目的后期中容易出现，随着项目人员的熟悉，很多与项目无关的话题都有可能占用项目会议的时间，并且通常还不易察觉。因此无论是项目会议还是相关文件，都要明确所要讨论的内容。
　　第六，沟通不仅局限在公司内部，同时也要同外部，尤其是客户进行交流。特别是对项目重要的里程碑，需要征得客户的支持。这包括客户的准备活动（最好有一份准备文档）、施工的时间、客户的工作日历等等。
　　事实上，沟通管理是一门复杂的管理科学，需要项目经理在实践中加以总结。项目管理中的沟通与日常管理中沟通的不同之处在于，项目经理要在最短的时间内，达到满足项目需求的沟通效果。









在项目管理中面对面交流最重要
通过虚拟的方式同人打交道虽然方便，却也有它的不足之处。
现在的我们生活在一个虚拟交流的世界当中。由于虚拟的工作小组在某些方面具有与生俱来的优势，所以它得到了公司领导人的大力欢迎。商业学校的老师们总是竭尽所能的让那些充满了理想和抱负的管理人员了解虚拟交流的好处。但人类几千年来所形成的交流方式和交流智慧不是轻易就可以被磨灭的。在很多时候，直接的人际互动在人际交流当中所起到的都是极为积极的作用。
作为一名咨询顾问，我在工作当中学到了很多的东西，而其中的大多数经验都是从失败的教训中积累的，上面所提到的这一点就是其中之一。我曾经在一家国际性的公司中担任咨询项目经理。公司让我为其它的小组的工作提供帮助。在以往的工作当中，在这方面我是有着相当成功的经验的。尽管我为获得了公司的信任而深感高兴，但内心深处还是有一丝忧虑，我觉得公司对我的期望似乎有些太高了，因为虽然当时的我已经是一名高级咨询顾问了，但毕竟我在公司当中所扮演的角色只是一名初级项目经理而已。
在接受了新的工作任务的头一个星期里，我同自己要协同负责的八个项目的项目经理进行了联系。刚开始的时候，他们并不怎么愿意接受我的帮助。为了让他们相信我的到来决无恶意，我花了好几个星期的时间来慢慢的说服他们，让他们接受我。刚开始的四个月，工作进行的还算平稳顺利，没有遇到什么问题。但是，没过多久，非常出乎我的意料之外，我手下的一个比较大型的项目就出了问题。
灾难剖析
根据我当时的工作记录，我手下一个项目经理的上级负责人在项目设计阶段总结会后接到了取消项目的通知。而在此之前，我们为了准备这次会议已经花费了一个月的时间。特别是在会议前的最后一个星期，我们每天晚上都要熬夜工作，为的就是把会议做好。
突如其来的通知让我们不知该如何是好。我打通了项目经理的移动电话。他接了电话，用微弱的声音告诉我现在没有办法同我谈这件事情。我只能挂断了电话，等着下周能够在公司总部遇到他时再了解事情的答案。
在接下来的五天的时间里，每天我都要面对我的上级和公司多位副总裁的询问，他们希望能够尽快了解原因，找到答案。我只能告诉他们再耐心等待几天的时间。在他们等待的过程当中，我想尽了办法去自己寻找问题的答案，联系了很多同项目小组成员有社交联系的人，从他们那里收集信息。
最后，终于在正式的工作报告当中，我了解到了问题的真实情况。原来，在准备方案的过程当中，项目的“高级”建筑师（刚从初级建筑师升职上来的）遇到了困难。就在他不断尝试不断摸索的过程当中，他遭到了项目小组内一名资格比较老但技术上也只能算作初级的工程师的攻击和取笑。在项目经理还没来得及解决这个问题之前，其它的一些工程师也都加入到了声讨他的队伍当中。由此一来，原本的会议就被搞糟了，客户方的CIO自然就确信我们的项目小组是完全不能胜任的。
联系的基础
从上面的经历当中，我们可以总结出很多的经验教训。根据在以往的工作当中积累的经验，我很快就把自己的注意力转移到了矛盾的解决上。我知道项目当中的四位工程师和一位初级建筑师在工作当中的声誉一向都非常好，问题同他们的职业素养肯定没有关系。他们之间肯定另有问题。
我用了很多时间，同项目经理一起分析小组成员之间的互动情况。尽管项目经理以前并没怎么太注意这个问题，但是他也还是注意到了小组内的气氛相当紧张。在经过了一番努力之后，我终于在他的帮助下了解到了问题的根源。事实上，是那个“高级”建筑师先疏远小组内的其它成员的。而刚刚在他升职之后接替了他的初级建筑师职位的那名资历比较老的工程师很讨厌他。其它的工程师也都站在了比较有人格魅力的老工程师的一边。当年轻的高级工程师在工作中卡壳了的时候，老工程师的愤怒让他无法再顾及自己的职业素养，对年轻的工程师进行了攻击。同项目小组成员后来的接触证实了我们最初的分析和判断。
现在问题又变成了“我们为什么忽视了这个问题？”在以往的工作当中，我也曾经遇到过类似的情况。甚至还曾经发现并解决过这样的问题。项目经理承认他自己把太多的时间花在了办公室里，花在了对项目时间安排的计划上，而忽视了早就已经存在的严重问题。那么，我又能如何为自己托词呢？
我意识到错误出在我对待问题的基本方法上。我在给自己手下的项目经理提出意见和建议的时候并没有考虑他们的个人需求到底是怎样的。更重要的是，我留下了一个领导权的真空，再没有人出来填补它之前，它只是一片空白。
然而，要想控制住一个工作小组的领导权是需要一定的技巧的。至少要有以下两个方面的基础。

同项目小组当中的一个或多个成员存在着领导与被领导的关系。理想的状况是，你已经同小组中的某些成员建立起了领导与被领导的关系。这样一来，小组的其它成员在接受你的领导风格时就有了某种参照。但是，由于这个项目小组当中没有一个成员以往同我建立了这种关系，所以这一点对我来说就不适用了。
有能够代替你实行领导权的项目经理。这也是一种非常理想的状况，可以让你借助另外一名领导者的力量来实行自己的领导权。如果是由你自己亲自培训他的话，这种方式就更为有效了，因为这样一来他就有了和你同样的领导方式。而在上面的例子当中，我手下的这名项目经理把注意力放在了工作的管理上，而没有放在对小组成员的领导上。
应用规则来建立领导权的机遇。技术人员通常是用自己的智慧来树立自己的领导权，通过解答各种技术问题来证明自己的能力。在上面的这个例子当中，我故意没有参加到交流当中，为的就是让那名高级建筑师证明自己的能力。
至少要偶尔与小组成员见面的能力。人格魅力在人际交往的过程当中是非常有力的工具，但是要想充分的发挥其效力，还是需要通过人与人之间实际的接触。在上面的这个例子当中，我就没有做到这一点，从来没有同小组成员进行过接触。
证明自己对事件的兴趣和影响能力的机遇。要保证自己直接参与到重大项目事件的准备当中。在上面的例子中，我实际上还是以顾问的身份参与到了主要项目事件的准备当中的。
上面所谈到的这五点显然都是出自我自己所喜好的领导风格和领导方式。其它的领导者可能会有他们各自不同甚至有些激进的其它方式。正所谓仁者见仁智者见智。
在跌倒的地方重新站起来
在弄清了造成问题的原因之后，我和项目经理一起制定了一项行动计划。我们给那位高级工程师另外指定了新的工作任务。我们在公司总部召开了为期一周的小组会议。同时，我还让高级建筑师了解到，在以后的工作当中，我会更多的参与他的技术决策。这些措施的采取加强了我在项目小组当中的领导权，也让我能够更好的了解和掌握整个小组的工作状况。这样一来，我给项目经理提出的建议就更有针对性并且更为有力了，也得到了更为积极的反馈。

冲突也是沟通——“走出项目管理的泥沼”之“人员管理”话题之四

人员冲突是经常让经理们头痛的事情之一，而且无论解决得如何，总会有一些挫折感，自责没有将事态消灭在苗头阶段。事实上不必这样耿耿于怀，冲突与书信和会议一样，也是一种沟通方式，只是它的形式比较激烈，负面的影响也比较大，会造成一定程度的破坏性。认识到冲突的本质，就可以放松一下紧绷的神经了。既然如此，如何处理好冲突呢？冲突不仅仅只有破坏性，我们能从中学到什么呢？
我曾经担任经理的一个项目组，与其他部门的接口工作特别多。与其他部门的人员沟通，不再是经理一个人的事，而是每一个成员每天都要做的事情。冲突已经是见怪不怪的事情，主要事例分为三类。
一是部门内部长期合作共事的人员冲突，涉及方自己调解是上上策。
因为双方同在一个部门工作，日常接触最多，彼此比较了解，对产生矛盾的根源，和怎样一步一步上升为冲突的过程也心知肚明。如果能够捅破那层纸，直接坦诚布公地交流，以工作为重，仍然有希望继续做同事。而且，如果能够自己解决困境，也能够将破坏性减到最小，也不失为挽回局面的一种方式。否则，闹得不可开交，势必影响以后的长期合作，而且让上级经理头痛心烦，这个影响就太差了。经理们对待需要长期合作的人员之间的冲突，睁大眼睛，促使其尽量自行解决，达成共识即可，能不介入就不介入。
这样的冲突如果能够自行解决，双方无疑可以增进了解，也能够为对方着想，体谅和尊重对方，双方在待人接物和与人沟通、协作上的成熟是必然的。
二是在流程上有上下游关系的人员冲突，以流程改善为主。
这类冲突的原因多为下游对上游的工作质量不满，多次旁敲侧击、私下提醒均无效，就会一竿子捅到双方领导那里。冲突的根源主要在于上下游职责不明，所以会有双方的互相推诿、扯皮，甚至指责。双方领导务必在聆听各自陈述缘由的时候，去除由于感情色彩而引发的冲突细节，而关注“如何把事情做好”这个主题。在把流程理顺，职责分清楚之后，再加以调解个人情绪，应该是不错的结局了。
当然，有的问题也不是一次就能够准确找到好的流程，可以一了百了的。冲突事态发展出现了周期性，流程的改进也在不断的发展、完善，直至实践证明其流程确实很有效，就可以将这个流程固定，加以控制。如果经过了多次流程的改造、调停都不能使工作达到要求，那么是不是可以试一试换人了？
三是立场上就对立的部门的人员冲突，以经理个人的沟通、减压为主。
例如软件项目的开发部和测试部，由于职责不同，必然对立，但是这并不能推导出两个部门人员情绪上就是对立的。然而在项目的实际运作中，双方由于认识上的不一致，冲突不断发生。小的冲突是双方司空见惯的，一般争论过了就过了，下次照样讨论或者争论，并不影响工作进展，这说明双方都对自己的工作认真负责。因此有这方面经验的同行也都能够理解对方，达成默契，认同这种沟通方式。但是如果冲突发展到双方气得不愿意解释自己的观点，互相挑对方话语中的毛病，甚至干脆破罐破摔，这就会影响到工作进展，经理必须出面调停已经处于冷战或者热战状态的双方。
处理这样的冲突，有的部门领导一听到这样的消息，就把方方面面涉及到的人都请到一起，象谈判一样分列两厢，开始沟通。也许会有效果吧，可惜我没看到很有利的例证。通常，人越多，尤其领导越多，大家讲话越是小心，小心翼翼地思考每一句话，不要现出自己不讲道理，或者没有考虑对方利益，让领导们看轻了自己等等。这样遮遮掩掩，如何根除问题？最终当然也能够在领导的敦促下达成一定的“谅解”，但是根源不除，难免今后重燃战火。我倒是觉得如果得到消息的经理，能够分别私下了解一下每个当事人的心情和事态发展，也许更能够化解问题于无形。倾听，还是倾听，听当事人诉苦，让他说出自己如何被对方挑逗、刺激得火冒三丈。等他发泄完了，他自然会把话题转到工作上的，这时候，他已经能够自己分析出问题的来龙去脉了。一个巴掌拍不响，双方都会有些举动刺激了对方，经理可以站在旁观者的角度分析问题的焦点所在，对双方稍做善意地提醒。冲突也是沟通，了解对方的方式，经过这次冲突，双方对对方的性格特点也加深了了解，以后的相处应该能够选择对方比较容易接受的方式，工作还是会在比较平和的环境下进展。
双方的过于较真儿，也是工作压力大的表现，经理也要想办法缓解当事人的压力，如组织团队活动，或者添加人手、调整进度等等。冲突背后的事情还真不少呢。
这种调解方式，让双方在情绪上、自尊心上都能够很容易接受，效果还不错。比起大动干戈地处理方式，也可以算是“无招胜有招”了。
冲突不可怕，经理自己先不要被吓爬下，或者累爬下。我们每个人都会遇到冲突，理性地处理冲突，从冲突中学习，大家都在冲突中成长，日后的工作必然进展得更加顺利，更少发生冲突。
如何建立团队
团队，并不仅仅是一组人恰巧在一起工作就可以构成一个团队。团队应该如何定义，Smith给出如下的定义：能相互负责的、具有共同的目标的、共同的执行目标和共同方法的有互补技能的一些人。
在以下的软件项目中一定需要注意的团队合作：
1． 开发和审查项目需求
2． 开发将整个项目中使用的项目构架和设计指导方针。
3． 定义将在项目中应用的技术环境的各个方面(包括程序设计语言、编译程序、源代码库、代码生成程序、编辑程序和版本控制程序)。
4． 开发在整个项目的相关的代码标准
5． 协调一个项目的相关方面的工作(包括子系统、模块和类定义界面)。
6． 设计程序的困难部分。
7． 检验独立小组或开发者的程序设计和代码。
8． 调试程序中的困难部分。
9． 测试需求、设计和代码。
10． 审计项目的进展情况。
11． 软件维护。
这些部分如果整个小组合作来解决的话比一个或两个人解决更加完善，当小组的整体的合作起来比不合作起来好的情况下，团队才有必要生存。因为也不是所有的项目都需要团队的，相反有些情况，合作的效果并不如一个人。
建设什么样的团队？根据有关统计数字（美国资料）表明：
开发时间在6~14月的4~8人的团队最佳。
项目经理应以团队的合作为主要的目标，而不应看重某个人的能力。
要有共同的目标、可提升的意愿（主要是指技术上）。
团队成员的相互认同感、相互信任。
有自主意识并追求相同的结果。
需要高层次的享受（根本性的需求）。
有效的沟通和适当的授权意识。
具有以下性质的团队为最佳团队。
如下看一个事例再对最佳团队进行分析：
Error.cao 所在L公司是一个有7个人的团队，虽然大家的能力等相差很大，但从来相互合作，没有任何人受到歧视和不被尊重。大家在开小组会议时畅所欲言，对问题的披露没有任何阻力，大家会后也相互合作。
但有一个奇怪的问题，每次有经理在的那些会议，大家（基本上每个人）都不想说任何话，基本等经理把事情布置完毕后，大家散会，在会后也基本上不提这次开会的任何事情，就好象这个会议没有开过。
为什么会有如此大的差别？
原因有两个：经理在每次开会前，都在批评每个人一番，基本上是按照顺序来，在这样的会议上大家就好象"牛鬼蛇神"一样。批评完后，经理再按照顺序来询问这些成员有没有什么问题，每个人都想早点出来，固然什么问题也没有了。
就是因为大家什么都没听进去，所以什么也不太记得，会后讨论什么？即使有人提及此次开会的话题，对方马上说，没听清楚或说忘了。如此的什么会议也是无效的。
如何把这样一个团队改造成一个优秀的团队呢？
方法是：有效的沟通和适当的授权意识（经理和小组成员）。给小组某成员适当授权，来改变经理负责制的不良情况，在给小组授权的同时，可能在开始小组成员可能还不能够接受，但一段时间后便基本改善了。
对于优秀团队其他特征又如何？在上面我们已经简单地描述优秀团队的特征了，下面我们再详细描述这些特征：
1． 团队规模：开发时间在6~14月的4~8人的团队最佳。
一些专家认为团队的规模一般要少于8~10人，若这个项目需要多于此些人来完成，可将小组分为多个团队。但有些小组若有较高的凝聚力，也可以适当超过这个数字，当然这个也在适当情况生效。
2． 注重合作：项目经理应以团队的合作为主要的目标，而不应看重某个人的能力。
注重合作是团队的核心，建立团队的目点就是合作，在一个基本的"认同点"上寻找属于自己的一方面。就好象我国的社会主义的现代化建设一样，一定要强调"一个中心"的问题，然后才是"两个基本点"。
我们为什么要组成团队？就是为了合作！
3．求同存异：要有共同的目标、可提升的意愿（主要是指技术上）。
建立战略性的伙伴关系。团队成员的相互认同感、相互信任。如此在一些问题上就把小事进行化简，紧密合作时，就不会将时间浪费在迷途上。在人员的成就感方面，一个团队的需要就是一个"使命"，这个"使命"的完成，才能使得团队的人员在成就感上得到满足。若当一个团队没有面临挑战时可能比这个团队面临挑战时更加不团结。因为更多的时候人们在"困难"的环境中更加容易合作。所以在团队中的任何一个人不能给这个团队带来无聊的目标。
若团队的成员对彼此相互信赖，他们就会有沟通的意愿，事实上他们就是相互吸引(这个问题是个心理因素，我建议项目经理学习一点心理学，但不要学的太多会走火入魔的！)，有了这一点因素，团队就会以一个整体的面貌出现。在任何问题上就避免了一切问题（包括能力、工资福利、奖惩、技术条件、办公实施等）。
4．自主意识：有自主意识并追求相同的结果。
在很多情况下，一个团队的所有成员技术水平相当，不容易从中间抽取一个人来进行项目管理，这个时候也无须进行什么授权，改为某种监控方式即可。若在这个方式下获得成功，就必须团队的每个成员有自主意识，共产主义社会了，每个人都主人！
在团队中，小组的每个成员的角色都是不同的，若小组成员没有自主意识，不能进行沟通（最主要的是主动地沟通），那么即使是在技术上的顶尖人物，也不会做出什么好软件，除非每个人各做一套。
5．适当享受：需要高层次的享受（根本性的需求）。
没有愉快的心情，就没有什么好的效益，这些愉快的心情从那里来，我告诉大家一个生活的方式，我在到公司的第一分钟，我的做的是吃一块糖，然后告诉自己生活中每天都是甜蜜的，心情倍好，工作效率也不差，即使在最苦难的时期，我也保证开心。当然愉快的心情也来自其他，比如说好的工作环境、一个良好的工作氛围，这个氛围也不一定是工作上，在其他方面也可以，比如说共同爱好、兴趣呀、幽默感什么的！
6．有效沟通：有效的沟通和适当的授权意识。
作为开发过程的实际经验，表现出以下结果，一个团队的沟通方式异常的重要，一个有效的沟通方式并不适合每个团队，每个团队根据自身地特点选择沟通方式。
在我接触的所有的优秀的团队(相对的，国内还没有一个可以是称得上优秀的团队)，基本上在沟通上有一个较好的方式方法。比如小组会议、白板或BBS(计划进度、开发难题、午餐讨论（作者认为这是最简单，但又是最有效的方式）)，在一些有效的沟通上人员会表达自己的真实感受，若成员不能表述自己的真实感受，在计划上、进度上就没有办法实施，即使实施了也没有什么较好的结果。
好的团队表现如此，但差的团队有那些特征呢？若存在这些特性我们将如何处理。
好，我们来罗列一下：
1． 缺乏共同的意愿。
一个团队的组成就是依靠一个小组的"共同的意愿"，这个"共同的意愿"是核心的问题，若组成这个团队的时候，大家带有自己的意愿进入小组，当他（们）的意愿没有得到实现时，他（们）可能会偏离项目本身去做另外一件事（这件当然与项目无关），相应的表现出来的特征是部分人员做与项目无关的事情。从而影响整个小组的士气，削弱小组的凝聚力、降低工作效率。
2． 没有认同感。
在小组的认同感上，我有两个看法，一个是小组成员对小组的认同感；一个是小组成员之间的认同感。没有认同感就在思想的本身不会去要求对方（没有得到你认同的成员或小组）按照规则进行实施，因为你认为这种规则他（它）无法实施。从而无法给小组或小组成员带来压力，同时自己也在某种程度上失去责任感。
在小组成员沟通不畅地情况下，这个问题就存在，或者在某些对该项目有轻视的倾向时也有这种观点。
3． 生产力障碍。
生产力是什么？是产生有效代码的能力。思考一下项目为什么会延期？为什么会失控？主要的问题还在于小组的能力，当现在的工作所需的时间大于原本计划的最大时间时，这个小组肯定存在能力障碍。
4． 低效率沟通。
缺乏共同的意愿和没有认同感都会产生沟通不畅的情况，当然还存在一种最大的情况也会导致沟通不畅，就是沟通方法不对。当一些接口性问题调节不及时或得不到调节的时候，就说明沟通不畅。
5． 缺乏信任。
该问题和没有认同感表现出相似的特征。
6． 有问题的员工。
一般情况下有问题的人员从不积极参与团队的活动；经常抱怨团队的决定；他们宁愿让自己无知，也不向其他成员学习；有过分的保密欲望，做任何事情不与别人商量；小组的其他成员都抱怨的人…。
如何解决这些问题：对于有问题的员工应该更换，以免破坏小组的风气，但该员工在该项目占有一定的分量，则需要指导他如何和团队的其他成员合作，尽量采用积极地方式让小组的其他成员与他沟通。若指导在短时间内没有明显的改善，则需要立即更换。
端正小组成员的态度（将在第三节详细描述），很多时候并不是技术上的主要因素造成项目的延迟或失败，基本上是小组成员的态度和心理意识，由此导致一至五的所有问题，端正小组成员的思想意识，我认为比提高小组成员的技术水平更对项目本身带来直接地、快速的好处。
如何长期有效建立自己的团队？这个不仅仅是项目经理们的愿望，也是关系到公司的整体的、长远的利益和发展。
1．制定小组较为持久的目标或战略；
小组的持久的目标是小组存在的最稳定的因素之一，当然小组的目标也不宜太长，因为时间长的目标也将降低小组的士气。原因很简单，在一个短的时间内不能实现一个什么间断性目标，若目标确实很持久，那么就将目标分成若干个间断性的目标，分期实现。
2．采用低的团队开销；
团队的开销直接影响的是团队存在时间的长短，若团队的时间存在长，在项目的实施中就存在一定的底气，这个底气来自于后备资金的支持，无论在分配利益上，还是在硬件实施的改善，激励机制的调整都有一定的余地。
这个时候我们并不能理解为增加团队的费用，这个是两个不同的意思，若在实际上是增加了团队的费用来改善团队的话，基本上就失去意义了。
3．尽量避免采用有问题个人；
有问题的员工在什么样的单位都存在，然而，如何调整好这些有问题的员工（这个是公司整体的机制）。但若建立一个长期有效的团队，还是尽量避免采用有问题的员工。
一般有问题的员工是不能与大家合作的，即使如此也会在某种程度上排斥部分其他员工从而影响团队的整体性。
4．减少人员流动或合理流动；
中国目前这些状况并不能带来一个良好的机制，因为大多数公司在员工的使用，不能做到人员的合理流动，有项目就一股脑地上，没有先后或层次，没有分工。
由于这些情况的大量存在，固然，人员的合理流动是一个团队长期存在的首要因素。
5．注意团队文化
目前，最重要的问题就是当项目进行一半时，核心人员突然离去，这损失就很大了，但是一般情况下，这个核心人员的离去，还将会影响到其他个体一起离去，这个对项目将是致命地打击。为什么存在这样的情况，团队文化！由于在团队中团队文化的形成是由于某个人起到一定的作用，固然这个核心人物将直接影响整个团队。
所以，在建立长期有效的团队同时，也应该注意自己小组的文化！
用心管理，创造高绩效的团队文化
孙子兵法说，"克敌，攻城为下，攻心为上。"
　　在管理上，这个道理同样适用。
　　管理的意义就在于管理者与下属员工一起完成工作，共同创造高绩效。
　　在完成工作的过程中，规划未来部署工作要用心，指导员工正确工作要用心，创造高绩效的团队文化要用心，开拓创新要用心。惟有不断用心，管理目标才能被完成并做得更好，惟有不断用心，管理者和员工才能在工作中不断获得提高和超越。总之，所有的一切都离不开用心。
　　一定意义上，管理者的用心程度与其优秀程度和工作业绩成正比，用心管理比直接的用"薪"（薪水）管理意义更为深远、效果更好。
　　用心管理不是简单地要求管理者要有责任感有具备奉献精神，当然这些基本的素质要求必不可少。但是，作为用心管理，更多的是要求管理者能够在其位谋其政负其责，把应该做好的事情做好，把应该管好的人管好，真正担负起管理者的职责，做一个高绩效的管理者，创造高绩效的团队文化，管出高绩效的员工。
　　考察某些企业管理层的表现，在用心管理这个方面，许多管理者的做法还有很大的改善余地，做的好不够好。工作当中管理者不用全心、不尽全力、遇事推脱、逃避责任、逃避困难、在责任和压力面前躲躲闪闪、能过且过的现象比较多见。
　　管理层不用全心、不尽全力的低绩效表现正在给员工的士气造成严重影响，给企业的发展埋下隐患。如果管理者不能用心履行自己的职责，管理手段简单粗浅，势必会影响管理的效果，降低管理的效率。如果这个问题持续得不到有效的解决，势必会给企业的发展造成致命的伤害。
　　用心管理作为现代管理者的一项重要素质要求和企业管理的一个重要课题必须被提到议事日程，尽快加以解决。
1. 管理层不用心的低绩效主要表现：
（1）工作缺乏热情。
　　缺乏工作热情主要是因为企业缺乏有效的用人机制，管理者能上不能下，一旦一个员工升任到管理岗位就位子基本可以坐得很稳，不犯大错误的话不用担心被拿下，说不定还灰被策略地晋升到更高层次的职位。这种僵化的用人机制使得管理者缺乏工作的压力和前进的动力，养成了懒散的习惯和表面化的工作作风。
　　另外，一般管理者都在同一个岗位上呆了很长时间，已经失去了工作新鲜感，每天只是重复以前的工作过程，进行简单处理，基本都可以应付，如果没有上级领导安排任务，是无须多动脑筋的，这种现状导致了管理者缺乏工作动力，缺乏热情。
（2）工作态度有所转变。
　　在做管理者之前，为了获得公司领导的赏识和职位的晋升，他们一般都工作努力，态度认真。当真的坐上那个位子之后，有些管理者的工作态度开始慢慢转变。因为职位来之不易，因为曾经努力付出过，所?quot;聪明"的管理者们一般都采取了明哲保身的态度，慢慢从台前转到了幕后，隐藏在责任的背后，给工作的工作流程的衔接和工作的有效推动都带来了一定的麻烦。
（3）管理层的责任感减弱。
　　由于工作态度的转变，一般管理者的责任感就随之减弱了，他们都精通一套太极推手的手法，善于把责任化于无形或直接推给他人。管理者之间、部门之间互相推诿，出现责任问题的时候惟恐避之不及。为怕担责任，有些可做可不做的工作一般不做，可以提供帮助协助解决的事情以工作忙没有时间为借口推脱。
　　我们在工作当中都曾或多或少地碰到这样一些人、一些事。这些人的表现直接导致了员工的信心丧失和士气低落，组织的效率降低，有些人不管有些事无人管的现象很严重。谁会愿意为不负责任的领导卖命？谁会愿意在一片混乱纠缠不清的工作环境努力工作？
　　这种状况只能制造怨言和混乱。
（4）观念跟不上。
　　有些管理者的思想陈旧，观念落后，不能与时具进，观念的落后更加使得管理者不会用心管理。
　　在这个一切以市场为导向的时代，还有管理者在等着别人分配任务，没有任务，没有安排，宁可等待也不愿意多做一点工作，这恐怕是管理层绩效低下的重要的原因所在。他们没有很好地理解市场的概念，没有充分估计到市场竞争的残酷，缺乏竞争意识，缺乏危机感。不能前瞻性地看待市场和竞争，不能主动出击，而是被动接受，被动应付。
（5）缺乏必要的敬业精神。
　　作为企业的管理者，在充分享受职权、职位带来的收益的同时，也愿意付出，但给人的感觉总是还缺乏进一步的敬业精神和奉献意识，更多的管理者花更多的时间和精力去关注自己的利益得失，对责任与义务的问题却很少考虑，他们低估了自己的影响力，没有意识到自己的举动给企业员工带来的影响。
　　这些无疑在很大程度上削弱了企业竞争合力，限制了企业的发展。
（6）没有完善的企业文化。
　　企业的高层没有为企业建立良好的企业文化，没有明确的远景规划和战略目标，只是跟着感觉走，所以无法形成核心动力，大家不知道自己到底要做什么，要怎么做才好，这也在一定程度上限制了管理层能力的发挥，没有共同一致的目标，就谈不上凝聚力和向心力，力量只能在内耗中慢慢弱化。
（7）能力问题。
　　由于观念和学习跟不上，一些管理者的工作技能在快速发展的竞争环境下迅速递减，渐渐落后于时代的发展，落后于公司的成长速度，甚至能力不如自己的下属。管理者技能低下就无法指导帮助自己的员工进步，也不能很好地做好授权沟通，造成了管理效率和员工绩效下降。
2. 管理不用心的后果
　　小王是一家企业的ERP项目负责人，为人老实，工作肯干，业绩优秀，ERP项目在他的认真操作下已经开始公司产生效益了。
　　但是，去年年底他却向公司提出了终止劳动合同的要求，原因是他感觉公司管理层工作太不用心，管理者们要么各忙各的，要么不管不问，完全没有把这个花费不匪的项目放在心上，什么事情都要自己协调，自己处理，到处都是白眼和冷遇，到处都嫌麻烦。
　　另外，他对自己的薪水也不太满意。做项目两年多了，工资还是以前的一千多块，比一个事务性工作的内勤的工资多不了几个钱，公司领导根本没有将他的待遇问题放在心上。
　　小王是这家小型企业的唯一的电脑高手，擅长程序编程，工作有耐心，坐得住，工作成绩也不错，像他这样水平的编程高手，市场价最少也得月薪4000元以上，可是在这个公司却拿不到两千。这且不说，关键是公司领导根本没有把ERP项目真正当回事，口头上都表示的很好，要重视、要认真对待、要做好之类的话说了说了不少，在处理实际问题上却左躲右闪，好像ERP项目就是小王一个人的事情。
　　小王为使ERP软件更加适合公司的流程，更加本地化和个性化，便于ERP软件和公司的工作流程成功实现对接，花费了不少的心血和精力，先后为公司设计开发了十几个小的辅助软件，工作成果卓著。当然这也给他增加了很多的烦恼和无奈。
　　烦恼和无奈来自于因缺乏领导支持而生出的孤独感和无力感。在公司，没有其他人包括主管领导和他交流工作，没有人可以在ERP项目上对他提供帮助，有些人惟恐避之而不及，在他们看来，ERP的实施增加了他们的负担，做些无用功，上还不如不上好。有些人不但不提供帮助，还处处设置障碍，制造麻烦，一个BOM的录入问题就烦恼了小王很长时间，管理层最终也没有给出一个合理的解决办法。
　　用孤军奋战形容小王的感受恐怕最为贴切。
　　更让小王伤心的是，他从别人那里听到了公司某些领导说的风凉




如何对付不合作的业务决策人
世上无坦途，每个项目都会存在必须克服的障碍。比如，最后完成期限提前、范围变动乃至天灾人祸等等都会令项目经理焦头烂额，疲于应付，当你的主要信息来源表明你的工作似乎同正确的前进方向背道而驰时你该如何是好？请遵从以下的3条“交通规则”吧，力争你的努力终有所偿，工作进度一往无前，而且，别把你的项目决策人甩在后面。他可是你的项目“大车”上一个要命的关键“乘客”。
掌握主动
项目管理要想获得成功，关键就是参与。当应用这一原则时，这个概念能防止你的项目由于缺乏交流和决策混乱而迷途太远。
实际上，存在交流问题的迹象首先就会出现在关键的项目定义阶段期间。你主持了最初的概念会议而且试着把软件功能组织为一幅完整的图像。不幸的是，这正是你最依赖项目决策人的场合，但他的支持可能微弱的象条小溪甚至压根没有。
为了避免出现这种状况，你一定要让项目的决策人尽量毫无痛苦地参与到项目中来。一定要主动探询你需要的信息而不是坐等它自己跑到你面前来。最初的项目计划对你的成功非常关键，千万不要拖延。
多花点时间记录下各方面存在的问题，最好以一种简短会议的方式见见项目决策人。如果你提出的问题他们不能回答，那么你务必要做出各种可能的假设并且把它们记录在你的项目计划中。你得清楚，这可是你需要一直坚持知道听见其他声音的行动过程。白纸黑字地摆出各种假设会驱使项目决策人做出明确的决定，而且还可能创造出一直欠缺的紧迫感。
这一阶段同时也是考察项目决策人心目中衡量项目优先级的良机。他们在这个时候甚至可能还没有想过具体的解决方案，而定义优先级倒可能揭示出你以前并不清楚的关键信息。
既然你已经历了计划进度的阶段，接下来就该弄清楚你的前进目标是什么。
绘制地图
当项目决策人可能落在车轮后面时，项目经理的工作实质上就是具体操作了。项目决策人的工作很少与他或她在交付解决方案方面的角色有关。告之决策人如何以最安全、最快捷的路线抵达最后的目的地而且保证他或她紧随其后完全是你的责任。
有时在同某个项目决策人打交道时，你可能会撞上一种遭遇“伏击”的问题。为了绕过这一障碍，你必须经历一个定义解决方案并跟从它行动的过程。用这种方法，你的项目将更为切实有据，而你的信息请求则更少些个人的色彩了。
项目决策人越难合作，拥有详细记录的项目计划就显得越发重要。设置计划的轮廓都能帮助你防止决策人对你的解决方案表现出明显的冷漠。
如果你确实无法得到明确的回答，那么从具体开发任务开始你就需要为应付变化做准备，例如设计项目变动表等。这样可以帮助你记录下缺乏交流的困难处境下所付出的真实努力，例如由于决策变更而消耗的时间和费用等。
如果你预先通知项目决策人未确定的假设将同变化顺序过程合并为一体，那么他或她至少会理解那些无聊的唠叨会对项目产生严重的影响。晚些时候，如果源自决策的缺乏而产生的项目变化就会开始影响你的时间安排，你可以提交报告证明你调整交付日期或在功能上折中有了明确的理由。
到目前为止，我的建议只是为你提供同不合作的项目决策人打交道的常识性的、逻辑上的应对措施。但是，如果你把以上的招数都用过了却还是无法得到你希望的结果，此时你又该怎么办呢？真要到了这个地步，那你得考虑亲自掌握方向盘了。
做一位影子决策人
没人愿意自己的权威受到蔑视，这正是某些项目迟迟无法决策的原因，项目经理总是拒绝承担明显属于其他人的责任。最终，交付你的解决方案成为了你的首要目标。如果项目决策人正好挡在了这条道上，那么此时此刻就必须采取更为激烈的措施了。不得罪项目决策人却仍然掌控项目的前进方向也不是不可能。
首先，尽量提出多种决策选择，其间的差别不要太大，以利于显然的正确决策。最好总是提出3种选择，它们是：显而易见的正确答案、显然的错误答案以及虽然可行但却乏善可陈的方案。乍看起来，这样做的功利性也太强了点，而且确实就是十足的狡猾策略。然而，决策的实际行为来自适当的人选，而且他或她决不会猜想你甚至在同他/她会谈之前就已经下定了决心。为达目不择手段，反正决策人还在你的控制之下。
当然，在同决策人讨论之前一定要实现周密计划。就算决策人没有给出明确的答案，如果他或她不喜欢最后结果，你至少也留下了宽容的余地。记住，与得到许可相比道歉更为容易，除非决策人对你的行动缺乏判断力。
如果项目决策人在做决定的时候采取不合作的态度，那么你不妨把有关的各种信息统统提交给他或她。一定要非常慷慨地提交各种报告、更新哪怕他们根本没时间阅读。用这种方法，当需要立即解决的问题出现时它的重要性才会因你已经提出过而大大强化。另外，问题的影响程度也不要过分地夸大，因为到这个时候令人不快的信息已经完全淹没在了正面结果的海洋里。
要诚实而且掌握外交手段，记住你交付解决方案的第二个目标就是让每个人，包括说了也没用的决策人都不会做出负面评价。一定要保证每一个决定都实现了项目的最大利益而且鼓励了项目的优先级的提高。
如果你无法令项目决策人参与决策那么你不妨把你做出每个决定都通知他。让项目决策人感到他或她好象还在控制着项目的运转，从而摆出一种承认你做得对的姿态。就算你在项目中的每个转折点都是真正的中流砥柱，也也应该记住正是项目决策人才能确定项目乃至你在项目中扮演的角色是否成功。
小结
以上3条交通规则应该帮助你的项目在不过分倚赖邪门歪道的情况下赢得成功。如果你的业务决策人没有掌握方向盘那么你仍然能阻止项目越轨。采取行动、有组织而且面向过程、承担你应当承担的责任、拒绝不应该由你负责的责任，只有这样，你才能保证项目获得成功。就算你必须忍受项目决策人的又踢又叫而驱动项目前进，他或她也会从任务完成的回报中获益，而不论他或她是否缺乏交流能力。结果，你和你的项目都能从你良好的意图中得益。