一、XXX管理平台系统概要

项目背景

某公司为了解决各部门信息孤岛效应，为了向客户提供具有公司品牌的、内容全面、高质量、个性化、统一的优质信息服务，树立公司形象、提高客户忠诚度，同时打造一个优质的客户品牌；需要建立一个完善的XXX系统管理平台，以全方位地解决公司的信息服务的问题，实现资讯数据的共享。

该平台主要包含信息中心数据库建设和围绕该中心数据库建设的相关项目建设。

系统硬件

该项目的系统架构方案从最初初稿到最终定稿，先后经过了几十个版本的不断修改、调整和优化，最终在机器上架前一天才算告一段落。该系统架构方案包含硬件（服务器、防火墙、交换机、存储设备等共计约50多台，硬件费用将近1000万）该系统网络结构比较复杂，包括internet网络、网通网络、电信网络、中心机房网络、与其它系统网络。

系统概要架构图

 系统软件

操作系统：AIX5.0，Linux5.3，Windows Server2003

数据库：Oracle10g for Linux and cluster ware

系统监控软件：Nagios

系统集成难点：网络部署、系统监控、数据库同步、数据库集群等

系统开发软件

开发工具：Java、Delphi

开发软件架构：B/S & C/S

B/S缓存：OS Cache+ Eh Cache

B/S架构：Structs Spring + Hibernate/ Structs Spring + iBatis

其它：ASP,dll

中间件：resin

系统同步和接口

MQ、Webservice接口，与外围基础数据同步

Oracle Stream数据同步，大部分数据采用

Oracle PL/SQL存储过程同步，双向同步部分

程序同步，与外围系统大量数据同步

该平台系统构成

中心数据库系统

3个纯web系统

1个B/S+C/S系统

相关接口开发

系统监控开发

系统规模

耗时将近12个月，总计120个人月

核心开发团队12人，参与总人数28人，2个分项目经理。

 这是我所带过的最大规模的团队，其中的辛酸苦辣也只有个中人方能了解，以后慢慢道来吧。

本人也根据自身的项目经历和从业经验，分享一下自己对项目管理人员所需能力的理解；当然不同软件能力成熟度的公司对于项目经理能力要求也不尽相同，人不能脱离大环境而存在；以下能力按重要程度进行排序。

沟通能力

与销售人员、售前人员相比，技术人员的最大差距在哪里？就是沟通能力。无论从拜访客户、需求调研、商务谈判、与公司的上下级沟通还是甲乙双方的人际关系，感觉商务人员确实要比纯粹的技术人员高明很多；项目经理相当于半个商务人员，我也一致致力于此，但从和商务人员近一年的相处而言，确实要学习的太多了。

项目经理的沟通主要包括内部沟通和外部沟通。外部沟通是与甲方和相关方的沟通，包括甲方的领导，项目经理，技术人员，以及相关接口系统的友商，沟通的目的在于确认双方需求、系统进展、相关协调等等。内部沟通主要是与公司内部的沟通，包括公司相关高层领导，平级协助部门，团队成员，主要目的是为了创建一个良好的工作氛围，尽可能屏蔽与项目无关的损耗，使团队集中精力到项目过程中去。

针对不同的对象沟通的方式也是不同。外部沟通过程中甲乙双方的地位实际上是不平衡的，乙方处于弱势位置，为了避免命令式的强制/被压制，服从/被服从的发生，最好是双方建立良好的朋友关系，这样甲方既可以及时了解项目的进展，也可以了解项目经理和项目所面临的困难，以期达到部分谅解；外部沟通也包括一些营销活动，这取决与甲方的喜好和公司的财务制度，呵呵。关于这一点，销售人员更有发言权。

内部沟通中与公司高层领导的沟通主要是进行耐心说服工作，通过邮件电话均可，当然如果无法对领导实施相应的压力比如资源，也可以借助甲方的力量(这是下下策)；与部门评级之间的沟通，要尽量采用温和的手段，为了避免无效沟通最好知公司高层、其直接领导，然后再进行沟通；与团队成员的沟通，首先是进行会议沟通，会议沟通主要发生在项目的关键点上，比如项目启动会、项目验收会，或者重大事项的时候，频繁的会议沟通，我不认为有太大用途，尤其是人多的时候；其次是1对1的沟通，与下面的项目经理和团队成员进行面对面沟通，可以及时了解项目进展、团队成员的思想波动，有针对的为其提出建议、解决方案，让团队成员感觉到项目经理的人文关怀，并传达公司的温暖；最后是避免不了的项目活动，聚餐、爬山、电影都是很好的活动方式，这取决与项目经理的权限和公司的财务制度。

关于沟通的目的，如何进行沟通、要解决什么问题，大体可以按如下步骤来做：

是什么？

为什么？

怎么做？

这几点看起来很容易，实际上包含了你对问题的理解、总结、思考、应急能力；记住这三点，并应用在你今后的沟通过程中(比如会议、电话、邮件)，相信对改善和提高你的沟通能力和沟通效果有很大的帮助。

组织能力

建立核心团队：

这里的核心团队是指子项目的项目经理和关键技术人员，具体视不同的项目规模而定，人员的管理和沟通是有成本的，我个人认为3-5个人比较合适，太多的人员太多的细节靠一个人有限的精力是无法进行跟踪和控制的；当然这里的核心团队成员是指那些技术和架构水平高超、有一定的项目管理能力、善于团队协助的人；核心团队成立越早越好，有利于项目的稳定和提前进入角色。如前文中所述，不善于团队协助的人只能带来负面效应。

协作能力

协作能力主要表现在项目内部各团队之间的协作、与公司内部其他团队的协作，与项目相关的友商的协作能力上。

项目管理能力

软件工程

软件工程按照传统的理解即需求分析、系统设计、系统开发、系统测试，这对项目经理而言是最起码的要求；就大部分国内项目而言，项目经理还是要样样都懂一点的，我不太赞同工作2、3年就自命不凡担当项目经理的人，技术、业务、人际关系的把握的积累都是需要时间的；当然外企也有职业的项目经理，他们可以不专技术，而专注过程。

软件能力成熟度

软件过程能力（Software Process Capability）：描述了在遵循一个软件过程后能够得到的预期结果的界限范围。该指标是对能力的一种衡量，用它可以预测一个组织（企业）在承接下一个软件项目时，所能期望得到的最可能的结果。IT企业有自己的软件能力成熟度，当然个人也有自己的软件能力成熟度，即体现在个人对过程的定义、监控、跟踪和度量上。本人有幸在3家CMM5的公司工作过，不过仍称不上对CMM有多深的研究，一来过于繁琐，再则软件能力成熟度与所在的IT环境有密切的关系，过程的实施和度量需要一系列的保障；事实上严格遵循CMM流程的企业并不多，基本上都是为了内部评估而评估的；不过基于过程的思想值得项目去参考和学习。

关于本项目的话，如果一定要说有什么软件能力成熟度的话，我认为是2级吧，项目管理的基本流程和系统文档已经有了，做类似的项目是具备一定的复制性的。

架构能力

系统架构，这个与项目经理的角色和定位有一定关系，项目经理需要从整体上把握系统的各个环节，硬件、操作系统、数据库、软件、软件框架、甚至测试，都需要有所涉猎，能做到一精多专已经是不错的状况了，能做到全能的人应该是大师级的人物了，至少我不是，呵呵。

系统集成，这项能力与具体的项目有关，对于小项目来说只需要完成相应的业务功能，对性能的考虑、系统扩展型、系统部署、外围系统的接口要求并不高，所以对系统集成考虑的较少；如果实施大中型项目的话，项目经理最好具备起码的思想和评估能力。

关于系统架构、系统集成能力的提高，需要本身知识储备的日积月累、阅读大量的相关资料、以及项目实施过程中的学习，除此之外，别无办法。

学习能力

技术学习

项目经理需要的一个最基本的能力便是对他们的基本技术技能进行深度和广度的拓展。目前的技术知识更新换代过于频繁，但技术本身的内涵确实恒久不变的。如Oracle从9i到11g，其Concept变更的并不多，其基于关系的数据库特性在短期内还是无法改变的；如java和.net之争，其核心仍是面向对象的；如各技术框架之选型，无非是实现展现层、业务逻辑层、控制层、数据持久层的分离；适当的扩展自己的技术能力也是与时俱进的一种体现。

业务学习

相比技术而言，业务是更难学习的，尤其是财务、ERP、金融证券业务等，与IT背景相距深远，但是又不能不学，作为项目经理需要与甲方业务方进行沟通，缺乏相关知识背景，会造成沟通上的鸿沟，甚至无法理解对方的意图。当然并不是说项目经理一定要成为业务专家，事实上也是不太可能的。

文档能力

        项目经理一定要会写，这是由项目经理的工作性质所决定的，从解决方案、系统架构、需求文档、验收文档的编写，到设计文档、测试文档的规格要求，无不打上项目管理人员的烙印；撰写文档是组织自己思路进行深层思考的过程，如果文档无法表达明白的话，相信自己的思考也一定不成熟；撰写文档也是沟通的需要，会议纪要、需求文档如果写的不清不楚的话，双方如果进行确认？想清楚才能写明白这是很简单的一个道理。

总结

        项目经理的能力依据项目的规模和公司的成熟度有不同的要求，不能一概而论；举例而言，在本系统中假设时间为100的话，各项过程所占的比例分别如下：

 

 

 

如果你处在一个专业的IT公司，你未必会意识到项目组织结构对IT项目管理的影响，因为在大多数的专业IT公司中，基本上都是项目型组织或者强矩阵型组织结构，在这样的组织结构中，项目经理对项目全面负责，对客户高度负责，项目团队工作精力集中，协作强，沟通效率高，你会感觉到项目经理的权威和职能至少还是有保障的。

   

假如不幸你处于职能型组织或者弱矩阵型组织中，有时候你会感觉无所适从，人力资源的获取、管理、考核都无法正常开展，你会发现自己置身于一个弱势地位，团队建设有时会变得瘫痪，严重一点会影响团队合作甚至拖垮项目的总体进度。

如果你要寻求合适的资源，首先需要向了解各个部门内部合适的人选，然后征求个人的选择和看法；其次与其直接汇报经理进行沟通，看该资源是否能全身投入；再次协调不成需要向上级领导进行汇报；需要经过层层沟通。

其次关于考核和冲突管理，关于考核，在弱矩阵型组织和职能组织中团队成员的考核是由汇报经理决定的，这也决定了项目经理作为管理者的弱势地位，无法实施项目经理正常的权限，“要敢管”就完全成了一句空话，更有甚者会出现团队成员未经允许擅自离队的情况；团队有合作也有矛盾，不同的团体之间也会有矛盾产生，通常管理者会站在自己成员的角度进行所谓的护短行为，如前面所述，严重的影响了项目经理的积极性和整个团队的和谐和建设。

解决办法：如果无法改变IT部门的组织现状，则至少保证现场项目经理的权威，现场的团队管理应由项目经理全权负责，其次考核应该由项目经理和汇报经理双方共同决定，再次建立一个仲裁组织，对项目中遇到的冲突进行决策。

项目风险管理是指对项目风险从识别到分析乃至采取应对措施等一系列过程，它包括将积极因素所产生的影响最大化和使消极因素产生的影响最小化两方面内容。

风险识别--确认哪些风险有可能会影响项目进展，并记录每个风险所具有的特点。

风险量化--评估风险和风险之间的相互作用，以便评定项目可能的产出结果的范围。

风险对策研究--确定对机会进行选择的步骤及对危险作出应对的步骤。

风险对策实施控制--对项目进程中风险所产生的变化作出反应。

本文无意讨论项目风险管理的一般流程和相应的控制，只是根据项目中所遭遇到的问题把自己的一点心得体会表达出来，很多在其他人眼中也许算不上风险，有一部分甚至超出了项目管理的外延，但对于部分IT企业或者中型项目管理，至少是本人所经历到的事情，或许对大家有所参考。

背景：本人于08年06月入职某公司，8月份即开始负责该项目，对公司组织、制度和相关业务缺乏了解；公司于08年4月进行重组，高层和人员变动剧烈，新老冲突严重；公司IT力量比较薄弱，产品线较丰富，均为小项目，但自命不凡；后来了解到我是作为双方利益冲突的牺牲品来负责该项目的。

企业内部管理的风险

公司领导对IT管理的熟悉程度。公司领导对IT管理的熟悉程度事实上决定了项目管理中的很多事情例如人员，但不幸的是往往公司的领导非IT出身，这意味着你要尽更多的精力来与之进行沟通、解释工作；曾有领导认为大项目是小项目的简单叠加，即人月的倍数；更甚者领导对系统集成缺乏认知，我曾花了3个月进行沟通，甚至差点导致项目流产。

公司领导对IT项目的支持程度。公司领导对IT的熟悉程度影响了对IT项目的支持程度，但另一方面与公司高层对本公司的IT定位也有关系。

公司财务制度。这个说起来与公司内部管理和制度有关了，财务控制成本，项目经理也要控制成本，但是做起来就比较困难了，日常费用的报销、应急费用的申请、是否有备用金、是否有项目活动经费、是否有项目奖金、甚至团队成员的住宿、考勤、租房等等；如果与财务产生了矛盾，也会让你吃不了兜着走；项目经理是否能够承受这么多的额外工作？

公司HR制度。主要是项目中新员工的招聘、转正申请、工资发放等等，外企和正规化的IT公司应该不存在这类问题，但是我遇到很多类似问题，也帮助团队成员去讨薪；这类问题的解决与否直接影响到项目团队成员的积极性。

公司组织架构。大中型项目往往意味着你要同公司内部多个部门直接进行协同工作，了解公司部门组织结构，认识相关部门经理，甚至公司领导会对解决问题的效率有很大影响。

企业项目管理的成熟度

IT部门组织架构。了解IT部门的组织结构是项目负责制还是等级制度，可以了解自己所处的环境，以便寻求合适的资源。

公司所做过的最大项目规模。了解公司所做的项目规模可以直接对公司的软件和实施能力进行评估，就像让一个儿童去做成人的工作，显然是勉为其难的。当然通常情况下公司领导会按照项目金额去衡量项目规模，导致缺乏可比性。

公司之前有没有做过类似的项目。这个包括业务类似、架构类似、技术类似等。

公司的软件能力成熟度。软件能力成熟度反映了一家公司的IT管理水平，高成熟度的公司至少可以让你在项目流程、项目文档、项目支持上受益。

公司IT技术总监的能力。往往一个公司的IT技术总监能力和整个公司的IT水平息息相关，他的能力和水平也影响到对项目的支持水平。呵呵，反正我每次去公司开会寻求资源时总是要PK上半天的。

项目经理的职责风险

项目管理主要包括工作范围管理、时间管理、质量管理、成本管理、风险管理、沟通管理、人力资源管理、采购管理、整合管理。需要了解项目经理所拥有的权限。大多数情况下公司除了成本、人力资源、采购涉及到money的不会让你经手之外，恨不得会都让你包办。下面就是你的义务了，呵呵。

需要了解本项目经理所要负的全部义务。我理解的义务就是项目经理所要担当的角色，首先是保姆，最好用最少的money管理项目成员的吃喝拉撒睡；其次是炮眼，要勇于担负起所有甲方对公司的压力，以及团队成员与公司之间的压力，不该管不要管，要少管(这是公司其他领导的原话)，实施上可能吗？然后是架构师、系统分析员、需求调研员、DBA、程序员，曾经有领导问我会不会写代码，我说我不会，当然是气话，事实上我写的不比任何一位成员少。

项目经理的人力资源调度能力

这个与公司组织、IT部门组织结构、甚至技术总监有很大关系。避免双重管理，在我的team中有4类人，2拨人来自于公司IT部门两个不同的领导；1拨人是属于我直接管理，当然人很少；还有1拨人属于支援性质的；其中3类人不归我考核、管理；领导总是会说你要敢于管理，呵呵，怎么管？借调个人，首先要确认是谁的人马，然后向个人电话沟通，再向相应的主管电话沟通，最后向公司领导沟通。

如何处理害群之马，项目管理比较忌讳团队成员无法按照自己的进度进行，因为是个团队协同工作，项目不能因为个人而有所延误；其次希望自己的团队成员能够积极沟通，当无法正常按进度实施的时候，至少双方能够积极交流共同面对分析并解决。在我的一个子项目中，需求调研人员换了3批次，项目经理换了3批次，项目成员换了3批次；项目经理不辞而别达三次，辞退员工4人，原因是认为团队成员不合格，其实我个人认为是他不合格，为了此事还曾与他的直接主管吵了几次。据说他喜欢与业务比他强技术比他强的人进行配合，大概是我的能力太差了吧。

人员的技能问题

一个理想的团队包括子项目经理、系统架构师、系统管理员、DBA、高级工程师若干、工程师若干，测试员若干、美工等。平衡你的资源和相应人员，在一个资源不充足的团队中，只有勉为其难了，有什么样的人用什么样的人，尽量做到用人不疑，疑人不用；一个人尽量担当多个角色，挖掘个人潜力了。团队成员是需要培训的，这在外企通常做的比较好，内企则因项目通常人少，周期比较紧，结果无法实施。

系统集成能力

个人认为系统集成程度是大中型项目与小型项目的一个明显区别。系统集成能力主要表现在是否对系统硬件，操作系统，数据库，不同接口开发，系统架构上，这方面知识的积累并非一朝一夕所能造就，取决于公司的积累。

系统外包经验

当公司资源无法满足项目要求的时候，需要适当的引入外包资源；公司在这方面是否有过独立的经验，也对项目的顺利实施与否有很大关系。

甲方项目经理能力问题

甲方的项目经理素质的高低对项目的成本、范围、时间、沟通等几个方面均有相应的影响。不幸的是，我们很难影响甲方的决定。但至少和甲方的项目经理关系要做到融洽，而不要推到对立面去。

系统架构是项目中技术实现的最重要的环节。系统架构的良好与否关系到系统的性能指标、安全指标、稳定性指标、可扩展性、业务实现等等。

系统架构涉及到系统硬件的选型、网络拓扑、操作系统选型、数据库选型、B/S与C/S的选型、B/S各框架的选择、缓存的实现、数据库设计等诸多方面。

在大型IT企业中，项目经理和架构师是分离的；但对于国内IT公司尤其是小企业来说，就成了一种奢望。项目经理一肩挑的现状至少短期之内还是无法改变的，这自然也增加了项目经理的痛苦指数和工作量。

关于系统架构是什么？我最认同一句话：架构即关注点分离。

项目经理不是万能的，系统架构需要更广博的知识，当然某些方面专业的知识也是必须的，这取决于平时知识的积累和总结，也需要其他团队成员共同的努力。

系统硬件

关于系统硬件的选型，首先是根据业务需求和性能指标确定硬件的需求数量和相应型号；举例说：一个普通的B/S系统需要有web应用服务器，数据库服务器，如果对于性能有较高的要求，则需要增添cache服务器；如果对于稳定性和高可用性有特殊的要求，则需要对相应的服务器进行集群处理。

关于系统硬件的选型，一是关于厂商的选择(有IBM和HP之争)，一是关于机器架构的选择(PC服务器和小型机)，再则是某种机型的选择（在本系统中主要为HP360和HP580）；再细的话就是更细型号的选择了(HP360、HP580都至少有十几种型号)，最后是机器选件，比如是否需要扩充硬盘、内存或者CPU。

其实最重要的一项就是预算，呵呵。本系统的硬件采购是由甲方采购的，但是架构是由自己做的，方案如果有之前的案例就会很轻松很多，很不幸，这个方案改了几十版，跨度达到4个月。无他，对硬件，我不熟。

系统软件

关于系统软件的选择主要上是操作系统、数据库、开发工具

选择什么样的操作系统与计算机硬件本身有很密切的联系，当然也与甲方的要求有关。Linux/Windows/专有UNIX都是可选项，windows囿于安全性原因，一般不为推崇；UNIX与硬件有很大关联，一般也很少用；所以普遍选择的是Linux；

关于操作系统版本的选择，一般建议选择目前市面比较稳定的版本，最新的版本往往意味着兼容性问题，太老的版本一般有性能问题；

关于操作系统的32/64位的选择，这个需要硬件的支持；在64位CPU上安装32位的操作系统意味着资源的浪费；在这个项目上曾经考虑有所欠妥，结果造成了一定的问题。

关于数据库的选择，与操作系统有一定关系，也和对系统的安全性、稳定性、高并发性有一定关系；虽然一个好的DBA在任何一种数据库上都可以构建出高可用性的数据库，呵呵。

关于开发工具的选择，与操作系统相关，也与甲方的要求有关，开发工具一向有java和微软两条线路之争；在本系统中采用的当然是java了。

关于web中间件的选择，与开发工具、操作系统都有关系，JBOSS，websphere，tomcat，resin，web logic都有一定的拥蹇和市场；取决与甲方的要求和本团队对相应系统的熟悉程度。

B/S架构

关于系统软件架构通常是指的是B/S部分实现的具体框架，此部分仍属于技术架构部分。

众所周知，B/S的框架有不下数十种，常用的有SSH（Structs + Spring + Hibernate）和SSI（Structs + Spring + iBatis），SSH和SSI从本质上没有什么不同，就是实现业务逻辑层、控制层、数据持久层和展现层的分离。

B/S缓存的架构：OS Cache + Eh Cache 说到软件架构，我就不太在行了；我做过Powerbuilder，ASP，java(JSP,HTML,CSS,Javascript,structs,spring,xml,xsl,ajax,web service)不过都是入门级水平，实在连个称职的程序员都算不上，唯一的好处就是对方方面面都略知一二，查资料方便一点而已，呵呵。我个人只是在数据仓库和数据库开发、设计方面还算有点研究。

幸亏下面有相应的项目经理，也是项目中的技术经理，他在这方面是权威，B/S技术架构本来就是一个虚虚实实的框架，呵呵。

系统同步和接口架构

关于数据同步，在本平台中是最重要的环节，缺少数据的系统是无用的；为了实现系统数据同步架构，我曾先后在虚拟机上进行过oracle高级复制、Oracle Stream的测试，也曾为了该同步和公司技术总监吵过N多次，他主张用程序来实现，不过在他那边总是不了了之。

尽管通过测试，高级复制和stream都可以实现实时数据同步，不过我知道在实际生产环境中是远远不会这么简单的；

首先源数据和目标源的结构并非完全一致，允许目标源的结构大于原数据源的结构

其次多环节数据实时同步，从中心数据库到电信数据库，再从电信数据库同步到网通数据库。

再次各数据库均采用RAC方式，现实的例子中很少有类似应用。

最后Oracle的stream有许多的bug，需要进行不断调试和patch升级。

事实上，在同步方案的过程中，也遭遇到很大的困难，前后的测试和最终顺利实施经历了2个月之久，不过stream仍需要不断的人工监控和干预。我相信到目前为止即使市面上也没有任何一种完全稳定的同步方案。

关于MQ、Webservice、LDAP接口，目前的业务和技术虽然已经完全实现，但是还缺乏稳定性和一致性。

总结

系统架构是项目最重要的技术部分，它是否应该是项目经理的职责，暂且不谈；从现实的角度而言，技不压身，技能服众还是很有意义的；从项目经理角度来看，你能够准确的对项目进度、难度、工作量进行评估，对团队成员面临的困难迅速给出解决方案，减少项目经理和团队成员的沟壑；从团队成员角度来看，信任自己的项目经理，也是项目成功的一个重要因素。

项目经理能够通过对系统架构的设计,尽快评估出各部分的工作量,以安排相应的人力资源和工作计划,做到有的放矢,实际上本项目虽然包含几个业务系统,加上对本公司相关资源和技能的评估,但我个人认为系统集成和数据同步等在项目实施中占据了50%的工作量.

聊一下自己的总结吧，经验也是在教训中不断成长。

技术方面

        之前对硬件和网络缺乏基本的选型概念，以及对整个系统的整体和技术方案把握有所欠缺，导致整个系统架构从项目之始到系统部署完成一直处于变动之中，周期达5个月，版本不下几十版。

关于数据库方面，虽然对困难有所估计，也做过一些预研工作，但是对实施过程中的难度估计仍然有所不足。最典型的是安装了Oracle32位版本导致无法充分利用系统硬件资源，以及Oracle Stream数据同步过程中出现了若干的bug。

关于系统接口的处理，缺乏稳定性、健壮性、容错性，有待于系统设计的完善和技术人员水平的提高和总结。

业务方面

因为第一次从事该行业，对其中的数据库和业务缺乏了解，导致前期在系统需求汇报和与公司进行沟通寻求资源的时候，因为缺乏理论依据，结果导致沟通过程中发生了不少误会；这也是项目前期开展不顺利的一个原因。

与甲方进行沟通的时候，因为业务原因，完全依赖与相应的项目经理的沟通，自己则对各子系统细节缺乏深入了解，造成整体工作的被动。

团队方面

尽管有因人而异，因材施教之说，实际上不同的人在团队合作方面确实有不同的差别，尤其是项目的核心成员如果缺乏团队合作意识，对项目的进度和成本会造成延迟和增加，对项目团队建设和协作也会造成严重不良影响。

举例而言，某子系统，因人员原因，换了3拨需求调查人员，换了3拨项目经理，换了3拨开发人员；而集中在某项目经理上，更加典型，该项目经理做.Net开发出身，被公司派来做java项目，他的技术水平如何就不谈了；首先本系统准备采用Structs + Spring + iBatis的B/S架构，他非要自作主张使用Structs + Spring + Hibernate的B/S架构；缺乏与项目中的技术高手的交流，喜欢埋头苦干；缺乏与甲方的主动沟通，导致需求迟迟未定；他本人不熟悉java，却喜欢把java和.net进行比较，懂不懂就说java如何如何；比较喜欢钻研技术和追求完美的技术框架，而自己的能力却又无法达到，实际上到最后发现他的代码也不过如此，缺乏注释，代码缺乏分层控制；最重要的是对自己的团队成员缺乏理解和沟通，人的技术水平是无法实现突飞猛进的，懂不懂就拍桌子指责自己的团队成员，本来只有4个人的团队，结果被他赶走了5个人次，只有一个愿意跟他干活，人走了又去抱怨公司不给资源，确实在这方面公司有不少责任，但他自己何尝没有更大的责任呢？最后他先后撂挑子自己离开项目组3次，最后彻底走人了，我相信没几个人能受得了他的脾气。也许这个人很有钻研的精神，在充足的资源前提下能够做好产品，可是项目中更不需要缺乏团队精神的成员。