学位论文
论文题目：O公司软件测试团队建设案例研究
学位类别：工商管理硕士作者：导师：系别：经济与工商管理学院学号：学科领域：工商管理完成日期：2013年5月
北京师范大学研究生院
北京师范大学学位论文原创性声明
本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立进行研究工作所取得的成果。
除文中已经注明引用的内容外，本论文不含任何其他个人或集体已经发表或撰写过的作品成果。
对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。
本人完全意识到本声明的法律结果由本人承担。
学位论文作者签名： 日期： 年月日 关于论文使用授权的说明 学位论文作者完全了解北京师范大学有关保留和使用学位论文的规定，即：研究生在校攻读学位期间论文工作的知识产权单位属北京师范大学。
学校有权保留并向国家有关部门或机构送交论文的复印件和电子版，允许学位论文被查阅和借阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它复制手段保存、汇编学位论文。
（保密的学位论文在解密后遵守此规定） 保密论文注释：本学位论文属于保密在 年解密后适用本授权书。
非保密论文注释：本学位论文不属于保密范围，适用本授权书。
学位论文全文电子版同意提交后：□一年
□二年在校园网上发布，供校内师生浏览。
本人签名： 日期： 导师签名： 日期： O公司软件测试团队建设案例研究摘要 软件测试行业目前发展迅速、需求旺盛，但因行业本身太年轻，国内软件公司管理能力低下，造成软件测试人员流动大，工作效率低。
如何建立一个高效、稳定的软件测试团队成为越来越突出的问题。
O公司作为业界第二大软件公司，其软件测试团队建设经验具有一定的代表性。
本文描述了O公司一个软件测试团队的建立、震荡、发展的过程，以及在这个过程中发生的影响团队建设的四个典型事件，包括总监的疑惑、小赵、大李、Tony的恩怨、访问控制问题和老周的工作安排。
针对这些案例，依据团队建设相关理论，有侧重地分析了O公司软件测试团队在团队建设过程中遇到的团队沟通、团队激励、团队冲突、工作流程细化等方面的问题。
本文认为，在团队初建时期，应进行充分的沟通，建立全方位、全通道的沟通机制；在团队震荡时期，应建立有效的冲突管理机制，及时应对关系冲突和任务冲突；在规范时期，应进行机制建设，细化目标，建立柔性规章；在高产阶段，应进行合理的工作流程设计，提升团队整体绩效。
关键词：软件测试团队建设团队激励
1 OCOMPANYSOFTWARETESTINGTEAMBUILDINGCASESTUDIES ABSTRACT Softwaretestingindustryhasdevelopedrapidly,thedemandisexuberant,buttheindustryitselfistooyoung,poormanagementcapacityofthedomesticpanies,causingthesoftwaretestersfrequentlymovefrompanytoothers,lowefficiency.Howtobuildanefficient,stablesoftwaretestingteamistoemoreandmoreprominentquestion.pany,asthesecondlargestpanyintheindustry,thesoftwaretestingteambuildingexperienceiswithacertaindegreeofrepresentativeness. Thisarticledescribedtheprocessofonesoftwaretestingteamofpanytobebuilt,shocked,developedetc.Italsodescribedfourtypicalcaseswhichaffectedthesoftwaretestingteam’sbuilding,urredduringthatprocess.Thefourtypicalcasesincluded:Thedirector’sdoubt;GrudgesbetweenXiaoZhao,DaLiandTony;esscontrolissue;WorkassignmentofLaoZhou.Basedonthoseeventsinpracticeandrelatedtheoriesofteambuilding,analyzedtheissuesofmunication,teammotivation,teamconflictandworkflowrefinement,whichwereencounteredintheprocessofpany’ssoftwaretestingteambuilding. Thearticleconcludedthat:itshouldestablishprehensive，municationmechanismsduringtheearlyphaseofteambuilding;itshouldestablishaneffectivemechanismsforconflictmanagementduringtheshockphase,handletherelationconflictandtaskconflictintime;itshouldmakerulesandregulationsduringthephaseofregulationsettingup,trytomaketheobjectivedetailedandtrytomakethoserulesandregulationsoftandeptable;itshouldmakereasonableworkflow-designtoimprovethewholeteam’sproductivity. KEYWORDS：SoftwaretestingTeambuildingTeammotivation
2 目录 1绪论
1.2研究目的及意义.............................................................................................3
1.3研究内容与方法.............................................................................................4 2
案例正文
2.1.1O公司主要产品及市场状况...............................................................72.1.2O公司中国研究院简介.......................................................................72.1.3O公司软件测试团队介绍...................................................................7 2.2软件测试团队建设过程.................................................................................92.2.1BJSQE团队的成立阶段......................................................................92.2.2BJSQE团队的震荡阶段....................................................................102.2.3BJSQE团队的规范化阶段................................................................102.2.4BJSQE团队的高产阶段....................................................................11 2.3典型事件.......................................................................................................12
2.3.1总监的疑惑........................................................................................122.3.2小赵、大李、Tony的恩怨...............................................................132.3.3访问控制问题.......................................................................152.3.4老周的工作安排................................................................................16 3案例分析
3.1.1团队建设理论....................................................................................193.1.2团队激励理论....................................................................................213.1.3团队沟通理论....................................................................................223.1.4团队冲突理论....................................................................................23 3.2问题与原因分析...........................................................................................25
3.2.1团队成立期........................................................................................253.2.2团队震荡期........................................................................................263.2.3团队规范期........................................................................................27
1 3.2.4
团队高产期........................................................................................28 4
对策与建议..........................................................................................30 4.1团队成立期的全面沟通...............................................................................304.2团队震荡期的冲突管理...............................................................................314.3团队规范期的机制建设...............................................................................324.4团队高产期的流程设计...............................................................................33 5结论
2 图目录 图1我国软件产业2007年至2012年业务收入（单位：亿元）............................................1图2历届调查中公司的专职测试人员规模分布........................................................................2
图3论文框架................................................................................................................................5
图4O公司组织结构示意图......................................................................................................8
图5团队的类型..........................................................................................................................19
图6团队的有效性模型..............................................................................................................21
图7沟通的过程..........................................................................................................................23
3 1
绪论1.1研究背景 1984年9月中国软件行业协会成立，这标志着软件作为一个新兴产业成为我国经济生活中一个明确的组成部分，开始被单独作为一个学科和行业来进行研究和发展了。
在随后的20多年，我国软件产业历经萌芽阶段（1989——1991年）、起步阶段（1991——1994年）、兴起阶段（1994——1998年）、加快发展阶段（1998年以后），已初具规模。
2012年，我国软件产业共实现软件业务收入2.5万亿元，同比增长28.5%，我国软件产业总体继续保持稳定快速地发展，企业数量稳步增加，产业规模持续扩大，如图1所示： 图1我国软件产业2007年至2012年业务收入（单位：亿元）资料来源：工业信息化部 随着软件产业的发展，软件产品的质量控制与质量管理正逐渐成为软件企业生存与发展的核心。
几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。
软件测试工程师就是
1 这样的一个企业重头角色。
1中国软件测试网对比2007年到2011年的调研数据发现(如图2所示)，“无专职测试人 员”该项所占比例从2008年开始逐年降低，在这五次调查中，测试专职人员在1-10人的比例仍占据首位，但总体有下降趋势，尤其近3年来呈现逐年下降，2011年比2007年更是下降了9个百分点。
专职测试人员在50人以上的，07、08、09、10、11年的比例依次为25%、27%、28%、33%、35%，呈逐年上升趋势。
数据中反映的公司专职测试人员的不断增多，测试团队的不断壮大，是软件公司对软件测试越来越重视的有力证明，软件测试的重要性毋庸置疑
2。
图2历届调查中公司的专职测试人员规模分布资料来源： 1胡琨,刘浩,刘涛.初议软件测试[J].科技广场,2008,(05):241-242.22011年中国软件测试从业人员调查报告[EB/OL]./08/n-811608.html,2012-04-13.
2 测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试用例，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。
对软件测试工程师而言，必须具有高度的工作责任心和自信心。
任何严格的测试必须是一种实事求是的测试，因为它关系到一个产品的质量问题，而测试工程师则是产品出货前的把关人，所以，没有一定的专业技术水准是无法胜任这项工作的
1。
同时，由于测试工作一般由多个测试工程师共同完成，并且测试部门一般要与其他部门的人员进行较多的沟通，所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。
然而，我国的软件测试行业本身太年轻、起步较晚，与国际先进水平相比差距较大，例如：国内开发人员与测试人员的比例是8∶
1，而国际公认的行业标准实际上是1∶
1。
这就导致了国内软件测试人员工作压力大。
另外，国内软件公司管理能力低下，普遍落后于国外，并且大多数公司存在着发展瓶颈——国内超过500人规模的软件公司为数不多，而过千人的IT公司更是屈指可数了。
管理上不去导致规模上不去，规模上不去导致很多公司只能在意识上重视测试，没有能力在测试上进行实际的投入。
这必然导致软件测试人员待遇低，工作不热情，效率不高。
在传统的软件开发模型中，软件测试排在靠后的阶段，即在需求分析、概要分析、详细设计、软件编码之后，然后是软件的发布（在现代新的开发模型中，测试是贯穿于整个产品周期，从设计阶段就开始了）。
在整个开发过程中，软件测试人员是处于服务的角色。
软件测试对员工的吸引力不如程序开发那么强。
尤其是在O公司这样大型的、专业的、集软件与硬件开发于一体的公司中，来自其他部门的吸引力特别大，人员在部门间、甚至是公司间流动特别大；同时，软件测试工作绩效不容易衡量，激励方式不容易把握，常常还导致部门生产效率不高、员工热情不大、团队缺乏凝聚力的现象；另外，对于O公司这样一个跨国的大型公司，如何包容具有不同工作背景，不同文化习惯的员工也是一个不容忽视的问题。
如何构建一个高效、稳定、且具有一定的凝聚力、战斗力的队伍，对于软件测试经理来说是一个极大的挑战。
1.2研究目的及意义 软件测试管理的目标是实现软件质量、进度、成本之间的最佳平衡。
有效的测试管理需要企业管理层、软件开发团队、质量保证与测试团队通力合作，采用计划、组织、领导、控制等手段，组建高效团队，制定完善的测试流程，做好测试设计，有效执行测试，加强 1王刚,李迎,白祎花.软件测试人员应具备的素质[J].软件导刊,2011,(02):34-35.3 过程跟踪，从而顺利完成质量保证和测试任务。
软件测试是技术密集型活动，团队的知识结构、创造力和凝聚力是保证测试流程、测试技术充分实施的基础。
本文以软件测试经理的亲身经历，从组织行为学，团队建设理论、团队激励理论出发，以O公司的一个软件测试部门为例，理论联系实际，阐明在实际环境中，如何运用相关理论，进行软件测试团队的建设，增强团队的凝聚力，提高团队的工作绩效。
为相应理论提供鲜活的例子，丰富软件测试行业的管理经验。
在实践上，虽然本文以O公司这样一个跨国企业为例，探讨了软件测试团队建设的相关问题，但它同时也是软件测试行业的一个缩影，很多国内企业的测试团队也存在着与它类似的问题。
所以，本文虽然是有关O公司软件测试团队的案例研究，有其问题的特殊性，但我们应该看到这些案例所反映出的共性，反映出问题的普遍所在。
本文尝试着通过对O公司的一个软件测试团队在进行团队建设的不同阶段所遇到的不同障碍进行分析，从而为同类型的软件测试团队提供了解决问题的思路和对策。
1.3研究内容与方法 本文使用案例研究的方法，以O公司的一个软件测试团队的建立、震荡、发展的过程为主体，记录了该软件测试团队6年来的成长历程，以及在成长过程中出现的团队建设方面的主要问题。
选取了团队建设的不同成长阶段发生的典型事件，并围绕这些实践中出现的问题，有侧重地分析了O公司软件测试团队在团队建设过程中遇到的团队沟通、团队激励、团队冲突、工作流程细化等方面的主要问题。
总结了可为类似软件测试团队建设提供可借鉴的经验和教训，并就O公司软件测试团队的未来发展提出可供参考的思路和建议。
论文框架如图3所示
4 图3论文框架
5 2案例正文 2.1O公司概况 O是世界上第二大的企业软件公司，向遍及145个国家的用户提供数据库、工具和应用软件以及相关的咨询、培训和支持服务。
O公司总部设在美国加利福尼亚州的红木城，全球员工超过40,000名，是《财富全球500强》企业。
自1977年在全球率先推出关系型数据库以来，O公司已经在利用技术革命来改变现代商业模式中发挥关键作用。
O公司同时还是世界上唯一能够对客户关系管理―操作应用―平台设施进行全球电子商务解决方案实施的公司。
O公司1989年正式进入中国市场，成为第一家进入中国的世界软件巨头。
其首创的关系型数据库技术也从此开始服务于中国用户。
1991年7月，经过了近两年时间的努力开拓，为了更好地与迅速发展的业务相适应，O公司在北京建立独资公司——北京软件系统有限公司。
2009年4月，以74亿美金收购S公司，从此拥有S公司旗下的数万员工及著名的产品Java和Solaris操作系统。
S公司创建于1982年，1986年在美国成功上市，主要产品是工作站及服务器。
财富500强之
一，行业中被认为是最具创造性的企业之
一。
S公司不仅打败了包括IBM在内的全部工作站（WorkStation）和小型机（MiniComputer）公司，而且依靠它的Solaris（一种Unix）操作系统和风靡世界的Java程序语言，成为在操作系统上最有可能挑战微软的公司。
S公司不乏能人，它不仅为Google培养了CEO埃里克·施密特和首任工程部副总裁韦恩·罗森（WayneRosen），并且在一定程度上奠定了今天Google工程部门的基础。
但当互联网泡沫破碎时，它以服务器和工作站为主的硬件业务便急转直下，从硅谷最值钱的公司沦为人均市值最低的公司。
如今，O公司的业务已几近覆盖中国所有的省、自治区与直辖市——在中国建立了14个分支机构、4个研发中心、拥有超过2.5万个客户、1500个合作伙伴和4500名员工。
在支持创新和开放标准方面，O公司的表现更加无与伦比，其中，O公司的在线开发者社区——O公司技术网(OTN)在全球拥有1400万名成员，包括25万名中国成员，为中国本土企业和机构提供了强有力的支持。
在中国推行“十二五”规划之际，O公司致力于利用创新性技术为客户、合作伙伴和社区提供发展动力，为中国的可持续性发展贡献自己的力量。
主要集中在三个方面：加速信息技术的应用；通过创新性技术支持企业转型；培养本地技术人才。
6 2.1.1O公司主要产品及市场状况 在结束不久的2012年财年，O公司取得了很好的业绩：GAAP总收入增长4%，达到371亿美元；营业利润增长17%，达到137亿美元，利润率达到37%；净收入增长27%的历史最高水平。
O公司自始至终都在做一件事，那就是围绕着新兴技术领域，如：云计算、社交、大数据与移动应用进行并购与产品的推陈出新。
O公司产品主要有以下四类：
（1）数据库：O公司数据库、实时应用集群、数据仓库、MySQL、Timesten内存库等。
（2）中间件：数据集成、业务分析、SOA、WebCenter、WebLogic等。
（3）管理软件：人力资本管理、客户关系管理、企业绩效管理、财务管理、采购管理等。
（4）集成服务器：大数据机、ExaData云管理服务器、Exalogic中间件云服务器等。
这四大产品线几乎涵盖了企业云应用所有组件，可以提供服务器、存储，在这之上O公司自己的虚拟化技术和VM直接竞争；有数据库、有中间件，O公司重写了ERP和CRM以后，能够做到支持云的设计。
O公司提供云所需要的一条完整产品线。
在企业管理环境中，很多公司都可以提供建设云的一部分，但是没有哪一个公司可以像O公司一样完整，从数据库、软件、硬件、安全到ERP全部的一揽子提供。
如O公司全球总裁马克赫德所言，O公司目前没有竞争对手，原因是公司拥有最全面的产品线，拥有包括SAAS、PAAS和IAAS在内的三个层次的云服务，能够为客户提供最全套的解决方案，这是其他竞争对手不具备的。
2.1.2O公司中国研究院简介 O公司的软件研发、设计、维护都由软件研究院负责完成。
OARDC(O公司AsiaResearchandDevelopmentCenter,)是O公司在海外建立的三家研发机构之
一，包括2002年在深圳，2003年在北京及2007年在上海成立的三家研发中心，同时，在新加坡、印度、韩国、澳大利亚、日本等地还有分部门。
在中国主要从事社会网络、嵌入式技术、虚拟技术、空间技术、普适计算、电子商务等方面的O公司产品开发及维护、应用开发及原型系统设计工作。
同时为中国及亚太地区合作伙伴提供专家及技术支持。
2.1.3O公司软件测试团队介绍 O公司的各个产品线都有自己独立的软件测试队伍。
本文讨论的是O公司旗下的SystemGroup（原S公司的）X86软件测试团队。
在2006年，该团队在北京组建，由美国总部的Julie领导，总监是Lisa，成员最多时达到18人。
其中骨干成员是从其它部门抽调过来的，加上对外招聘的人员、应届毕业生及实习生组成。
所以成员的背景、经历有很大的不同（组织结构如图4所示）。
7 图4O公司组织结构示意图 这个软件测试团队主要负责O公司的X86服务器的系统集成测试。
O公司的X86服务器主要是指基于AMD和IntelCPU的服务器，分为机架安装式、桌面式和刀片式，是X86体系架构；SystemGroup的其它部门主要是处理Solaris操作系统和SPARC体系架构的专用服务器。
系统集成测试主要包括X86的部分Firmware测试，如BIOS/UEFI、ILOM的升级测试、板载I/O测试、外插卡I/O测试、外插卡驱动测试、外插卡的组合测试、系统压力测试、部件（如内存条，CPU，硬盘）的测试等。
还有不同操作系统的如Redhat，Windows，VMware，Solaris等Cert（认证）测试等。
每当一个AMD或者是Intel新的CPU型号发布，O公司要推出相应的主机服务器时、或者老的型号的服务器需要推出更新版本时，都要经过该系统集成测试，合格后才能发布供全球客户使用。
所以，这个团队常常是任务紧，工作量很大，相当辛苦。
而且要求测试人员知识面广，不仅要求懂得计算机硬件体系结构，还要懂BIOS/UEFI层面的知识，不仅要求对操作系统的深入了解，还要会编程，经常要改些测试脚本程序等。
可以说，系统测试人员几乎是计算机的全面手。
团队建立之初，队员由美国同事培训，学习并接收项目。
开始是做一个平台的Sustaining维护工作，后来先后接收了40多个平台，工作成绩让美国同事大为赞许。
现在北京和上海的团队一起成为O公司X86架构在美国东部、西部开发中心之后的第三个中心。
已经与美国的中心并列，独立承担新产品的研发测试任务。
8 2.2软件测试团队建设过程 本文中的O公司软件测试团队的建立过程是比较典型的美资大型跨国企业在中国建立团队的过程。
因为美资大型跨国企业大多数比较成熟，在很多国家都建立有不同的团队，经验相对丰富。
大多数情况下，在工作流程上，往往照搬其总部模式，而在日常管理上则由团队领导者结合本地规章进行管理。
但是，团队建设毕竟是与人相关的活动，其在不同的环境下，面临不同的人群，必然有着不同的矛盾、冲突，随之相应的就是要有不同处理方法、步骤和流程，这导致本地团队领导者在团队建设的不同阶段会面临不同的障碍，要运用不同的方法，手段进行处理，必要时还会在工作流程上加以变革。
软件测试团队，它是一种固定工作团队，因其是IT行业，人员素质高，有其特殊性。
本文尝试着以团队建设过程中的不同阶段为视角，对所遇到的不同障碍进行分析和解决，从而建设一个高效的团队。
事实上，在团队建设的不同阶段，“高效”的标准不尽相同，本文以最终是否会影响到整个团队的预期目标/项目为标准来选择相应的矛盾加以分析，而不是局限于各个阶段内。
这里“高效的团队”是指（相对与公司其他同样性质、处理同样工作的团队）在相同的时间内、在保证质量的前提下，能够处理和完成更多项目的团队。
下面先简单回顾一下O公司软件测试团队（BJSQE团队）的建设历程。
2.2.1BJSQE团队的成立阶段 2006年5月，Lisa和Julie在中国S公司研究院成立了X86研发部，负责S公司已推出的X86各型号服务器的升级与测试工作。
该研发部由北京和上海两部分组成。
计算机硬件相关的开发、测试放在上海，软件测试部分放在北京，我们称之为BJSQE团队 Lisa和Julie从北京S公司研究院的Solaris部门选调了大李、小唐、Pete，新招了小赵、小张等5人组成了北京测试团队的第一批成员。
大李97年哈尔滨理工大学毕业，在联想、富士通等公司的计算机研发部门工作过，在S公司的Solaris开发部门也工作了3、4年，经验比较丰富，是作为技术主管吸收进来的，性格豪爽，典型的东北人性格，是IT行业里不多见的女强人。
小唐99年浙江大学计算机系毕业，在IBM工作几年后加入S公司研究院的Solaris部门，做开发已经有2年了，工作经验也很丰富，是资深工程师。
小赵，大连理工计算机系硕士应届毕业生。
Pete是清华大学的，在IBM工作过一段时间，在Solaris部门作项目经理3年了，调过来准备作为这个新成立部门的部门经理。
小张是大学刚毕业的实习生。
这个软件测试团队成员确定后，Julie把Pete、小唐、大李派到美国X86服务器研发总部--加州的门洛帕克去接受培训。
按Lisa的计划，准备让北京的团队首先接手S公司G12X平台的测试任务。
但是她始终不能确定，北京这个新团队到底能不能顺利接下并完成这个任务。
G12X是以AMD皓龙2核处理器为CPU的两款机架式服务器，分别是1U的G1X
9 和2U的G2X，内存16GB、4个千兆网口的低端服务器。
大李、小唐在美国进行2个月的培训，学习了如何建立测试环境、如何修改、调整测试用例、如何运行测试及生成测试报告等。
Pete负责北京的总体安排，包括实验室的建立、人员、工作进度的安排等。
在团队建立之初，交流的不顺畅导致实验室及测试环境的构建没有按期完成。
典型事件一的“总监的疑惑”详细地描述了该情况。
延期2个月后，Pete在得到Julie的帮助后，终于完成实验室的构建。
Lisa亲自到北京进行实地视察。
在考察了新建的实验室后，Lisa让大李与小唐现场演示如何进行测试，大李与小唐按照培训的方式认真地完成一轮测试并将详细的测试报告发给Julie和Lisa审阅。
2006年12月11日，经Lisa批准，北京软件测试团队正式开始从美国同事那里接手G12X的测试任务，这宣告X86北京测试团队终于度过了成立阶段。
2.2.2BJSQE团队的震荡阶段 在开始G12X的测试时，团队其实进入了震荡阶段，先后出现了小赵与大李之间的矛盾及北京与上海团队之间的冲突。
典型事件二“小赵、大李、Tony的恩怨”详细地描述了这些矛盾和冲突。
小赵与大李的矛盾已经影响到了项目的顺利完成。
若再不能及时解决这些问题，冲突加剧，矛盾加深就会极大地影响整个团队的绩效。
Pete通过安抚人心、与其他部门及时沟通，终于渡过了这一危机重重的阶段。
2.2.3BJSQE团队的规范化阶段 当时的系统集成测试主要内容有两大块，操作系统的On-board测试和OptionCard测试。
操作系统的On-board测试是针对主流操作系统Window、Solaris、RedhatLinnx、SuseLinnx、VMware等进行CPU、内存、硬盘、网络的性能和压力测试。
Option卡测试又分两类，一类是针对存储卡的，另一类是针对网卡的。
这两种测试都要进卡的驱动测试，压力测试、性能测试以及对这两种卡在主机的不同扩展槽上的各种组合测试。
对于4U的服务器，我们的主机通常有6-8个扩展槽，主机支持的网卡有10种、存贮卡有7-8种，各种组合汇总后是一个非常大的表格。
我们的测试要覆盖重要的、典型的组合，这时测试用例的设计与选取是非常重要的，它完全依赖于测试人员的知识和经验。
顺利完成G12X的1.3版本和1.4版本后，其测试发现的Bug，测试的速度得到美国总部的认可和好评，于是新的项目F12F、G4E、G4F先后从美国转移到中国，由中国北京团队进行测试工作。
随着项目即主机平台的增加，测试的内容也在增加。
除了前面说的两大块即操作系统的On-board测试和OptionCard测试，后来又增加操作系统的认证测试、部件Qual、随服务器出厂的光盘Image制作与测试，这个光盘能帮助客户安装操作系统，并提供必须的驱动程序，还可以做基本的系统诊断等。
原来的5个人已经远远不够了。
这时Pete从其它研 10 发部门请来了Feng、老周等资深工程师，又从外部招来小李、老韩、老付等，还从加拿大招了一个海归Mike。
团队成员增多了，团队的生产力是有所提高，但是没有带来与增加的人数相对应的生产力的提高。
刨除新进入员工在年龄、工作经验上与老员工的差异因素的影响，生产力的提高程度还是与期望值相差较远。
什么原因呢？Pete发现有些同事上班时花了很多时间流连忘返在外网上，这势必影响到项目的进展，怎么办呢？Pete采取一系列的措施，终于让团队成员将精力集中在工作项目相关的事情上了，对此，典型事件三“访问控制问题”进行了详细的介绍。
2.2.4BJSQE团队的高产阶段 大家上班都认认真真地工作了，但是人手的增加还是远远赶不上项目和工作量的增加，如何解决这个问题?
Pete又采用了如下三个方面的措施。
首先，Pete提高团队自身的工作效率，量化工作任务、工作时间。
将每一个Test用例的准备时间、运行时间全都量化，每个项目的测试计划定下来后，相应的测试用例也随之定下来，那么测试的设备、环境、时间基本也就确定下来，加上一定比例的富余量，如无意外情况发生，那么测试的完成时间也就随之定下来，这个时间里有测试用例的运行时间、有测试工程师的交互时间，如果测试交互时间不满，就会再增加其它任务，即工程师要同时处理几个测试任务，极大地提高了工程师的工作效率，从而提高了整个团队的工作效率。
其次，Pete对美国的测试工作模式进行更改：优化测试计划，将OS的部分测试合并到Optioncard测试中，将二者有机结合起来而不是完全隔离开来，这样就避免了二者相同部分的测试，减少了重复；同样地，将部件Qual的测试也融合在常规的测试周期中，不必像美国同事那样单独为部件Qual运行测试。
从而大大提高了北京团队的整体效能。
再次，将美国简单地按平台划分测试人员的方式进行调整，美国是一个平台4-5人固定不变，北京是同类平台全都由一组人员来测试。
比如在美国，G12X是一组人在测试，G12F可能是另外一组人。
北京则是G12X、G12F，只要是1U和2U的服务器都是一组人负责测试。
这样，工程师可以借鉴相关平台的测试经验，不但增加了工程师测试的熟练程度、还增加了并行性，极大地提高了团队的工作效率。
同样的平台项目，美国一组工程师只做一个，而北京团队可以接手两到三个，其高效率让美国X86总部很欣赏，逐渐地把美国东部和西部的测试任务都挪到了北京。
2007年12月北京团队开始接手刀片式服务器的相关工作，2008年开始接手存贮服务器的测试任务。
到目前为止，北京团队先后接手完成了44平台服务器的测试任务。
仍在运行的有9个平台。
事实上，在高产的同时，如何能在质量上更上一层楼的问题接踵而来，典型事件四“老周的工作安排”就是典型的解决方案之
一。
11 2.3典型事件 2.3.1总监的疑惑 明媚的阳光并没有给Pete带来好的心情，X86SQEteam的成员也是这样。
Pete是X86SQE的经理，这个部门从4月成立到现在已经有6个月了，骨干大李，小唐经过2个月美国培训回来有一段时间了，测试的流程、步骤都已经非常清楚了，但实验室却还没有建立起来。
让大家高昂的工作热情无处发挥。
这到底是真么回事呢？Pete一遍一遍地问自己。
Pete是从Solaristeam调过来的，作项目管理有几年了。
来O公司前还在IBM干过一段时间，但对面前的情况也是一筹莫展。
建设实验室所必须的设备清单已经提上去了，购买测试样机的内部PO也已经提交了，可是迟迟没有得到总监的批复。
Pete仔细地把清单还有PO看了一遍又一遍，没有什么问题啊。
清单上的部件都是实验室必须的，有网线，交换机，电源插座等等，购买测试机的PO包括服务器的配置清单，进出口的费用，有清关费，运输费，代理服务费等等。
如果再得不到批复，实验室不能如期建好，被测服务器不能及时进口到中国，原定的项目计划就要泡汤了。
无奈之下，Pete给他的顶头上司—资深经理Julie发了邮件，请求帮助推进总监的批复进程。
Julie是Pete是上司，常驻美国，是Lisa的老部下，彼此非常熟悉。
Pete是她和Lisa总监的新部下。
当Julie从Pete处了解了事情的详细情况后，向总监Lisa发去了询问的邮件。
总监Lisa也很郁闷，她对在北京研究院新招的这个项目经理已经不太信任了。
在前一段时间，她发信让Pete回答两个问题，结果Pete回信谈了一大堆别的事情就是没回答她想要的那两个问题。
还有一次，Pete发信给Lisa希望她批准Maggie（Lisa的助理）帮他下一个PO，邮件的写法有问题导致Lisa以为他让Lisa去批准一个已经生成的PO。
Lisa特地进入订单系统查询了好几遍，也没看见有新的PO需要批复。
后来还是Maggie助理了解情况后告诉Lisa事件的原委。
这些导致Lisa总监对于来自Pete的请求总是抱有怀疑的心态。
这不，当她前几天又收到Pete的实验室采购清单及被测机购买清单时，就很不确定该不该批准了。
看到老部下Julie询问的邮件，Lisa就把自己的疑惑全都说了出来，首先在美国像网线、交换机、电源插线板都由后勤部门提供，为什么Pete要提出购买那些配件。
另外，关于购买被测机的PO，为什么里面要包含运输费、代理费、清关费等一大笔费用，这在美国闻所未闻，能否麻烦Julie先了解清楚。
Julie立刻与中国研究院的后勤部门取得联系，得到确认，这些东西的确要由实验室的使用者去准备，然后又与负责中国订单的部门取得联系，确认这些费用是必须的，是因为中国的海关规定与美国有所不同才导致Lisa总监在美国进行类似业务时不会涉及那些费 12 用。
当读完Julie转发过来的各相关部门的详细说明，Lisa终于明白了其中的来龙去脉。
于是在财务系统里批准Pete的那两笔费用申请。
收到已批复的系统提示信息，Pete和同伴们终于一扫几日的阴霾高兴起来，实验室的设置工作又可以继续开展下去了。
新项目不日即可开始了，但Pete心里的疑问却没有消除，PO为什么这么久没有批呢？总监不信任我们吗？Lisa心里也有疑问，Pete为什么不在系统的申请里详细标注或说明呢？Pete的交流成问题。
Pete的同事也有疑问，这到底是怎么回事呢，实验室为什么拖了这么久？ 2.3.2小赵、大李、Tony的恩怨 小赵坐在电脑前很生气，盯着屏幕上漂亮的屏保画面，脑子浮现的却是这两天的不顺心的事。
首先是其主管大李对她的态度最近让她很不愉快。
小赵是去年来的硕士毕业生，通过层层选拔、过关斩将进入她仰慕已久的IT界著名的S公司。
她基础知识扎实，本人也勤奋努力好学，在其主管大李的精心带领下很快就适应了O公司的环境，不久就能独立完成一些基本的测试任务。
再后来自己还可以在主管的帮助下完成一些测试脚本的修改。
她的主管大李是从其他部门调过来的，是部门的元老，名牌大学毕业生，先后在几家著名的IT公司里工作过，是一名经验丰富、工作能力强的女技术强人，性格也很豪爽火爆。
小赵感觉到大李不像以前那么耐心了、不热情了，有点摆架子。
另一件让她不高兴的是上海OSBringupTeam的Tony。
Tony是OSBringUpTeam负责解决北京团队发现的Bug。
小赵觉得Tony老是为难她，写Email不回、打电话不接、更新Bug记录也不及时。
她盯着屏幕良久，思考着她该如何办。
大李近来也不太顺心，一个是最近上海OSBringupTeam新来的Tony对北京发的Bug响应不及时，两人为此还在Email里吵得不可开交。
另一个是小赵最近越来越不把她这个主管放在眼里，呼来换去，远不是刚来公司报到时那个乖巧听话的小姑娘了。
尤其是到美国出差去接项目时，本应由她这个主管出面联系的一些项目，小赵竟也不先打一声招呼就擅自主张地应承下来，让她感到很被动。
是时候给这个小丫头一些教训了，但是Tony这个事情比较棘手，每次发的Bug他老是让我们做这做那，自己什么也不做，该自己收集的数据也要让我们来收集，太过分了。
其实上海的Tony那边也在不断的抱怨，说北京这边的测试人员提供的数据不完善，让他无从下手。
Tony是一个很有经验的软件开发人员，在来O公司前已经工作很久了，比较挑剔，要求较严格，有任何不清楚的问题都会小题大做地叫嚷一番，但在这件事上他似乎也是有道理的。
问题到底出在哪儿？如何解决呢？ 大李是项目主管，她带领小赵和小李负责O公司4U服务器的系统测试。
原定2个月完成的测试任务结果却没能及时完成。
大李负责制定测试计划、选择测试用例，小赵和小李负责测试的运行和结果分析。
自从大李和小赵出现矛盾后，他们小组的工作效率有些下 13 降，在版本1.6的测试过程中出现了没能及时完成测试的情况，这在以前从未发生过。
至于北京和上海OSBringUp之间的关系，的确有些问题。
不光大李这个项目，另一个2u服务器项目的同事也抱怨类似的情况。
BringUp工程师随意关闭北京小组发的Bug，不自己收集数据，甚至全推给北京小组来收集。
以上这些情况Pete看在眼里，急在心上，如何化解呢？ Pete经过观察和分析，发现了小赵和大李变化的缘由。
自小赵毕业后招到X86部门后，本人很努力、很勤奋，加上大李的认真带领和指导，很快就能胜任基本的测试工作。
Pete又让小赵同大李一道去美国培训学习O公司的新产品、了解研发情况、接收新项目4U服务器到中国进行测试工作。
小赵任务完成的很出色，受到Pete的表扬，同时小赵也完成Pete额外分配的Testcase的升级和迁移，自信心大增，就有点飘飘然了，有些事竟没有请示主管就下意识的自己就做了，因为她认为自己可以胜任，有信心。
大李是一如既往地认认真真地完成自己的工作，但眼中揉不得沙子，看不惯小赵身上的变化，于是在自己的行为和态度上就流露出来。
经过对双方深入的了解，Pete认为这事要向双方挑明，把问题说开。
于是他在一天下班之前约上大李和小赵到公司楼下的咖啡厅喝咖啡。
在柔和的灯光下，伴随着舒缓的音乐，Pete首先与小赵，大李一道回顾了团队组建后的工作安排、工作成绩。
小赵对大李给予的指导和帮助表示深深地感谢。
当提到大李感到不悦的事情时，小赵很是惊讶自己的行为会让大李感受到了伤害，诚恳地为自己欠考虑的行为向大李道歉，大李欣然接受了，二人从此和好如初。
小赵不断地成长进步，大李一如既往的认真工作，后来由于又有了新的项目，Pete把小赵调到新的项目组里，大李还有些不舍呢。
关于与上海的冲突，这个问题较为复杂，里面既有工作流程上问题，也有个人关系的问题。
Pete认为应该先仔细研究工作流程上的问题出在哪儿。
在软件行业中，关于Bug管理一般都会对在发Bug时的情况作出规定，如要求Bug要有的详细的错误信息，详细地重现步骤，错误的严重等级，产品相关属性等。
但对于由谁重现Bug，如何分析及解决Bug的定义较为宽松。
这就留有很大空间让软件开发或维护人员发挥自己的长处。
至于关闭Bug，一般会要求有验证即可。
到底是谁来关闭，并不介意。
这些宽松的规则和要求，如果大家本着相互体谅的原则，不会有问题，但对于过于较真，认死理的人来说，就造成了北京和上海Tony的问题。
当然这与Tony的个人性格是有一定的关系的。
针对这样的状况，Pete决定先解决流程问题。
Pete与Tony的经理Jack进行了电话沟通，他们一致认为先对事不对人，先找出流程上的原因和解决方案后，再看是否需要分析人员的问题。
事实上，Jack经理也对前段时间出现的与北京的合作出现状况有所了解，也正想着如何解决。
当Pete打来电话，商量此事时，立刻积极响应。
二人仔细讨论后，决定对当前Bug处理流程里没有详细规定的部分进行细化。
首先，Bug的重现须由接受Bug的工程师来完成，除非缺少相关的必要设备时，由Jack经理发帮助申请给Pete，这杜绝了Bugfix工程师寻求软件测试工程师重现的随意性。
这也是让北京Pete团队深恶痛绝的。
14 当然，也会考虑到上海的诉求。
其次，规定当北京团队在系统里发了Bug后，发邮件通知上海team并保留现场两小时，给上海同事一个机会前来查看，以节省上海进行重现问题的时间。
但只有两小时，过时不候。
因为测试还要继续其他的工作。
在关闭Bug的流程上也做了补充。
原则上谁发的Bug就由他验证后关闭。
Bug软件开发人员不能随意关闭别人的Bug。
对于开发人员认为不是真正的Bug（有些是功能未实现，需要添加的新特性）时，由软件开发人员在Bug里注明后关闭。
流程细化后，北京上海的争执现象锐减。
偶尔还会听到Tony的抱怨，那是个别的现象了。
2.3.3访问控制问题 IT公司里，有的允许员工上班时可以上外网（），有的控制比较严，不允许员工随意访问。
在这一点上，无论O公司还是S公司（都是美国公司），都不对员工访问外网加以强制限制，在公司的员工手册上说员工可以偶尔使用公司的资源访问。
但是什么是偶尔，何时可以访问都没有明确说明。
在防火墙上也没有做任何限制设置。
这种模糊的表述让很多员工上班时肆无忌惮、无节制地在网上冲浪，QQ、MSN一直都在线，导致本职工作受到影响，从而影响了团队的绩效。
怎么办才能提高团队整体绩效，对员工有所约束又不损伤员工的自由呢？ Pete观察到员工的测试工作虽然安排得很满，但在测试运行过程中，还是有一点空余时间。
员工往往利用这些时间上网、聊天、购物、看新闻，个别的还上网读小说、玩游戏。
对此，Pete没有一刀切，他首先与各位主管协商、达成一致，即要求大家只在午休时间上网，进行必要的、短时访问；严禁读小说、玩游戏；查询与项目相关的资料则不受限制。
然后，他召开团队会议，当众宣布这条纪律。
员工无节制地上网现象少了，至少是当着Pete的面比较少了。
Pete能感觉到员工有抵触情绪，而且，员工的确还是有多余的时间没有利用起来，如何根本上解决这个问题呢？ Pete与每个员工进行单独面对面谈话（公司里常常称之为1:1），讨论每个人的兴趣、爱好和其职业的发展规划，然后给他们安排两种任务，一种是明确的、项目上的、有强制完成时间的工作任务，称之为前台任务；另一种是一个较长期的、是与本人职业发展及兴趣相关的、也与团队的项目发展相关的任务，称之为后台任务。
员工可以根据其前台工作任务的情况给出其后台任务一个大致的进度计划和安排。
Pete每2周或每3周与员工就其后台任务的进度进行小结，并在整体大会上进行公开陈述。
例如，小王对Linux内核很感兴趣，Pete就让他把与其相关的驱动的编译与调优测试作为前台任务，然后让其把跟进Linux内核的版本变化作为后台任务，定期向大家通报和讲解最新内核社区的变化，小王乐此不疲。
因为这后台任务是员工自己的兴趣所在，员工自己有很高的热情与积极性，同时，团队的工作也需要相关的知识，员工将最近的学习心得或研究体会在大会上公开展示 15 出来，一方面提高了团队整体的相关方面的知识水平，也给该成员提供了一个展示其才华的机会，让其更加自信，更加被团队认可，如此一来，团队成员除了偶尔短时上网以外，很少出现长时间在网上漫无目的地乱逛了。
因为此时，员工从内心里珍惜这些空余时间，这不仅是公司的工作时间，也是充实自己、自我成长的时间，是不能随便浪费的。
除此之外，Pete还采取如下措施从制度层面进行强化，从而形成了团队上班时间大家都认真工作，无暇做无关事情的风气。
1.要求每个团队成员每周在指定的网络服务器上（Twiki）写工作报告，详细、具体地列出本周完成的工作内容，下周的工作安排等，因为是Twiki方式，所有成员的报告，大家都可见，历史记录都可查。
主管以身作则，给普通员工带一个好头。
2.要求每个成员都做好测试记录，随时进度可查。
3.每周召开项目主管进度协调会，会上将与各主管同步各个平台的测试进度，协调各平台之间的设备、环境等资源。
4.每周召开全体人员会议，会上同事共同交流测试的具体情况及项目的进展情况。
5.与每个成员每两周进行一次单独地、面对面地沟通（1:1），了解项目情况及员工本身状况，例如其遇到的问题，无论是工作的、家庭、情绪上的等等。
6.每个平台的版本发布后，要开分析会，总结分析在测试中遇到的问题，从测试环境、测试用例、测试流程上进行分析，为什么会遗漏一些问题没测出来等，对测试用例查漏补缺。
促成团队形成一个风气，就是大家把任务领回来后，要按时保质完成。
这些步骤是促进和保障大家按时完成任务的一种方式。
此外，Pete还鼓励员工开发新的测试用例，并给予及时的认可，如颁发及时奖励（SpotAward），或让其在团体大会上做讲解，并将生成的用例进行全方面推广。
很多成员如小赵、小李，小张等就曾提交Linpack、TAC、FCoE、iSCSI等的测试用例，不仅在本部门推广，还推广到美国东部和西部的测试部门，这让员工有极大的成就感、满足感。
大家把空余时间都利用起来了，就没时间去上闲逛了。
2.3.4老周的工作安排 老周是团队里骨干、主管，每天他都是第一个到办公室，打开计算机先浏览重要的邮件，然后准备一天的测试安排，这已是他多年的工作习惯。
老周是典型的70后，是团队里最年长的，先后在IBM、HP公司里任职多年，工作经验非常丰富。
老周当初是O公司另一个部门负责应用测试的，与X86的系统集成测试有些差别，但老周调过来后很投入，加上功底好技术全面，很快就上手了，毕竟软件测试方法上是相通的。
老周来本部门之前就已经是高级工程师，调入后，在主管老韩负责的组里工作，将老韩安排的工作完成的井井有条。
老韩没有老周年龄大，对老周也很客气，这种状况持续了有一年多，如何能发挥老周自身的优势给团队做出更大的贡献呢？ Pete仔细梳理了一下团队的工作内容发现操作系统的Cert（认证）测试工作目前没有固定人员去做，是由各个平台的测试人员随机去做，轮到谁手上的任务完成了，正好需要 16 时就去做一次。
这造成测试数据零散，测试日志存放混乱，查询起来很困难。
另外，因为不是专门的工程师做，临时抽的工程师流程上不熟悉，每次都要花费时间去查阅最新的规则、搭建自己的测试环境，费时费力，效率低下，完成一个版本的操作系统的Cert测试，前前后后需要一到二周的时间。
操作系统的Cert测试在两种情况下需要测试人员去做。
一种是平台的固件如BIOS和伺服务统ILOM由于版本更新时，原已经测试过的各种OS操作系统，如Redhat、Suse、Solaris、Window、VMware等就会需要重新进行测试，然后提交测试报告给相应的公司审查，合格后，新版的固件信息就会在OS列表里公示出来。
另外一种情况是当操作系统有了新的版本推出时，就要在相应的平台上安装新推出的操作系统，进行测试，然后将结果提交相应的公司审查，符合条件后，相应的平台信息便可在其OS的兼容列表中公示出来。
无论哪种情况，OS的Cert结果对O公司的服务器产品的客户或潜在的客户都有重要的作用和影响。
客户可以通过OS公司公示的结果选购O公司的服务器，当遇到问题时，可据此要求OS公司给予技术上的支持服务，因为这款机型是在应该支持的列表中。
进行Cert测试需要对操作系统比较熟悉；需要频繁与外界进行交流沟通，如与操作系统的公司支持人员就操作系统本身的新特性、参数、测试流程的更新等进行交流。
系统管理正好是老周的强项，于是Pete找到老周，表达了希望由老周专门负责所有操作系统的Cert测试工作的想法。
老周有些犹豫，首先是因为工作量，所有操作系统的Cert测试工作量不小，即使一切顺利的情况下，一个工程师在一个测试周期里都恐怕难以完成。
如果出点意外情况，就更没法保证按时完成了。
其次，这还要求对所有主流的操作系统都要熟悉才行。
Linux他没有问题，但是，还有Window、Solaris和VMware。
考虑到Linux与VMware比较接近，于是老周答应接下所有Linux和VMware的Cert测试。
其他的操作系统，老周还需要帮手。
Pete重新评估了Cert测试的工作量，经过比对历史记录，认为老周说得有道理，一个人在一个测试周期内很难全部完成所有操作系统的测试任务。
至少还需要一个工程师才可以，那么再找个什么人配合老周呢。
考虑到前文提到的小赵，在一个项目上工作的很久了，可以调换个新岗位给她，让她有新的挑战。
于是Pete征求了小赵的意见。
Cert测试对小赵来说，并不陌生，但是专门负责并进行深入研究小赵没做过。
想到O公司的服务器经过她的测试就能出现在第三方公司的网站上，就能让客户或潜在的客户作为使用或购机参考，小赵感到有些激动，很愿意去尝试一下。
于是，Pete安排由老周带领小赵负责全部操作系统的Cert测试工作，包括协调进度、整理数据、日志、对外联络等。
目标是让这些测试数据有序、可查，并尽可能低地缩短每个操作系统的Cert时间。
这样，老周和小赵就从原来的项目上抽调出来。
他们怀着极大的热情投入到Cert的测试工作中。
首先，他们按照操作系统种类分工，安装、设置好各种OS的Cert测试环境并始终保 17 持环境处于最新、稳定的状态，从而减少了每次进行Cert测试的准备时间。
其次，积极与厂家沟通交流，时时与厂家的最新标准、流程同步。
然后，他们还开动脑筋，设计并维护一个时时更新的Cert测试列表，放在北京团队的Web主页上。
里面包含了何时、在何种配置的服务器上对何种版本的操作系统完成了何种Cert测试，相应的测试日志文件存放在哪儿、何时提交等等。
有关Cert的所有信息，在列表上都一目了然。
很快，老周和小赵的工作成果就展现出来。
首先，各平台的主管不用再操心操作系统的Cert测试了，他们只需要与老周协调好OScert的时间安排然后就交由老周，老周便把余下的事情全做了，平台的主管只需等待结果就行了。
这样算下来，除了Window的Cert需要一周外，老周他们平均2到3天便完成一个操作系统的Cert任务，效率大增。
其次，美国的市场部的同事对老周他们维护的Web网页上的操作系统Cert列表赞不绝口，以往他们要发许多的Email都不一定能拿到准确数据，现在随时就可以从列表上得到了，他们的效率也大大地提高了。
18 3案例分析 3.1理论基础 3.1.1团队建设理论 团队理论起源于二十世纪六十年代。
20世纪90年代，经营环境的复杂多变使组织的反应速度成为决定企业经营成败的关键，强调员工合作的哲学使团队逐渐成为较为流行的组织形式。
在组织行为领域，美国著名的学者斯蒂芬•P•罗宾斯认为，“团队是由为了实现既定目标而相互协作的个体所组成的一种正式群体，与一般的群体不同，团队通过成员之间的积极协同作用，使团队整体的绩效远远大于团队成员个体绩效的总和”
1。
实际上，人们对团队的观点是有些微小差异的，有的学者强调对每个成员知识技能的合理利用，也有学者强调团队成员的行为之间相互依存、相互影响，并追求集体的成功。
在管理科学和管理实践上，人们共同的看法是：团队是一个组织在特定的可操作范围内，为实现特定目标而建立的相互合作、一致努力的由若干成员组成的共同体。
不同的学者从不同的角度和标准对团队类型进行了划分，斯蒂芬•P•罗宾斯（StephenP.Robbins）把团队分成四种类型，即：问题解决型团队、自我管理型团队、跨职能型团队、虚拟型团队。
如图5所示： 图5团队的类型资料来源：StephenP.Robbins组织行为学15th 近年来被西方普遍应用的还有Suan和Diane对团队的研究成果，把团队划分成四种 1赵海霞.团队薪酬体系对团队绩效的作用机制研究[D].华中科技大学,2012.19 类型:工作团队(workteam)、并行团队(parallelteam)、项目团队(projectteam)和管理团队(managementteam)。
从团队的创建和发展过程角度，一般可以分为成立、震荡、规范化、高产和调整五个阶段。
在团队的成立阶段，要有团队创建人，完成一系列的准备工作，如团队规划、定位、目标等。
要得到上层领导的支持。
这一阶段结束时，团队每个成员都应该清楚本团队能达到的组织愿景；团队经过成立阶段后，就进入了震荡阶段。
在这个阶段成员们彼此的性格特征和行为风格的差异会逐渐暴露出来，冲突也不断产生。
团队管理者要认识并处理冲突，积极进行有效的沟通，帮助成员顺利度过震荡阶段；团队经过震荡阶段，开始走向稳定和成熟，沟通之门打开，相互信任加强，成员的人际关系由分散、矛盾逐渐走向凝聚、合作，开始建立工作规范和流程；在高产阶段，团队成员之间已经非常默契，能够及时、准确、高效地接受和完成各项任务。
这时的团队就真正成为了团结合作的集体；随着工作任务的完成，很多团队会进入调整阶段。
大部分任务型团队会解散，有的会继续工作，或许会发展新成员。
团队的效果通常包含团队生产率的客观指标、管理者对团队绩效的评估以及成员满意度的累积结果三个方面的含义。
有效影响建设高效团队的因素有四大类。
第一类是影响团队有效性资源以及其他外在条件；第二类与团队构成有关；第三类是工作设计；最后一类是过程变量，它表明团队中运作的一些事情会影响到团队的有效性。
斯蒂芬•P•罗宾斯（StephenP.Robbins）把这些因素简化成一个相对集中的模型，如图6所示。
20 图6团队的有效性模型 来源：斯蒂芬•P•罗宾斯《组织行为学》第12版 本案例研究主要是围绕着软件测试团队建设在不同阶段的主要障碍，结合团队有效型模型，分析团队领导者在使用解决方法、措施时的绩效表现和理论依据，寻求更好的方法提高团队的绩效。
3.1.2团队激励理论 激励即激发和鼓励，是指激发人的动机，鼓励人们从事某种活动而采取措施的过程。
通俗的说，即是通过精神或物质的某些刺激，促使员工产生内在的工作动力，以积极的工作情绪和状态，朝着组织所期望的目标前进。
激励是一种激发人们行为的持续的过程，是激发员工不断创造绩效的持续的过程。
对于团队来说，员工的激励机制十分重要。
激励机制的合适与否关系到了团队的绩效的好坏与组织存亡。
它的作用主要有以下几个方面：吸引并留住人才，提高组织凝聚力；充分调动员工的积极性；规范员工的行为；激励有助于个人目标和组织目标的结合；提高工作绩效。
很多学者对激励理论进行了深入的研究，下面简要介绍本文中采用的双因素理 21 论和目标设置理论。
双因素激励理论又叫激励因素—保健因素理论，是美国的行为科学家弗雷德里克·赫 茨伯格（PeterickHerzberg）提出来的。
赫兹伯格通过调查发现，一些因素如工资、工作条件等只能消除员工不满，即使改善了，也不能调动员工的积极性，不能使员工满意。
这些因素称为保健因素。
而另外一些因素如挑战性工作、工作的责任及发展机会等能够使员工感到非常满意，这类因素的改善能激发员工的满意感，有助于充分持久地调动他们的工作积极性。
他把这类因素称为激励因素。
赫兹伯格的双因素理论认为，满意和不满意并不是相互对立的。
满意的对立面是没有满意，不满意的对立面是没有不满意。
也就是说，一个人可以同时感到满意和不满意。
双因素理还论认为，员工激励可分为内在激励和外在激励。
外在激励是指外部的奖酬或在工作外间接满足，如薪酬、福利等。
内在激励是从工作本身得到的某种满足，如兴趣、成就感等。
赫兹伯格认为，外在激励只能产生少量的激励作用，而内在激励能促使员工努力工作，积极进取。
目标设置理论是爱德温•洛克（EdwinLocke）提出的。
他认为，目标设置是管理领域中最有效的激励方法之
一，员工的绩效目标是工作行为最直接的推动力。
目标对员工的激励主要有五个方面：
（1）引导工作行为，明确的目标可以使角色分配更清晰，减少了日常活动的不确定性。
（2）目标体系明确了工作的挑战性和考核标准。
（3）目标是评判各种活动和资源利用的规范。
（4）目标决定了组织的结构，将组织的各方面力量集中到实现目标上来。
（5）目标反映了组织所重视的工作，提供了计划和控制活动基本框架
1。
3.1.3团队沟通理论 沟通就是我们通常所说的信息交流，即把某一信息或意思传递给客体或对象，以期取得客体做出相应反应效果的整个过程，是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅
2。
它包括输出者、接受者、信息、渠道等四个主要因素。
著名学者斯蒂芬•P•罗宾斯（StephenP.Robbins）在1997年建构了沟通过程模型，这一模型包括七个部分：沟通信息源、编码、信息、通道、解码、接受者和反馈。
如图7所示。
1卢涛.RL公司员工激励案例研究[D].大连理工大学,2010.2崔佳颖.组织的管理沟通研究[D].首都经济贸易大学,2006. 22 图7沟通的过程 按照不同的划分方法，沟通有多种形式，不同形式的沟通有着各自的特点。
通常可划分为：正式沟通和非正式沟通；上行沟通、下行沟通和平行沟通；单向沟通和双向沟通；口头沟通和书面沟通。
有很多沟通障碍会阻碍、歪曲有效的沟通。
组织行为学大师斯蒂芬•P•罗宾斯（StephenP.Robbins）认为重要的沟通障碍有过滤、选择性知觉、信息超载、情绪、语言、沟通恐惧等六种
1。
过滤是指发送者有意操纵信息，以使信息显得对接受者更为有利。
过滤的主要决定因素是组织结构中的层级数目。
组织纵向层级越多，过滤的机会就越多。
只要存在地位上的差异，过滤活动就会存在。
选择性知觉指接受者根据自己的需要、动机、经验、背景及其他个人特点有选择地去看或者去听信息，还会把自己的兴趣和期望带进信息中。
信息超载指信息超过个体能够分类和使用的能力。
会导致信息丢失，降低沟通有效性。
情绪指接受者的情绪感受会影响他对信息的解释。
语言指沟通双方由于在年龄、教育、文化背景、专业领域、纵向层级的不同而对同样的词汇理解不同，从而导致交流的不畅。
沟通恐惧指一些人（约占总人数5%~20%）总有某种程度的沟通恐惧或焦虑，或是在口头沟通，或是在书面沟通，或者是二者兼有的沟通上，感到过分紧张和焦虑。
从而影响到某一类或某几类沟通技术的使用。
3.1.4团队冲突理论 冲突存在于社会生活的各个层面，冲突也是不可避免的。
由于学者们各自研究探讨的侧重点不同，对冲突的认识及分析也各不相同。
Deutseh(1973)从行为层面对冲突进行界定，认为冲突是不相容的行为活动，它指的是 1斯蒂芬•P•罗宾斯（StephenP.Robbins）.组织行为学[M].北京:中国人民大学出版社,2008:322-325.23 个体行为活动干涉、妨碍或以某种方式介入他人的行动。
冲突的起源可能是两方或者多方之间对立的利益、目标、价值、或对上述的误解引起，然而只有当引起了它们彼此间不相容行为时才会引起冲突。
Thomas(1992)认为冲突既是个体不和谐的反应，又是发生在个人、团队、组织间的意见、目标或利益的不一致。
斯蒂芬•P•罗宾斯（StephenP.Robbins2008）把冲突定义为一种过程，当一方感觉到另一方对自己关心的事情产生不利影响或将要产生不利影响时，这种过程就开始了。
本人非常认同这个观点，因为它是一个广义的定义，可以涵盖所有的冲突水平。
以前的学者结合自己的研究侧重点，分别选取不同的标准对冲突进行类型划分。
Guetzkow&Gyr(1954)首次对冲突进行了分类，将冲突分为基于人际关系的情感型冲突和基于任务实体的实质型冲突，即实质型冲突是与团队工作任务相关的冲突，而情感型冲突则是与人际关系相关的冲突。
Amason(1996)将冲突分为认知冲突与情感冲突。
认知冲突是与任务相关的冲突，由决策时的不同意见或分歧所引起。
情感冲突是由个人的个性与人际关系等方面的摩擦、工作中的误解等引起的
1。
Jehn(1997)则将冲突分为任务冲突、过程冲突和关系冲突三类。
从广义的角度来看，任务冲突和过程冲突都是以任务为导向的，不同的是任务冲突强调的是在任务内容和任务目标方面观点的差异，而过程冲突强调的是在任务过程上观点的差异。
综合以上观点，既使这些学者使用了不同的名称，但其定义与所述的内容却十分相似。
总的说来，以往的学者主要是从对冲突问题所针对的对象将冲突划分为“任务冲突(taskconflict)”和“关系冲突(relationshipconflict)”，或称为“认知冲突(cognitiveconflict)”和“情感冲突(emotionalconflict)”。
早期的学者认为冲突对团队存在着消极的影响，然而随着学者对冲突认识的进一步深化，认为对冲突所发挥的效应有待进一步确认检验。
冲突的早期观点认为所有的冲突都是不良的、消极的，它常常与暴乱、破坏和非理性同时使用。
冲突是有害的，是应该避免的。
20世纪三四十年代，该观点占主流。
冲突的人际关系观点认为，冲突无法避免，与生俱来的，提倡接纳冲突。
此观点在20世纪四十年代末至七十年代中叶在冲突理论中占统治地位。
冲突的相互作用观点鼓励冲突，鼓励管理者要维持一种冲突的最低水平，从而使群体保持旺盛的活力。
相互作用观点并不认为所有的冲突都是好的。
它认为冲突有两类，一类是支持团队目标，并能提高团队绩效的是功能正常的、有建设性的冲突。
另一类是阻碍团队的工作绩效、功能失调的、有破坏性的冲突。
低水平的任务冲突和中低水平的过程冲突是积极的、功能正常的。
而关系冲突则总是降低各种团队绩效，对团队成员的各种工作态度产生消极影响。
目前为止，没有一项实证 1卢红旭.团队冲突对团队绩效的影响研究-基于信任的视角[D].浙江工业大学,2012. 24 调查结果显示关系冲突会产生正向的影响作用。
这是因为关系冲突破坏了团队成员的自我管理过程，当团队内部发生与任务无关的关系冲突时，会给团队成员带来消极的情绪，影响团队成员的理性判断，从而影响团队运作，致使团队任务不能顺利完成，降低了团队绩效。
3.2问题与原因分析 3.2.1团队成立期 总监的疑惑是在团队建设初期发生的重要事件之
一，它反映了团队的沟通问题。
这也是在团队建设过程中尤其是成立阶段常常遇到的必须解决的问题，如果处理不好，轻则迟滞团队的建设或者导致项目的延误，重则影响到团队的存亡。
这里，无论是Pete还是总监做的都有所欠缺，并因此导致实验室建设延期2个月，对团队绩效产生了负面影响。
只有Julie做得比较到位，有力地推动了项目的审批进程。
如何进行充分的沟通问题是团队成立期团队建设的核心问题，在“总监的疑惑”事件中具体表现在几个方面： 首先，团队领导者忽视上行沟通，可能会给团队的初建带来困难和误会。
沟通就是我们通常所说的信息交流，即把某一信息或意思传递给客体或对象，以期取得客体做出相应反应效果的整个过程，是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅。
它包括输出者、接受者、信息、渠道等四个主要因素。
按照不同的划分方法，沟通有多种形式，不同类型的沟通有着各自的特点。
按信息沟通方向划分，可把沟通分为上行沟通、下行沟通和平行沟通三类
1。
上行沟通是指信息由下级向上级传递的沟通方式，是企业领导者了解下属和职工意见的一种重要方法。
下行沟通是信息由上级向下级传递的沟通方式。
其作用表现在使下级明确工作任务、目标，增强责任感和归属感，协调各组织层次的活动，增强各级的联系。
平行沟通是指企业内各平行机构之间或同一层次人员之间的信息交流
2。
平行沟通可以加强各部门之间的联系、了解、协调与团结，减少各部门之间的矛盾和冲突，改善人与人之间的关系。
对Pete来说，在自下而上的沟通当中，没有及时主动地将团队的需求、原因交待清楚，以为领导的领导肯定总揽全局，知道和了解各个方面的情况，自己只需要将自己团队的具体需要量化出来，总监根据项目经费的情况酌情审批即可。
他没有意识到总监的工作经验和背景完全不同，导致总监根本不了解或不认为他提出的预算方案是合理的，根本就不认可费用支出的项目。
好在他及时将问题反馈到他的直接上司Julie处。
Julie的沟通就做得很充分，首先她不仅先问清了Lisa的疑问，而且从相关部门拿到了具体的说明，结合实际 1肖胜.小学校长与教职工沟通的现状及策略研究[D].辽宁师范大学,2007.2马倩倩.科技型创业企业成长中的团队沟通问题研究[D].山东大学,2009. 25 需要，彻底打消了Lisa的疑问，是一个比较成功的沟通。
其次，没有意识到的一些沟通障碍，影响了沟通的有效性。
有很多沟通障碍会阻碍、 歪曲有效的沟通。
组织行为学大师斯蒂芬•P•罗宾斯（StephenP.Robbins）认为重要的沟通障碍有过滤、选择性知觉、信息超载、情绪、语言、沟通恐惧等六种。
作为Lisa总监，因为级别高，时间紧（与Pete和中国有时差的关系），没有直接去收集了解事件的背景，但因对工作严谨负责，而导致项目上的合理申请没能及时批复，是要承担部分责任的。
她的表现行为正好体现出了有效沟通障碍中的“选择性知觉”。
“选择性知觉”是指在沟通过程中，接受者会根据自己的需要、动机、经验、背景及其他个人特点有选择地去看或者去听信息，还会把自己的兴趣和期望带进信息中。
这使Lisa不自觉地就用她在美国的经验来作出判断。
好在她及时从其部下找到了期望的答案，没有让项目长久耽误下来。
第
三，权力距离和沟通恐惧，加深了沟通不畅。
Lisa与Pete不是直接领导与被领导的关系，Pete因级别低，通常具有“害怕”越级沟通心理，每当与领导的领导或者更高的领导交流时，会有种惴惴不安的感觉（这在外企中是常见的现象），生怕写错了邮件给自己、自己的顶头上司带来不必要的麻烦。
从某种角度来说，这也可以算是某种程度的“沟通恐惧”。
对于Pete，因为有过前几次沟通的小错误，就更不敢多写、多问了，越是这样就越是导致总监Lisa的疑惑。
Lisa虽然从Julie处得到了清晰的答案，她还是不久就亲自飞到了中国。
Pete抓住机会向她做了一次清楚、全面的介绍，从实验室的设计、实施、配套设备管理流程到项目的进展、人员准备情况一一作了介绍。
并让Lisa进行实地现场参观，通过具体详细地介绍及现场实地的了解，Lisa有了深刻的理解，在随后的项目进程中，彼此的交流顺畅了很多。
当然，这一点上，Lisa采用了沟通渠道上“面对面的”的方式，因为它是最具丰富性的通道，有其它方式无可替代优点，避免了可能的误解。
3.2.2团队震荡期 团队在经过几个月的成立阶段后，原先的新鲜感逐渐地消失，成员们之间性格上的差异、处事方法的差异会逐渐暴露出来，冲突随之产生，这就要求学习如何进行协作，如何沟通，如何处理冲突。
团队的运行随之就进入到了震荡阶段，团队中的各种冲突逐步显现出来。
在“小赵、大李、Tony的恩怨”这个事件中，既有小赵与大李两人之间的个人冲突，也有北京与上海的部门冲突，前者是人际间的关系冲突，后者是任务冲突。
关系冲突中表现为人与人之间的敌对、不和与摩擦，它会加剧人们之间的紧张，使误解增大，从而会影响团队目标的实现。
小赵与大李的矛盾的确如此，她们的不和导致项目的延期完成，影响了团队的绩效。
而后者，北京与上海的部门间冲突是任务冲突，其本质上是有积极意义的。
26 它是因为北京和上海分别基于自己的视角对Bug流程的不同解读所导致的冲突，当它没有演变成高强度的冲突前给予及时的解决会促进整个团队的绩效。
当然，如果没有及时解决，让部门间的矛盾激化，那肯定也是会严重影响整体工作效率的。
这时，是需要团队领导者出面进行及时、有效的沟通与协调，对有争议的任务流程定义进行修正、细化，正如Pete处理北京和上海部门之间关于Bug处理流程时所作的完善和细化，这样，对日后团队的工作业绩有正面的积极作用。
冲突存在于社会生活的各个层面，冲突是不可避免的。
Deutseh(1973)从行为层面对冲突进行界定，认为冲突是不相容的行为活动，它指的是个体行为活动干涉、妨碍或以某种方式介入他人的行动。
冲突的起源可能是两方或者多方之间对立的利益、目标、价值、或对这些方面的误解而引起，然而只有当引起了它们彼此间不相容行为时才会引起冲突。
Thomas(1992)认为冲突既是个体不和谐的反应，又是发生在个人、团队、组织间的意见、目标或利益的不一致。
Jehn(1995)，Jehn&Malmix(2001)将冲突分为任务冲突和关系冲突，认为“任务冲突”关注的是任务本身，是人们对任务的不同观点而引起的冲突，比如团队成员对于所执行的任务目标、内容、工作流程、资源配置等不同观点所产生的差异。
“关系冲突”关注的是人际关系，是由个人差异如价值观差异、人格和偏好的不同等导致的消极情绪。
冲突的早期观点认为所有的冲突都是不良的、消极的，它常常与暴乱、破坏和非理性一起使用，是应该避免的。
而相互作用观点则鼓励冲突，鼓励管理者要维持一种冲突的最低水平，从而使群体保持旺盛的活力。
相互作用观点并不认为所有的冲突都是好的。
它认为冲突有两类，一类是支持团队目标，并能提高团队绩效的是功能正常的、有建设性的冲突。
另一类是阻碍团队的工作绩效、功能失调的、有破坏性的冲突。
低水平的任务冲突和中低水平的过程冲突是积极的、功能正常的。
而关系冲突总是降低各种团队绩效，对团队成员的各种工作态度产生消极影响。
目前为止，没有一项实证调查结果显示关系冲突会产生正向的影响作用。
这是因为关系冲突破坏了团队成员的自我管理过程，当团队内部发生与任务无关的关系冲突时，这会给团队成员带来消极的情绪，影响团队成员的理性判断，从而影响团队运作，致使团队任务不能顺利完成，降低了团队绩效。
对任务型冲突，在一定限度内可以有积极的作用。
然而，无论是关系型冲突还是任务型冲突，通常都是需要团队管理者及时介入处理的。
3.2.3团队规范期 当团队先后经过成立阶段、震荡阶段后，团队开始逐渐走向成熟和稳定，新进入的成员互相之间已经比较熟悉，这时要维持团队的工作效率就需要建立起良好的工作规范和制度。
在无约束的环境下，人的本性是趋向省力，自由和散漫的。
这是不利于团队效率的提高。
那么如何制定工作制度，制定什么样的制度才是有效的呢？“访问控制”事件 27 描述了这一阶段的问题。
O公司的软件测试团队在项目运行上是采用美国的模式，所以员工经过培训，就带回 了美国的项目运行流程和测试规范等。
但日常的工作规范，则具有本地属性，要符合当地政策、法规，由团队领导Pete具体管理。
在美国总部，的访问是自由的，这是因为美国总部的员工有着高度的职业精神，非常敬业，几乎很少有员工花大量时间在上干与本职工作无关的事情，所以公司的IT部门（在美国总部）根本不会限制的访问。
公司本着人性化的考虑，在中国的员工手册上没有禁止员工对的使用。
可能是由于中国的IT员工比较年轻，对上的新鲜事物比较好奇，却不太注意和区分工作时间与私人时间，随意上网。
但是，若要硬性规定在固定时间段才能上网的话，且无强制手段作为保障，是不可能起到非常好的作用。
Pete的第一个措施效果一般的原因便是如此。
Pete的第二个措施取得很大成功是由于其利用了目标设置理论和职业生涯管理理论。
目标设置理论实施的是具体、明确、通常是可见的、短期目标。
而职业生涯管理是指通过员工的工作及职业发展计划的设计，协调员工个人需求和企业组织需求，实现个人和企业的共同成长和发展，这是一种以人为中心的人本主义管理方法，是设置相对较长远的目标。
Pete通过和团队成员的单独面对面探讨（1:1），结合团队的任务需求及员工的爱好、兴趣，为每个成员设计了合适的短期及长期目标（职业规划）。
这些目标都是与员工自身的发展、兴趣密切相关，员工的热情、积极性、主动性自然就高，就不会产生抵触情绪。
以兴趣为引导，调动员工积极性、主动性，再结合一系列配套的规章制度即Pete的6条规定，效果当然是非常显著的了。
这6条规定，表面看是完成不同的任务，其实内部是有着密切的联想的。
前2条是要求团队成员独立完成的，后4条是要求团队领导与团队成员共同完成的，是基于前2条结果的，也就是说，对于前2条的结果，可通过后4条的执行进行检查、核实的，形式却不是那种郑重其事地、非常对立的，而是通过三个主题不同会议，一个单独面对面谈话（1:1）的自然方式进行的。
是比较容易被人们接受的。
做得好的，在会上会通过各种方式加以肯定和表扬，不好的也在会上明确地指出来并加以总结。
因为是大家开会讨论的形式，好的做法得以公开鼓励，大家会跟随效仿；不好的，大家会及时得到警示，避免重复发生。
这里Pete还用到了部分激励手段，如及时奖励（SpotAward）和大范围推广新开发的测试用例，这是应用激励理论的双因素理论中对员工的认可，是从物质和精神两个层面进行激励，效果当然好。
3.2.4团队高产期 测试团队进入到高产阶段，团队建设已经逐渐走上正轨，团队的发展比较平稳。
越来越多的项目，转移到中国北京测试团队的手上。
如何更好地发挥每一员工的作用从而让团队绩效更上一层楼的问题凸显出来。
28 在“老周的工作安排”事件中，Pete敏锐地感觉到了在当前的模式下，老周的工作效能没能发挥到极致。
如何进一步发挥老周的工作效能，激发并提高团队整体的工作绩效，同时还能改变当前操作系统Cert测试的混乱、低效的局面？ 首先，Pete进行了工作的再设计。
在罗宾斯的团队有效性模型中，第三类是工作设计的相关因素。
它包括的变量有工作的自由度、自主性、任务的完整性、重要性等。
对整个团队来说，Pete让Cert测试工作完整地独立出来，对原有的工作流程进行重构，使相关的测试环境、人员、数据相对集中并稳定下来，从而为团队的Cert工作的高效率创造了条件。
对老周来说，Pete让其承担了对O公司服务器来说非常重要的一个环节—做Cert测试，让其有了很强的责任感，从而激发了他的能动性和积极性。
对小赵来说，工作的转换让她减少了工作的枯燥感且对她提出了新的挑战，对于刚刚工作不久、充满工作激情的小赵来说，正是求之不得的。
这也极大地调动了小赵的积极性和工作热情。
其次，Pete针对团队成员的特点设置目标。
爱德温•洛克（EdwinLocke）认为目标设置是最有效的激励方法之
一，是员工行为的直接推动力。
明确而具体的目标能够提高工作绩效；困难的目标，一旦被人们所接受，会比容易的目标带来更高的工作绩效；有反馈比无反馈能够带来更高的工作绩效。
对于老周和小赵来说，完成对自己公司服务器的Cert测试并将结果公示到第三方的网站上，这是一个非常明确、可以达到的目标，而且目标实现的标志是非常清晰的--即能否通过第三方的审查并公示出来，这对公司来讲是非常重要的。
所以，每一次成功地完成Cert测试并让结果公示出来都是对老周和小赵的极大的鼓励。
加上来自公司内部赞扬的Email，这些正向的反馈极大地激励了老周和小赵，从而使的他们取得了很好绩效。
最后，Pete善用激励因素，激发团队成员的主动性和创造性。
赫兹伯格的双因素理论认为，一些因素如工作的挑战性、工作的责任及发展机会能够使员工感到非常满意，员工参与决策、管理过程对员工有激励作用。
首先，Pete打算让老周独自承担Cert测试任务，老周考虑后没同意，经过协商后，Pete同意老周的建议，多安排一个工程师与其一起完成这项任务。
老周的建议得到了尊重。
其次，老周可以自己自由地与平台主管协商工作进度，安排工作完成时间。
这些决定、管理的自主性以及看到的实时反馈（结果被公示）满足了老周他们的自尊、责任、成就、认可和成长的需要，给他们提供了内部工作动力，这符合双因素理论中的激励因素（内部因素）的描述或定义，的确带来高的工作绩效。
29 4对策与建议 4.1团队成立期的全面沟通 事实上，沟通问题往往贯穿于团队建设的各个阶段，包括项目的实施过程，而不仅仅是团队的成立阶段。
团队的成立阶段的主要目标是“要完成团队方案的勾画和其他准备工作，一般要花费几个月的时间。
”，这一阶段结束时，团队的每个成员都应该清楚本团队能够达到的组织愿景。
这当然离不开沟通了。
那么如何做？本文的经验告诉我们要从以下两方面做起。
一方面在团队建设初期，要建立全方位的沟通。
作为团队领导者，在沟通上会有三个方向，即自下而上、自上而下、同级沟通。
无论哪个都不能掉以轻心。
自上而下的沟通常用于给下属介绍工作、分配任务、发布或解释规章制度或指出下属的问题所在等。
这时具体清晰，有时效的沟通就比较重要。
常用的要领有：A多说小话，少说大话。
B不急着说，先听下属的意见。
C不说长短，不议论他人。
D不要厉声指责。
E广开言路，采纳意见。
自上而下的沟通之后，要及时收集反馈，以此来核实并确保下属得到的是你所期待传达的信息。
自下而上的沟通通常发生在给领导写报告、提供信息、对同事、对组织或项目提出意见或建议时。
这个方向上的沟通更要及时、准确还要客观。
原则上是当天的答复当天完成，不拖延。
交代问题要全面，不要想当然地认为领导可能了解事件的来龙去脉、前因后果，就像前文的“总监的疑惑”里的那样。
如果需要较长时间，当天完不成，要马上回复什么时候可以完成。
有必要时，在时间过半时交代进展情况。
让领导知道你的进度。
另外，有相反意见时，不要当着外人，当面顶撞。
这无助于问题的解决。
还有，在向领导反映问题的同时要准备好自己的解决方案或建议，供领导决断。
作为团队领导者，水平沟通指与其它团队的同级别的人员的沟通。
这时往往代表本组织与另一个组织进行对话、协商。
因各有各的立场，此时应该基于双赢及互惠互利原则，以诚相待。
尊重对方才能得到同样的回报，彼此尊重才能平顺地沟通。
另一方面在团队建设初期，还要建立全通道的沟通。
目前在外企的软件公司里一般有如下的沟通方式：通告（电子网站上）、电子邮件、语音邮件、电话、电话会议、事先录制的演说、现场演说（Allhandsmeeting）、单独面对面交谈、视频会议、网络桌面会议系统和及时通信等。
不同的方式适合不同的沟通场合。
在这些方式当中，进行单个个体的交流时，单独的面对面交谈（公司里常常称之为1:1）效果最好，尤其是要沟通关于模糊性的主题。
这是因为面对面的沟通传递的信息最量大， 30 它能同时提供包含语言、体态、面部表情、手势、语调等信息，还可以得到及时反馈，无论是语言的还是非语言的。
大范围的或与人员众多的大部门进行有效交流的方式是现场演说（公司里常常称之为AllHandsMeeting），类似国企里的全体成员大会。
大家可以面对面地进行交流、现场互动，提问和回答问题，但不如一对一进行的深入，有些时候放不开。
常常需要的是AllHands结合一对一来进行。
现场的听众可以通过发言人的语调、表情，理解发言人的真情实感并与发言人互动。
确保双方都能相互准确理解对方所要进行的表述。
对于日常的频繁的项目交流，有条件的可以运用视频会议、电话会议及网络桌面会议系统的方式来进行相关讨论。
视频会议最好，有声音有图像。
网络桌面会议系统不能看到与会人员的画面，但可以共同看到要讨论的项目文件、数据，比纯粹的只能进行语言交流的电话会议好。
单个人之间的交流，除了最好的一对一方式外，电子邮件、语音邮件、电话都可以。
语言邮件用得较少，电话快捷但不如邮件正式和易于记录和保存。
及时通信可以作为辅助手段用于个体间的非正式交流，现在很流行。
这样，无论对上，对下还是平级之间采用前面提到的原则和相应的沟通渠道必然降低误解的可能性。
从而大大提高团队的工作效率和业绩。
4.2团队震荡期的冲突管理 团队在进入震荡阶段后，会出现各种各样的冲突。
我们如何应对冲突呢？根据冲突的变迁，有三种观点，本文比较认可“相互作用的观点”，即维持最低水平的功能正常的，具有建设性的冲突，消除功能失调的，有破坏性的冲突，从而使群体保持旺盛的生命力。
一方面，努力化解关系型冲突。
小赵和大李之间的冲突就是典型的、个人与个人之间的不和与摩擦的关系型冲突。
如果纵容放任它，可能引起连锁反应，加剧团队中人与人之间的矛盾，影响相互间的理解，从而降低团队的工作效率，阻碍团队目标的实现。
对于此类的冲突，就应该像Pete那样及时处理、化解掉。
不能让冲突升级和加剧。
这种冲突是属于功能失调型的，对团队是百害无益的，要坚决、迅速地处理。
另一方面，运用中低水平的过程和任务冲突。
对于中低水平的任务和过程冲突，如本案中的北京与上海在Bug处理流程上的冲突，其本质上是有积极意义的。
当它没有演变成高强度的冲突前给予及时的解决会促进Bug处理流程的完善和细化。
对日后团队的工作业绩有正面的积极作用。
因为它激发员工们针对不同的观点进行讨论和协商，有助于找到高效的方法来完善相应的流程，从而使团队的工作水平及业绩更上一层楼。
这种冲突是属于功能正常的冲突，是可以加以引导和利用的，在一定程度上是有利于团队的发展。
31 4.3团队规范期的机制建设 在团队的规范化阶段，主要目的是要建立和形成良好的团队工作规范和工作流程，这个阶段也是形成和建立团队文化的最有利的时期。
建立良好的团队工作方式是要有一定的方法和技巧的。
如果不切实际地、武断地硬性规定，往往会引起抵触，效果不好。
但是，如果将其转化为员工内在的行为目标，让其从内心进行认可，如本案“访问控制问题”事件里Pete的做法，长期目标与短期目标相结合，即员工兴趣爱好与具体工作任务相结合让员工有了积极性和主动性。
随之建立的6条规则便得到很好的实施。
谈到公司的激励机制，在O公司，团队领导的权利是有限的，也就像Pete那样，给优秀团队成员申请一下及时奖励（SpotAward）但数额往往比较小，其他方面就力不从心了。
像O公司这种大型公司，其绩效考评及激励系统是很全面的，该系统会根据每个员工对应的工作职位码列出一套应具备的能力列表。
每个员工都要在每个财年结束、下一个财年开始时，在系统里填写下一财年的目标、达到目标需要的资源、成功与否的衡量标准等信息。
每个季度结束，要求经理对员工的各个能力目标进行评测、打分，跟进先前设定的目标。
但这套系统在执行时是有些问题的。
其中一个问题是其激励机制不够灵活。
目前O公司中国研发员工的所有经济来源包括国家标准的五险一金、年基本工资、财年奖金三部分。
部分人会有少量股权，这对中国大陆地区的员工来说，可以忽略不计（因不方便交易）。
财年的奖金是根据全公司的效益来定额度。
O公司的财报年年增长，但奖金却少得可怜。
同样在中国CPI增幅超5%时，薪酬的增加总体却固定为2%，而且限定只能30%的员工有此机会。
这对合作精神很好的团队来说很不公平，因为团队每一个人都认真努力了，硬要分出30%来，其他人什么也得不到，还会指望下一年那70%好好工作吗？还有一个显得不灵活的问题是O公司每年的那30%一定要选贡献大的员工，这样一来，资深工程师、项目主管的贡献肯定比年轻的工程师、普通成员大。
按O公司的政策，每年都会是同样的一批员工获得那极为有限的加薪，而这点加薪往往对基数已经很高的项目主管或资深工程师来讲起不到激励的作用，因为对于大基数来说加薪幅度太低了，而对普通的、资历浅的员工来讲，很渴望加薪。
同样那些数目对于他们来讲可是一笔不小的收入，激励效果不可同日而语。
希望O公司在薪酬调整上、奖金发放上不再一刀切，作硬性的规定，这对员工的激励非常地不利。
O公司激励体制的另一个问题是一切统得太死，让一线经理无用武之地。
经理不能根据团队发展和稳定的需要制定薪酬调整比例和幅度、不能申请Offcycle（在年度加薪之外的加薪）。
Pete发现有团队成员有离职倾向，Pete知道其有加薪的诉求，但Pete被领导告知不可申请Offcycle，但严格的比例规定，让有离职倾向员工的预期远远没有达到，即使后来通过很长时间的层层审批后，终于拿到反offer（针对挖人公司开出的offer而开出的反offer，目的是让被挖人员通过接受新开出的、往往在福利待遇上比挖人公司开出的offer 32 要优越的反offer，而愿意继续留在原公司），离职人员往往去意已定，不能挽回了。
4.4团队高产期的流程设计 合理的任务划分能充分利用现有的资源，减少重复投入，也有利于员工发挥最大的工作效能。
在操作系统Cert测试独立出来由专门的工程师负责后，测试环境稳定，工程师熟练，这就为提高Cert测试的效率做好了准备。
进行工作流程设计要注意以下几方面：员工参与、目标具体明确、反馈及时。
1.员工参与在进行团队目标细化、工作流程设计时，首先要充分吸收有经验的、资深员工的合理化建议，增加员工的参与机会和程度，比如Pete与老周协商Cert的人员配置时，尊重了老周的建议，多配置了一名工程师。
对老周来说，他的责任与参与的需要得到了满足，调动了他的积极性，有利于日后工作效率的提高。
2.目标具体明确将整个团队宏观的、长远的、模糊的目标进行细分并落实到具体的员工个人身上时，要遵循我们常说的SMART原则，即目标必须是具体的（Specific）、可以衡量的（Measurable）、可以达到的（Attainable）、和其他目标具有相关性（Relevant）、必须具有明确的截止期限（Time-based）。
3.及时反馈新的工作流程及工作任务划分必须考虑到能够给相应员工提供及时的反馈，与SMART里的M有点重复，但这里强调“及时”两字。
这有利于员工自己能及时感受到其工作成果被接受与否。
比如老周与小赵能通过其测试结果是否被第三方公示了、被同事查询到了而感受到其工作成功或失败。
在测试过程中，类似的情况有很多。
比如安排测试人员参加Bug讨论会，项目进展讨论会等。
会上，其他小组对测试人员报出的Bug的提问、质疑会促使测试人员认真对待自己发的每一个Bug，问题描述是否清晰、重现步骤是否详细、是否误报等等。
参加这方面的会后，几乎都不再需要经理再来对测试人员强调要如何发Bug了。
33 5结论 通过前面的几个事件的描述和分析，我们不难看出，在团队建设的不同阶段，会遇到不同的、影响团队效率的问题，我们总结和归纳一下O公司软件测试团队的经验和不足。
在团队成立阶段，要建立全方位、全通道的沟通机制。
这是贯穿整个团队建设的所有阶段，在成立阶段尤其重要。
通过前面的几个事件不难看出沟通的重要性。
无论是总监的疑惑还是小赵与大李的恩怨，都离不开沟通。
要增加上下级之间，同级之间的信任和理解就必须加强沟通。
我们要充分利用好现有的各种沟通渠道，选择恰当有效的沟通方式，进行充分地沟通。
在团队震荡阶段，需进行冲突的有效管理。
在团队建设过程中，我们常常会遇到各种各样的冲突和矛盾。
总的来说，大部分会像前文提到的小赵和大李，上海与北京之间的人际之间、组织之间的矛盾和冲突。
对百害无益的关系矛盾要彻底清除，而对任务型冲突要限制在一定程度内，及时加以利用和处理，否则也会影响团队的绩效。
在团队规范化阶段，应细化目标，建立柔性规章。
在团队的规范化阶段，应将团队的目标细化并与成员的兴趣、爱好及其职业发展规划结合起来，使员工从内心深处认可和赞同其目标；减少生硬、强制性的条款，代之以灵活、易于接受的方式，并加以正向的激励。
在团队高产阶段，进行合理的工作流程设计。
团队的高产阶段，为提高团队的整体绩效，除了人员、设备、环境因素外，还要考虑团队的当前工作流程是否合理、是否得到优化。
要对团队的整体项目或目标进行进一步细化或分解，找出合理、有效的工作流程安排，就像Pete改变美国的测试模式，把操作系统Cert测试独立出来那样，对原有的流程进行改造，从而在团队整体绩效上产生了飞跃式提高。
软件测试团队建设过程中，有很多要考虑的因素。
如团队的人员、团队的设备、团队工作流程、团队目标、团队文化、团队激励、团队的沟通与冲突、决策、绩效等等。
本文就团队发展的几个不同阶段，分别选取了几个影响团队有效性的案例加以讨论分析、抛砖引玉。
不同的团队建设，遇到的问题顺序可能不同、也可能遇到的问题会有所不同，但总的来说，离不开本文讨论的团队的冲突、团队沟通、团队的激励及团队工作流程的优化等几个方面，可以借鉴本文方法和经验。
如果从公司层面再加以配合，如在激励方面，那将更大地提高团队的绩效。
34 参考文献 [1]陈娟.科研团队成员知识共享行为意向研究[D].杭州电子科技大学,2012.[2]崔佳颖.组织的管理沟通研究[D].首都经济贸易大学,2006.[3]戴昌均.人力资源管理[M].天津：南开大学出版社,2008.[4]弗雷德曼，威尔逊.第五项修炼教程：学习型组织的应用[M].北京：经济日报出版社, 2002.[5]胡琨,刘浩,刘涛.初议软件测试[J].科技广场,2008,(05):241-242.[6]贾硕林,颜寒松.团队精神[M].上海：上海财经大学出版社,1999.[7]李宝元.人力资源战略管理：案例教程[M].北京：清华大学出版社,北京交通大学出 版社,2010.[8]李秀娟.组织行为学：先知而后行•行必有所为[M].北京：清华大学出版社,2012.[9]梁杰.软件测试工程师薪资走高[N].市场报,2003-7-25.[10]卢红旭.团队冲突对团队绩效的影响研究-基于信任的视角[D].浙江工业大学,2012.[11]卢涛.RL公司员工激励案例研究[D].大连理工大学,2010.[12]路易斯•R•戈梅斯-梅西亚，戴维•B•鲍尔金，罗伯特•L•卡迪.人力资源管理[M].北京： 北京大学出版社,2011.[13]马蒂•布龙斯坦.团队管理[M].北京：机械工业出版社,2006.[14]马倩倩.科技型创业企业成长中的团队沟通问题研究[D].山东大学,2009.[15]麦克莱恩.提高团队协作能力：创建信任与高责任意识的团队[M].北京：电子工业出 版社,2011.[16]斯蒂芬•P•罗宾斯（StephenP.Robbins）.组织行为学[M].北京:中国人民大学出版社, 2008:322-325.[17]王刚,李迎,白祎花.软件测试人员应具备的素质[J].软件导刊,2011,(02):34-35.[18]王娇娥.关于教育生活中沟通缺失问题的思考[J].现代交际,2011,(12):83-84.[19]王挺，卫宗荣，赵玉建.信息时代下的虚拟研发团队管理[M].北京：中国轻工业出版 社,2010.[20]伍传林.FTH公司成都厂区生产导入项目团队管理研究[D].吉林大学,2012.[21]肖胜.小学校长与教职工沟通的现状及策略研究[D].辽宁师范大学,2007.[22]辛海.团队为赢[M].北京：中华工商联合出版社,2007.[23]姚裕群.团队建设与管理[M].北京：首都经济贸易大学出版社,2006.[24]余世维.打造高绩效团队[M].北京：北京联合出版公司,2012. 35 [25]张雷,李红光.团队管理新模式[M].北京：中国时代经济出版社,2006.[26]赵海霞.团队薪酬体系对团队绩效的作用机制研究[D].华中科技大学,2012.[27]2011年中国软件测试从业人员调查报告[EB/OL]./ html/08/n-811608.html,2012-04-13.[28]关于冲突与谈判-百度文库[EB/OL]./view/09d007a1 bff12184ca.html,2012-09-12.[29]软件测试的发展现状与前景[EB/OL]./view/c4ecfa22a5 e9856a561260dc.html,2013-01-25.[30]我国测试行业之现状分析[EB/OL]./92/n-232092.html, 2011-03-17.[31]2012年中国软件产业经济运行现状分析[EB/OL]./news /201301/25/25.shtml2013-01-25. 36 致谢 三年的边工作边读书的学习生活即将结束。
回首往事，心中颇多感慨，感激之情难以言表： 首先，我要将我深切的敬意献给我的导师，她在我写作论文的过程中给予了我非常大的帮助，不论是论文的篇章布局、论述逻辑，还是论文的标点符号，她都仔细、认真、不厌其烦地多次指导，使我受益颇多。
在这里向导师表示深深的感谢！ 其次，感谢北师大经济与工商管理学院的诸位老师对我精心培养和严格要求，使我在理论学习和实践水平上都有了长足的进步。
同时他们严谨治学的态度、对学问的执着追求以及对学生极其负责的精神，使我受益匪浅。
最后，要感谢所有同学，在这个和睦，团结，热心的集体里，我不仅愉快地度过了三年难忘的学习生活，还结交到了很多有理想，有才干，有抱负的好友。
谢谢你们!
作者2013年5月 37
除文中已经注明引用的内容外，本论文不含任何其他个人或集体已经发表或撰写过的作品成果。
对本文的研究做出重要贡献的个人和集体，均已在文中以明确方式标明。
本人完全意识到本声明的法律结果由本人承担。
学位论文作者签名： 日期： 年月日 关于论文使用授权的说明 学位论文作者完全了解北京师范大学有关保留和使用学位论文的规定，即：研究生在校攻读学位期间论文工作的知识产权单位属北京师范大学。
学校有权保留并向国家有关部门或机构送交论文的复印件和电子版，允许学位论文被查阅和借阅；学校可以公布学位论文的全部或部分内容，可以允许采用影印、缩印或其它复制手段保存、汇编学位论文。
（保密的学位论文在解密后遵守此规定） 保密论文注释：本学位论文属于保密在 年解密后适用本授权书。
非保密论文注释：本学位论文不属于保密范围，适用本授权书。
学位论文全文电子版同意提交后：□一年
□二年在校园网上发布，供校内师生浏览。
本人签名： 日期： 导师签名： 日期： O公司软件测试团队建设案例研究摘要 软件测试行业目前发展迅速、需求旺盛，但因行业本身太年轻，国内软件公司管理能力低下，造成软件测试人员流动大，工作效率低。
如何建立一个高效、稳定的软件测试团队成为越来越突出的问题。
O公司作为业界第二大软件公司，其软件测试团队建设经验具有一定的代表性。
本文描述了O公司一个软件测试团队的建立、震荡、发展的过程，以及在这个过程中发生的影响团队建设的四个典型事件，包括总监的疑惑、小赵、大李、Tony的恩怨、访问控制问题和老周的工作安排。
针对这些案例，依据团队建设相关理论，有侧重地分析了O公司软件测试团队在团队建设过程中遇到的团队沟通、团队激励、团队冲突、工作流程细化等方面的问题。
本文认为，在团队初建时期，应进行充分的沟通，建立全方位、全通道的沟通机制；在团队震荡时期，应建立有效的冲突管理机制，及时应对关系冲突和任务冲突；在规范时期，应进行机制建设，细化目标，建立柔性规章；在高产阶段，应进行合理的工作流程设计，提升团队整体绩效。
关键词：软件测试团队建设团队激励
1 OCOMPANYSOFTWARETESTINGTEAMBUILDINGCASESTUDIES ABSTRACT Softwaretestingindustryhasdevelopedrapidly,thedemandisexuberant,buttheindustryitselfistooyoung,poormanagementcapacityofthedomesticpanies,causingthesoftwaretestersfrequentlymovefrompanytoothers,lowefficiency.Howtobuildanefficient,stablesoftwaretestingteamistoemoreandmoreprominentquestion.pany,asthesecondlargestpanyintheindustry,thesoftwaretestingteambuildingexperienceiswithacertaindegreeofrepresentativeness. Thisarticledescribedtheprocessofonesoftwaretestingteamofpanytobebuilt,shocked,developedetc.Italsodescribedfourtypicalcaseswhichaffectedthesoftwaretestingteam’sbuilding,urredduringthatprocess.Thefourtypicalcasesincluded:Thedirector’sdoubt;GrudgesbetweenXiaoZhao,DaLiandTony;esscontrolissue;WorkassignmentofLaoZhou.Basedonthoseeventsinpracticeandrelatedtheoriesofteambuilding,analyzedtheissuesofmunication,teammotivation,teamconflictandworkflowrefinement,whichwereencounteredintheprocessofpany’ssoftwaretestingteambuilding. Thearticleconcludedthat:itshouldestablishprehensive，municationmechanismsduringtheearlyphaseofteambuilding;itshouldestablishaneffectivemechanismsforconflictmanagementduringtheshockphase,handletherelationconflictandtaskconflictintime;itshouldmakerulesandregulationsduringthephaseofregulationsettingup,trytomaketheobjectivedetailedandtrytomakethoserulesandregulationsoftandeptable;itshouldmakereasonableworkflow-designtoimprovethewholeteam’sproductivity. KEYWORDS：SoftwaretestingTeambuildingTeammotivation
2 目录 1绪论
........................................................................................................
1 1.1研究背景.........................................................................................................11.2研究目的及意义.............................................................................................3
1.3研究内容与方法.............................................................................................4 2
案例正文
................................................................................................
6 2.1O公司概况......................................................................................................62.1.1O公司主要产品及市场状况...............................................................72.1.2O公司中国研究院简介.......................................................................72.1.3O公司软件测试团队介绍...................................................................7 2.2软件测试团队建设过程.................................................................................92.2.1BJSQE团队的成立阶段......................................................................92.2.2BJSQE团队的震荡阶段....................................................................102.2.3BJSQE团队的规范化阶段................................................................102.2.4BJSQE团队的高产阶段....................................................................11 2.3典型事件.......................................................................................................12
2.3.1总监的疑惑........................................................................................122.3.2小赵、大李、Tony的恩怨...............................................................132.3.3访问控制问题.......................................................................152.3.4老周的工作安排................................................................................16 3案例分析
..............................................................................................
19 3.1理论基础.......................................................................................................193.1.1团队建设理论....................................................................................193.1.2团队激励理论....................................................................................213.1.3团队沟通理论....................................................................................223.1.4团队冲突理论....................................................................................23 3.2问题与原因分析...........................................................................................25
3.2.1团队成立期........................................................................................253.2.2团队震荡期........................................................................................263.2.3团队规范期........................................................................................27
1 3.2.4
团队高产期........................................................................................28 4
对策与建议..........................................................................................30 4.1团队成立期的全面沟通...............................................................................304.2团队震荡期的冲突管理...............................................................................314.3团队规范期的机制建设...............................................................................324.4团队高产期的流程设计...............................................................................33 5结论
......................................................................................................
34参考文献..................................................................................................
35致谢........................................................................................................
372 图目录 图1我国软件产业2007年至2012年业务收入（单位：亿元）............................................1图2历届调查中公司的专职测试人员规模分布........................................................................2
图3论文框架................................................................................................................................5
图4O公司组织结构示意图......................................................................................................8
图5团队的类型..........................................................................................................................19
图6团队的有效性模型..............................................................................................................21
图7沟通的过程..........................................................................................................................23
3 1
绪论1.1研究背景 1984年9月中国软件行业协会成立，这标志着软件作为一个新兴产业成为我国经济生活中一个明确的组成部分，开始被单独作为一个学科和行业来进行研究和发展了。
在随后的20多年，我国软件产业历经萌芽阶段（1989——1991年）、起步阶段（1991——1994年）、兴起阶段（1994——1998年）、加快发展阶段（1998年以后），已初具规模。
2012年，我国软件产业共实现软件业务收入2.5万亿元，同比增长28.5%，我国软件产业总体继续保持稳定快速地发展，企业数量稳步增加，产业规模持续扩大，如图1所示： 图1我国软件产业2007年至2012年业务收入（单位：亿元）资料来源：工业信息化部 随着软件产业的发展，软件产品的质量控制与质量管理正逐渐成为软件企业生存与发展的核心。
几乎每个大中型IT企业的软件产品在发布前都需要大量的质量控制、测试和文档工作，而这些工作必须依靠拥有娴熟技术的专业软件人才来完成。
软件测试工程师就是
1 这样的一个企业重头角色。
1中国软件测试网对比2007年到2011年的调研数据发现(如图2所示)，“无专职测试人 员”该项所占比例从2008年开始逐年降低，在这五次调查中，测试专职人员在1-10人的比例仍占据首位，但总体有下降趋势，尤其近3年来呈现逐年下降，2011年比2007年更是下降了9个百分点。
专职测试人员在50人以上的，07、08、09、10、11年的比例依次为25%、27%、28%、33%、35%，呈逐年上升趋势。
数据中反映的公司专职测试人员的不断增多，测试团队的不断壮大，是软件公司对软件测试越来越重视的有力证明，软件测试的重要性毋庸置疑
2。
图2历届调查中公司的专职测试人员规模分布资料来源： 1胡琨,刘浩,刘涛.初议软件测试[J].科技广场,2008,(05):241-242.22011年中国软件测试从业人员调查报告[EB/OL]./08/n-811608.html,2012-04-13.
2 测试工程师的工作是利用测试工具按照测试方案和流程对产品进行功能和性能测试，甚至根据需要编写不同的测试用例，设计和维护测试系统，对测试方案可能出现的问题进行分析和评估。
对软件测试工程师而言，必须具有高度的工作责任心和自信心。
任何严格的测试必须是一种实事求是的测试，因为它关系到一个产品的质量问题，而测试工程师则是产品出货前的把关人，所以，没有一定的专业技术水准是无法胜任这项工作的
1。
同时，由于测试工作一般由多个测试工程师共同完成，并且测试部门一般要与其他部门的人员进行较多的沟通，所以要求测试工程师不但要有较强的技术能力而且要有较强的沟通能力。
然而，我国的软件测试行业本身太年轻、起步较晚，与国际先进水平相比差距较大，例如：国内开发人员与测试人员的比例是8∶
1，而国际公认的行业标准实际上是1∶
1。
这就导致了国内软件测试人员工作压力大。
另外，国内软件公司管理能力低下，普遍落后于国外，并且大多数公司存在着发展瓶颈——国内超过500人规模的软件公司为数不多，而过千人的IT公司更是屈指可数了。
管理上不去导致规模上不去，规模上不去导致很多公司只能在意识上重视测试，没有能力在测试上进行实际的投入。
这必然导致软件测试人员待遇低，工作不热情，效率不高。
在传统的软件开发模型中，软件测试排在靠后的阶段，即在需求分析、概要分析、详细设计、软件编码之后，然后是软件的发布（在现代新的开发模型中，测试是贯穿于整个产品周期，从设计阶段就开始了）。
在整个开发过程中，软件测试人员是处于服务的角色。
软件测试对员工的吸引力不如程序开发那么强。
尤其是在O公司这样大型的、专业的、集软件与硬件开发于一体的公司中，来自其他部门的吸引力特别大，人员在部门间、甚至是公司间流动特别大；同时，软件测试工作绩效不容易衡量，激励方式不容易把握，常常还导致部门生产效率不高、员工热情不大、团队缺乏凝聚力的现象；另外，对于O公司这样一个跨国的大型公司，如何包容具有不同工作背景，不同文化习惯的员工也是一个不容忽视的问题。
如何构建一个高效、稳定、且具有一定的凝聚力、战斗力的队伍，对于软件测试经理来说是一个极大的挑战。
1.2研究目的及意义 软件测试管理的目标是实现软件质量、进度、成本之间的最佳平衡。
有效的测试管理需要企业管理层、软件开发团队、质量保证与测试团队通力合作，采用计划、组织、领导、控制等手段，组建高效团队，制定完善的测试流程，做好测试设计，有效执行测试，加强 1王刚,李迎,白祎花.软件测试人员应具备的素质[J].软件导刊,2011,(02):34-35.3 过程跟踪，从而顺利完成质量保证和测试任务。
软件测试是技术密集型活动，团队的知识结构、创造力和凝聚力是保证测试流程、测试技术充分实施的基础。
本文以软件测试经理的亲身经历，从组织行为学，团队建设理论、团队激励理论出发，以O公司的一个软件测试部门为例，理论联系实际，阐明在实际环境中，如何运用相关理论，进行软件测试团队的建设，增强团队的凝聚力，提高团队的工作绩效。
为相应理论提供鲜活的例子，丰富软件测试行业的管理经验。
在实践上，虽然本文以O公司这样一个跨国企业为例，探讨了软件测试团队建设的相关问题，但它同时也是软件测试行业的一个缩影，很多国内企业的测试团队也存在着与它类似的问题。
所以，本文虽然是有关O公司软件测试团队的案例研究，有其问题的特殊性，但我们应该看到这些案例所反映出的共性，反映出问题的普遍所在。
本文尝试着通过对O公司的一个软件测试团队在进行团队建设的不同阶段所遇到的不同障碍进行分析，从而为同类型的软件测试团队提供了解决问题的思路和对策。
1.3研究内容与方法 本文使用案例研究的方法，以O公司的一个软件测试团队的建立、震荡、发展的过程为主体，记录了该软件测试团队6年来的成长历程，以及在成长过程中出现的团队建设方面的主要问题。
选取了团队建设的不同成长阶段发生的典型事件，并围绕这些实践中出现的问题，有侧重地分析了O公司软件测试团队在团队建设过程中遇到的团队沟通、团队激励、团队冲突、工作流程细化等方面的主要问题。
总结了可为类似软件测试团队建设提供可借鉴的经验和教训，并就O公司软件测试团队的未来发展提出可供参考的思路和建议。
论文框架如图3所示
4 图3论文框架
5 2案例正文 2.1O公司概况 O是世界上第二大的企业软件公司，向遍及145个国家的用户提供数据库、工具和应用软件以及相关的咨询、培训和支持服务。
O公司总部设在美国加利福尼亚州的红木城，全球员工超过40,000名，是《财富全球500强》企业。
自1977年在全球率先推出关系型数据库以来，O公司已经在利用技术革命来改变现代商业模式中发挥关键作用。
O公司同时还是世界上唯一能够对客户关系管理―操作应用―平台设施进行全球电子商务解决方案实施的公司。
O公司1989年正式进入中国市场，成为第一家进入中国的世界软件巨头。
其首创的关系型数据库技术也从此开始服务于中国用户。
1991年7月，经过了近两年时间的努力开拓，为了更好地与迅速发展的业务相适应，O公司在北京建立独资公司——北京软件系统有限公司。
2009年4月，以74亿美金收购S公司，从此拥有S公司旗下的数万员工及著名的产品Java和Solaris操作系统。
S公司创建于1982年，1986年在美国成功上市，主要产品是工作站及服务器。
财富500强之
一，行业中被认为是最具创造性的企业之
一。
S公司不仅打败了包括IBM在内的全部工作站（WorkStation）和小型机（MiniComputer）公司，而且依靠它的Solaris（一种Unix）操作系统和风靡世界的Java程序语言，成为在操作系统上最有可能挑战微软的公司。
S公司不乏能人，它不仅为Google培养了CEO埃里克·施密特和首任工程部副总裁韦恩·罗森（WayneRosen），并且在一定程度上奠定了今天Google工程部门的基础。
但当互联网泡沫破碎时，它以服务器和工作站为主的硬件业务便急转直下，从硅谷最值钱的公司沦为人均市值最低的公司。
如今，O公司的业务已几近覆盖中国所有的省、自治区与直辖市——在中国建立了14个分支机构、4个研发中心、拥有超过2.5万个客户、1500个合作伙伴和4500名员工。
在支持创新和开放标准方面，O公司的表现更加无与伦比，其中，O公司的在线开发者社区——O公司技术网(OTN)在全球拥有1400万名成员，包括25万名中国成员，为中国本土企业和机构提供了强有力的支持。
在中国推行“十二五”规划之际，O公司致力于利用创新性技术为客户、合作伙伴和社区提供发展动力，为中国的可持续性发展贡献自己的力量。
主要集中在三个方面：加速信息技术的应用；通过创新性技术支持企业转型；培养本地技术人才。
6 2.1.1O公司主要产品及市场状况 在结束不久的2012年财年，O公司取得了很好的业绩：GAAP总收入增长4%，达到371亿美元；营业利润增长17%，达到137亿美元，利润率达到37%；净收入增长27%的历史最高水平。
O公司自始至终都在做一件事，那就是围绕着新兴技术领域，如：云计算、社交、大数据与移动应用进行并购与产品的推陈出新。
O公司产品主要有以下四类：
（1）数据库：O公司数据库、实时应用集群、数据仓库、MySQL、Timesten内存库等。
（2）中间件：数据集成、业务分析、SOA、WebCenter、WebLogic等。
（3）管理软件：人力资本管理、客户关系管理、企业绩效管理、财务管理、采购管理等。
（4）集成服务器：大数据机、ExaData云管理服务器、Exalogic中间件云服务器等。
这四大产品线几乎涵盖了企业云应用所有组件，可以提供服务器、存储，在这之上O公司自己的虚拟化技术和VM直接竞争；有数据库、有中间件，O公司重写了ERP和CRM以后，能够做到支持云的设计。
O公司提供云所需要的一条完整产品线。
在企业管理环境中，很多公司都可以提供建设云的一部分，但是没有哪一个公司可以像O公司一样完整，从数据库、软件、硬件、安全到ERP全部的一揽子提供。
如O公司全球总裁马克赫德所言，O公司目前没有竞争对手，原因是公司拥有最全面的产品线，拥有包括SAAS、PAAS和IAAS在内的三个层次的云服务，能够为客户提供最全套的解决方案，这是其他竞争对手不具备的。
2.1.2O公司中国研究院简介 O公司的软件研发、设计、维护都由软件研究院负责完成。
OARDC(O公司AsiaResearchandDevelopmentCenter,)是O公司在海外建立的三家研发机构之
一，包括2002年在深圳，2003年在北京及2007年在上海成立的三家研发中心，同时，在新加坡、印度、韩国、澳大利亚、日本等地还有分部门。
在中国主要从事社会网络、嵌入式技术、虚拟技术、空间技术、普适计算、电子商务等方面的O公司产品开发及维护、应用开发及原型系统设计工作。
同时为中国及亚太地区合作伙伴提供专家及技术支持。
2.1.3O公司软件测试团队介绍 O公司的各个产品线都有自己独立的软件测试队伍。
本文讨论的是O公司旗下的SystemGroup（原S公司的）X86软件测试团队。
在2006年，该团队在北京组建，由美国总部的Julie领导，总监是Lisa，成员最多时达到18人。
其中骨干成员是从其它部门抽调过来的，加上对外招聘的人员、应届毕业生及实习生组成。
所以成员的背景、经历有很大的不同（组织结构如图4所示）。
7 图4O公司组织结构示意图 这个软件测试团队主要负责O公司的X86服务器的系统集成测试。
O公司的X86服务器主要是指基于AMD和IntelCPU的服务器，分为机架安装式、桌面式和刀片式，是X86体系架构；SystemGroup的其它部门主要是处理Solaris操作系统和SPARC体系架构的专用服务器。
系统集成测试主要包括X86的部分Firmware测试，如BIOS/UEFI、ILOM的升级测试、板载I/O测试、外插卡I/O测试、外插卡驱动测试、外插卡的组合测试、系统压力测试、部件（如内存条，CPU，硬盘）的测试等。
还有不同操作系统的如Redhat，Windows，VMware，Solaris等Cert（认证）测试等。
每当一个AMD或者是Intel新的CPU型号发布，O公司要推出相应的主机服务器时、或者老的型号的服务器需要推出更新版本时，都要经过该系统集成测试，合格后才能发布供全球客户使用。
所以，这个团队常常是任务紧，工作量很大，相当辛苦。
而且要求测试人员知识面广，不仅要求懂得计算机硬件体系结构，还要懂BIOS/UEFI层面的知识，不仅要求对操作系统的深入了解，还要会编程，经常要改些测试脚本程序等。
可以说，系统测试人员几乎是计算机的全面手。
团队建立之初，队员由美国同事培训，学习并接收项目。
开始是做一个平台的Sustaining维护工作，后来先后接收了40多个平台，工作成绩让美国同事大为赞许。
现在北京和上海的团队一起成为O公司X86架构在美国东部、西部开发中心之后的第三个中心。
已经与美国的中心并列，独立承担新产品的研发测试任务。
8 2.2软件测试团队建设过程 本文中的O公司软件测试团队的建立过程是比较典型的美资大型跨国企业在中国建立团队的过程。
因为美资大型跨国企业大多数比较成熟，在很多国家都建立有不同的团队，经验相对丰富。
大多数情况下，在工作流程上，往往照搬其总部模式，而在日常管理上则由团队领导者结合本地规章进行管理。
但是，团队建设毕竟是与人相关的活动，其在不同的环境下，面临不同的人群，必然有着不同的矛盾、冲突，随之相应的就是要有不同处理方法、步骤和流程，这导致本地团队领导者在团队建设的不同阶段会面临不同的障碍，要运用不同的方法，手段进行处理，必要时还会在工作流程上加以变革。
软件测试团队，它是一种固定工作团队，因其是IT行业，人员素质高，有其特殊性。
本文尝试着以团队建设过程中的不同阶段为视角，对所遇到的不同障碍进行分析和解决，从而建设一个高效的团队。
事实上，在团队建设的不同阶段，“高效”的标准不尽相同，本文以最终是否会影响到整个团队的预期目标/项目为标准来选择相应的矛盾加以分析，而不是局限于各个阶段内。
这里“高效的团队”是指（相对与公司其他同样性质、处理同样工作的团队）在相同的时间内、在保证质量的前提下，能够处理和完成更多项目的团队。
下面先简单回顾一下O公司软件测试团队（BJSQE团队）的建设历程。
2.2.1BJSQE团队的成立阶段 2006年5月，Lisa和Julie在中国S公司研究院成立了X86研发部，负责S公司已推出的X86各型号服务器的升级与测试工作。
该研发部由北京和上海两部分组成。
计算机硬件相关的开发、测试放在上海，软件测试部分放在北京，我们称之为BJSQE团队 Lisa和Julie从北京S公司研究院的Solaris部门选调了大李、小唐、Pete，新招了小赵、小张等5人组成了北京测试团队的第一批成员。
大李97年哈尔滨理工大学毕业，在联想、富士通等公司的计算机研发部门工作过，在S公司的Solaris开发部门也工作了3、4年，经验比较丰富，是作为技术主管吸收进来的，性格豪爽，典型的东北人性格，是IT行业里不多见的女强人。
小唐99年浙江大学计算机系毕业，在IBM工作几年后加入S公司研究院的Solaris部门，做开发已经有2年了，工作经验也很丰富，是资深工程师。
小赵，大连理工计算机系硕士应届毕业生。
Pete是清华大学的，在IBM工作过一段时间，在Solaris部门作项目经理3年了，调过来准备作为这个新成立部门的部门经理。
小张是大学刚毕业的实习生。
这个软件测试团队成员确定后，Julie把Pete、小唐、大李派到美国X86服务器研发总部--加州的门洛帕克去接受培训。
按Lisa的计划，准备让北京的团队首先接手S公司G12X平台的测试任务。
但是她始终不能确定，北京这个新团队到底能不能顺利接下并完成这个任务。
G12X是以AMD皓龙2核处理器为CPU的两款机架式服务器，分别是1U的G1X
9 和2U的G2X，内存16GB、4个千兆网口的低端服务器。
大李、小唐在美国进行2个月的培训，学习了如何建立测试环境、如何修改、调整测试用例、如何运行测试及生成测试报告等。
Pete负责北京的总体安排，包括实验室的建立、人员、工作进度的安排等。
在团队建立之初，交流的不顺畅导致实验室及测试环境的构建没有按期完成。
典型事件一的“总监的疑惑”详细地描述了该情况。
延期2个月后，Pete在得到Julie的帮助后，终于完成实验室的构建。
Lisa亲自到北京进行实地视察。
在考察了新建的实验室后，Lisa让大李与小唐现场演示如何进行测试，大李与小唐按照培训的方式认真地完成一轮测试并将详细的测试报告发给Julie和Lisa审阅。
2006年12月11日，经Lisa批准，北京软件测试团队正式开始从美国同事那里接手G12X的测试任务，这宣告X86北京测试团队终于度过了成立阶段。
2.2.2BJSQE团队的震荡阶段 在开始G12X的测试时，团队其实进入了震荡阶段，先后出现了小赵与大李之间的矛盾及北京与上海团队之间的冲突。
典型事件二“小赵、大李、Tony的恩怨”详细地描述了这些矛盾和冲突。
小赵与大李的矛盾已经影响到了项目的顺利完成。
若再不能及时解决这些问题，冲突加剧，矛盾加深就会极大地影响整个团队的绩效。
Pete通过安抚人心、与其他部门及时沟通，终于渡过了这一危机重重的阶段。
2.2.3BJSQE团队的规范化阶段 当时的系统集成测试主要内容有两大块，操作系统的On-board测试和OptionCard测试。
操作系统的On-board测试是针对主流操作系统Window、Solaris、RedhatLinnx、SuseLinnx、VMware等进行CPU、内存、硬盘、网络的性能和压力测试。
Option卡测试又分两类，一类是针对存储卡的，另一类是针对网卡的。
这两种测试都要进卡的驱动测试，压力测试、性能测试以及对这两种卡在主机的不同扩展槽上的各种组合测试。
对于4U的服务器，我们的主机通常有6-8个扩展槽，主机支持的网卡有10种、存贮卡有7-8种，各种组合汇总后是一个非常大的表格。
我们的测试要覆盖重要的、典型的组合，这时测试用例的设计与选取是非常重要的，它完全依赖于测试人员的知识和经验。
顺利完成G12X的1.3版本和1.4版本后，其测试发现的Bug，测试的速度得到美国总部的认可和好评，于是新的项目F12F、G4E、G4F先后从美国转移到中国，由中国北京团队进行测试工作。
随着项目即主机平台的增加，测试的内容也在增加。
除了前面说的两大块即操作系统的On-board测试和OptionCard测试，后来又增加操作系统的认证测试、部件Qual、随服务器出厂的光盘Image制作与测试，这个光盘能帮助客户安装操作系统，并提供必须的驱动程序，还可以做基本的系统诊断等。
原来的5个人已经远远不够了。
这时Pete从其它研 10 发部门请来了Feng、老周等资深工程师，又从外部招来小李、老韩、老付等，还从加拿大招了一个海归Mike。
团队成员增多了，团队的生产力是有所提高，但是没有带来与增加的人数相对应的生产力的提高。
刨除新进入员工在年龄、工作经验上与老员工的差异因素的影响，生产力的提高程度还是与期望值相差较远。
什么原因呢？Pete发现有些同事上班时花了很多时间流连忘返在外网上，这势必影响到项目的进展，怎么办呢？Pete采取一系列的措施，终于让团队成员将精力集中在工作项目相关的事情上了，对此，典型事件三“访问控制问题”进行了详细的介绍。
2.2.4BJSQE团队的高产阶段 大家上班都认认真真地工作了，但是人手的增加还是远远赶不上项目和工作量的增加，如何解决这个问题?
Pete又采用了如下三个方面的措施。
首先，Pete提高团队自身的工作效率，量化工作任务、工作时间。
将每一个Test用例的准备时间、运行时间全都量化，每个项目的测试计划定下来后，相应的测试用例也随之定下来，那么测试的设备、环境、时间基本也就确定下来，加上一定比例的富余量，如无意外情况发生，那么测试的完成时间也就随之定下来，这个时间里有测试用例的运行时间、有测试工程师的交互时间，如果测试交互时间不满，就会再增加其它任务，即工程师要同时处理几个测试任务，极大地提高了工程师的工作效率，从而提高了整个团队的工作效率。
其次，Pete对美国的测试工作模式进行更改：优化测试计划，将OS的部分测试合并到Optioncard测试中，将二者有机结合起来而不是完全隔离开来，这样就避免了二者相同部分的测试，减少了重复；同样地，将部件Qual的测试也融合在常规的测试周期中，不必像美国同事那样单独为部件Qual运行测试。
从而大大提高了北京团队的整体效能。
再次，将美国简单地按平台划分测试人员的方式进行调整，美国是一个平台4-5人固定不变，北京是同类平台全都由一组人员来测试。
比如在美国，G12X是一组人在测试，G12F可能是另外一组人。
北京则是G12X、G12F，只要是1U和2U的服务器都是一组人负责测试。
这样，工程师可以借鉴相关平台的测试经验，不但增加了工程师测试的熟练程度、还增加了并行性，极大地提高了团队的工作效率。
同样的平台项目，美国一组工程师只做一个，而北京团队可以接手两到三个，其高效率让美国X86总部很欣赏，逐渐地把美国东部和西部的测试任务都挪到了北京。
2007年12月北京团队开始接手刀片式服务器的相关工作，2008年开始接手存贮服务器的测试任务。
到目前为止，北京团队先后接手完成了44平台服务器的测试任务。
仍在运行的有9个平台。
事实上，在高产的同时，如何能在质量上更上一层楼的问题接踵而来，典型事件四“老周的工作安排”就是典型的解决方案之
一。
11 2.3典型事件 2.3.1总监的疑惑 明媚的阳光并没有给Pete带来好的心情，X86SQEteam的成员也是这样。
Pete是X86SQE的经理，这个部门从4月成立到现在已经有6个月了，骨干大李，小唐经过2个月美国培训回来有一段时间了，测试的流程、步骤都已经非常清楚了，但实验室却还没有建立起来。
让大家高昂的工作热情无处发挥。
这到底是真么回事呢？Pete一遍一遍地问自己。
Pete是从Solaristeam调过来的，作项目管理有几年了。
来O公司前还在IBM干过一段时间，但对面前的情况也是一筹莫展。
建设实验室所必须的设备清单已经提上去了，购买测试样机的内部PO也已经提交了，可是迟迟没有得到总监的批复。
Pete仔细地把清单还有PO看了一遍又一遍，没有什么问题啊。
清单上的部件都是实验室必须的，有网线，交换机，电源插座等等，购买测试机的PO包括服务器的配置清单，进出口的费用，有清关费，运输费，代理服务费等等。
如果再得不到批复，实验室不能如期建好，被测服务器不能及时进口到中国，原定的项目计划就要泡汤了。
无奈之下，Pete给他的顶头上司—资深经理Julie发了邮件，请求帮助推进总监的批复进程。
Julie是Pete是上司，常驻美国，是Lisa的老部下，彼此非常熟悉。
Pete是她和Lisa总监的新部下。
当Julie从Pete处了解了事情的详细情况后，向总监Lisa发去了询问的邮件。
总监Lisa也很郁闷，她对在北京研究院新招的这个项目经理已经不太信任了。
在前一段时间，她发信让Pete回答两个问题，结果Pete回信谈了一大堆别的事情就是没回答她想要的那两个问题。
还有一次，Pete发信给Lisa希望她批准Maggie（Lisa的助理）帮他下一个PO，邮件的写法有问题导致Lisa以为他让Lisa去批准一个已经生成的PO。
Lisa特地进入订单系统查询了好几遍，也没看见有新的PO需要批复。
后来还是Maggie助理了解情况后告诉Lisa事件的原委。
这些导致Lisa总监对于来自Pete的请求总是抱有怀疑的心态。
这不，当她前几天又收到Pete的实验室采购清单及被测机购买清单时，就很不确定该不该批准了。
看到老部下Julie询问的邮件，Lisa就把自己的疑惑全都说了出来，首先在美国像网线、交换机、电源插线板都由后勤部门提供，为什么Pete要提出购买那些配件。
另外，关于购买被测机的PO，为什么里面要包含运输费、代理费、清关费等一大笔费用，这在美国闻所未闻，能否麻烦Julie先了解清楚。
Julie立刻与中国研究院的后勤部门取得联系，得到确认，这些东西的确要由实验室的使用者去准备，然后又与负责中国订单的部门取得联系，确认这些费用是必须的，是因为中国的海关规定与美国有所不同才导致Lisa总监在美国进行类似业务时不会涉及那些费 12 用。
当读完Julie转发过来的各相关部门的详细说明，Lisa终于明白了其中的来龙去脉。
于是在财务系统里批准Pete的那两笔费用申请。
收到已批复的系统提示信息，Pete和同伴们终于一扫几日的阴霾高兴起来，实验室的设置工作又可以继续开展下去了。
新项目不日即可开始了，但Pete心里的疑问却没有消除，PO为什么这么久没有批呢？总监不信任我们吗？Lisa心里也有疑问，Pete为什么不在系统的申请里详细标注或说明呢？Pete的交流成问题。
Pete的同事也有疑问，这到底是怎么回事呢，实验室为什么拖了这么久？ 2.3.2小赵、大李、Tony的恩怨 小赵坐在电脑前很生气，盯着屏幕上漂亮的屏保画面，脑子浮现的却是这两天的不顺心的事。
首先是其主管大李对她的态度最近让她很不愉快。
小赵是去年来的硕士毕业生，通过层层选拔、过关斩将进入她仰慕已久的IT界著名的S公司。
她基础知识扎实，本人也勤奋努力好学，在其主管大李的精心带领下很快就适应了O公司的环境，不久就能独立完成一些基本的测试任务。
再后来自己还可以在主管的帮助下完成一些测试脚本的修改。
她的主管大李是从其他部门调过来的，是部门的元老，名牌大学毕业生，先后在几家著名的IT公司里工作过，是一名经验丰富、工作能力强的女技术强人，性格也很豪爽火爆。
小赵感觉到大李不像以前那么耐心了、不热情了，有点摆架子。
另一件让她不高兴的是上海OSBringupTeam的Tony。
Tony是OSBringUpTeam负责解决北京团队发现的Bug。
小赵觉得Tony老是为难她，写Email不回、打电话不接、更新Bug记录也不及时。
她盯着屏幕良久，思考着她该如何办。
大李近来也不太顺心，一个是最近上海OSBringupTeam新来的Tony对北京发的Bug响应不及时，两人为此还在Email里吵得不可开交。
另一个是小赵最近越来越不把她这个主管放在眼里，呼来换去，远不是刚来公司报到时那个乖巧听话的小姑娘了。
尤其是到美国出差去接项目时，本应由她这个主管出面联系的一些项目，小赵竟也不先打一声招呼就擅自主张地应承下来，让她感到很被动。
是时候给这个小丫头一些教训了，但是Tony这个事情比较棘手，每次发的Bug他老是让我们做这做那，自己什么也不做，该自己收集的数据也要让我们来收集，太过分了。
其实上海的Tony那边也在不断的抱怨，说北京这边的测试人员提供的数据不完善，让他无从下手。
Tony是一个很有经验的软件开发人员，在来O公司前已经工作很久了，比较挑剔，要求较严格，有任何不清楚的问题都会小题大做地叫嚷一番，但在这件事上他似乎也是有道理的。
问题到底出在哪儿？如何解决呢？ 大李是项目主管，她带领小赵和小李负责O公司4U服务器的系统测试。
原定2个月完成的测试任务结果却没能及时完成。
大李负责制定测试计划、选择测试用例，小赵和小李负责测试的运行和结果分析。
自从大李和小赵出现矛盾后，他们小组的工作效率有些下 13 降，在版本1.6的测试过程中出现了没能及时完成测试的情况，这在以前从未发生过。
至于北京和上海OSBringUp之间的关系，的确有些问题。
不光大李这个项目，另一个2u服务器项目的同事也抱怨类似的情况。
BringUp工程师随意关闭北京小组发的Bug，不自己收集数据，甚至全推给北京小组来收集。
以上这些情况Pete看在眼里，急在心上，如何化解呢？ Pete经过观察和分析，发现了小赵和大李变化的缘由。
自小赵毕业后招到X86部门后，本人很努力、很勤奋，加上大李的认真带领和指导，很快就能胜任基本的测试工作。
Pete又让小赵同大李一道去美国培训学习O公司的新产品、了解研发情况、接收新项目4U服务器到中国进行测试工作。
小赵任务完成的很出色，受到Pete的表扬，同时小赵也完成Pete额外分配的Testcase的升级和迁移，自信心大增，就有点飘飘然了，有些事竟没有请示主管就下意识的自己就做了，因为她认为自己可以胜任，有信心。
大李是一如既往地认认真真地完成自己的工作，但眼中揉不得沙子，看不惯小赵身上的变化，于是在自己的行为和态度上就流露出来。
经过对双方深入的了解，Pete认为这事要向双方挑明，把问题说开。
于是他在一天下班之前约上大李和小赵到公司楼下的咖啡厅喝咖啡。
在柔和的灯光下，伴随着舒缓的音乐，Pete首先与小赵，大李一道回顾了团队组建后的工作安排、工作成绩。
小赵对大李给予的指导和帮助表示深深地感谢。
当提到大李感到不悦的事情时，小赵很是惊讶自己的行为会让大李感受到了伤害，诚恳地为自己欠考虑的行为向大李道歉，大李欣然接受了，二人从此和好如初。
小赵不断地成长进步，大李一如既往的认真工作，后来由于又有了新的项目，Pete把小赵调到新的项目组里，大李还有些不舍呢。
关于与上海的冲突，这个问题较为复杂，里面既有工作流程上问题，也有个人关系的问题。
Pete认为应该先仔细研究工作流程上的问题出在哪儿。
在软件行业中，关于Bug管理一般都会对在发Bug时的情况作出规定，如要求Bug要有的详细的错误信息，详细地重现步骤，错误的严重等级，产品相关属性等。
但对于由谁重现Bug，如何分析及解决Bug的定义较为宽松。
这就留有很大空间让软件开发或维护人员发挥自己的长处。
至于关闭Bug，一般会要求有验证即可。
到底是谁来关闭，并不介意。
这些宽松的规则和要求，如果大家本着相互体谅的原则，不会有问题，但对于过于较真，认死理的人来说，就造成了北京和上海Tony的问题。
当然这与Tony的个人性格是有一定的关系的。
针对这样的状况，Pete决定先解决流程问题。
Pete与Tony的经理Jack进行了电话沟通，他们一致认为先对事不对人，先找出流程上的原因和解决方案后，再看是否需要分析人员的问题。
事实上，Jack经理也对前段时间出现的与北京的合作出现状况有所了解，也正想着如何解决。
当Pete打来电话，商量此事时，立刻积极响应。
二人仔细讨论后，决定对当前Bug处理流程里没有详细规定的部分进行细化。
首先，Bug的重现须由接受Bug的工程师来完成，除非缺少相关的必要设备时，由Jack经理发帮助申请给Pete，这杜绝了Bugfix工程师寻求软件测试工程师重现的随意性。
这也是让北京Pete团队深恶痛绝的。
14 当然，也会考虑到上海的诉求。
其次，规定当北京团队在系统里发了Bug后，发邮件通知上海team并保留现场两小时，给上海同事一个机会前来查看，以节省上海进行重现问题的时间。
但只有两小时，过时不候。
因为测试还要继续其他的工作。
在关闭Bug的流程上也做了补充。
原则上谁发的Bug就由他验证后关闭。
Bug软件开发人员不能随意关闭别人的Bug。
对于开发人员认为不是真正的Bug（有些是功能未实现，需要添加的新特性）时，由软件开发人员在Bug里注明后关闭。
流程细化后，北京上海的争执现象锐减。
偶尔还会听到Tony的抱怨，那是个别的现象了。
2.3.3访问控制问题 IT公司里，有的允许员工上班时可以上外网（），有的控制比较严，不允许员工随意访问。
在这一点上，无论O公司还是S公司（都是美国公司），都不对员工访问外网加以强制限制，在公司的员工手册上说员工可以偶尔使用公司的资源访问。
但是什么是偶尔，何时可以访问都没有明确说明。
在防火墙上也没有做任何限制设置。
这种模糊的表述让很多员工上班时肆无忌惮、无节制地在网上冲浪，QQ、MSN一直都在线，导致本职工作受到影响，从而影响了团队的绩效。
怎么办才能提高团队整体绩效，对员工有所约束又不损伤员工的自由呢？ Pete观察到员工的测试工作虽然安排得很满，但在测试运行过程中，还是有一点空余时间。
员工往往利用这些时间上网、聊天、购物、看新闻，个别的还上网读小说、玩游戏。
对此，Pete没有一刀切，他首先与各位主管协商、达成一致，即要求大家只在午休时间上网，进行必要的、短时访问；严禁读小说、玩游戏；查询与项目相关的资料则不受限制。
然后，他召开团队会议，当众宣布这条纪律。
员工无节制地上网现象少了，至少是当着Pete的面比较少了。
Pete能感觉到员工有抵触情绪，而且，员工的确还是有多余的时间没有利用起来，如何根本上解决这个问题呢？ Pete与每个员工进行单独面对面谈话（公司里常常称之为1:1），讨论每个人的兴趣、爱好和其职业的发展规划，然后给他们安排两种任务，一种是明确的、项目上的、有强制完成时间的工作任务，称之为前台任务；另一种是一个较长期的、是与本人职业发展及兴趣相关的、也与团队的项目发展相关的任务，称之为后台任务。
员工可以根据其前台工作任务的情况给出其后台任务一个大致的进度计划和安排。
Pete每2周或每3周与员工就其后台任务的进度进行小结，并在整体大会上进行公开陈述。
例如，小王对Linux内核很感兴趣，Pete就让他把与其相关的驱动的编译与调优测试作为前台任务，然后让其把跟进Linux内核的版本变化作为后台任务，定期向大家通报和讲解最新内核社区的变化，小王乐此不疲。
因为这后台任务是员工自己的兴趣所在，员工自己有很高的热情与积极性，同时，团队的工作也需要相关的知识，员工将最近的学习心得或研究体会在大会上公开展示 15 出来，一方面提高了团队整体的相关方面的知识水平，也给该成员提供了一个展示其才华的机会，让其更加自信，更加被团队认可，如此一来，团队成员除了偶尔短时上网以外，很少出现长时间在网上漫无目的地乱逛了。
因为此时，员工从内心里珍惜这些空余时间，这不仅是公司的工作时间，也是充实自己、自我成长的时间，是不能随便浪费的。
除此之外，Pete还采取如下措施从制度层面进行强化，从而形成了团队上班时间大家都认真工作，无暇做无关事情的风气。
1.要求每个团队成员每周在指定的网络服务器上（Twiki）写工作报告，详细、具体地列出本周完成的工作内容，下周的工作安排等，因为是Twiki方式，所有成员的报告，大家都可见，历史记录都可查。
主管以身作则，给普通员工带一个好头。
2.要求每个成员都做好测试记录，随时进度可查。
3.每周召开项目主管进度协调会，会上将与各主管同步各个平台的测试进度，协调各平台之间的设备、环境等资源。
4.每周召开全体人员会议，会上同事共同交流测试的具体情况及项目的进展情况。
5.与每个成员每两周进行一次单独地、面对面地沟通（1:1），了解项目情况及员工本身状况，例如其遇到的问题，无论是工作的、家庭、情绪上的等等。
6.每个平台的版本发布后，要开分析会，总结分析在测试中遇到的问题，从测试环境、测试用例、测试流程上进行分析，为什么会遗漏一些问题没测出来等，对测试用例查漏补缺。
促成团队形成一个风气，就是大家把任务领回来后，要按时保质完成。
这些步骤是促进和保障大家按时完成任务的一种方式。
此外，Pete还鼓励员工开发新的测试用例，并给予及时的认可，如颁发及时奖励（SpotAward），或让其在团体大会上做讲解，并将生成的用例进行全方面推广。
很多成员如小赵、小李，小张等就曾提交Linpack、TAC、FCoE、iSCSI等的测试用例，不仅在本部门推广，还推广到美国东部和西部的测试部门，这让员工有极大的成就感、满足感。
大家把空余时间都利用起来了，就没时间去上闲逛了。
2.3.4老周的工作安排 老周是团队里骨干、主管，每天他都是第一个到办公室，打开计算机先浏览重要的邮件，然后准备一天的测试安排，这已是他多年的工作习惯。
老周是典型的70后，是团队里最年长的，先后在IBM、HP公司里任职多年，工作经验非常丰富。
老周当初是O公司另一个部门负责应用测试的，与X86的系统集成测试有些差别，但老周调过来后很投入，加上功底好技术全面，很快就上手了，毕竟软件测试方法上是相通的。
老周来本部门之前就已经是高级工程师，调入后，在主管老韩负责的组里工作，将老韩安排的工作完成的井井有条。
老韩没有老周年龄大，对老周也很客气，这种状况持续了有一年多，如何能发挥老周自身的优势给团队做出更大的贡献呢？ Pete仔细梳理了一下团队的工作内容发现操作系统的Cert（认证）测试工作目前没有固定人员去做，是由各个平台的测试人员随机去做，轮到谁手上的任务完成了，正好需要 16 时就去做一次。
这造成测试数据零散，测试日志存放混乱，查询起来很困难。
另外，因为不是专门的工程师做，临时抽的工程师流程上不熟悉，每次都要花费时间去查阅最新的规则、搭建自己的测试环境，费时费力，效率低下，完成一个版本的操作系统的Cert测试，前前后后需要一到二周的时间。
操作系统的Cert测试在两种情况下需要测试人员去做。
一种是平台的固件如BIOS和伺服务统ILOM由于版本更新时，原已经测试过的各种OS操作系统，如Redhat、Suse、Solaris、Window、VMware等就会需要重新进行测试，然后提交测试报告给相应的公司审查，合格后，新版的固件信息就会在OS列表里公示出来。
另外一种情况是当操作系统有了新的版本推出时，就要在相应的平台上安装新推出的操作系统，进行测试，然后将结果提交相应的公司审查，符合条件后，相应的平台信息便可在其OS的兼容列表中公示出来。
无论哪种情况，OS的Cert结果对O公司的服务器产品的客户或潜在的客户都有重要的作用和影响。
客户可以通过OS公司公示的结果选购O公司的服务器，当遇到问题时，可据此要求OS公司给予技术上的支持服务，因为这款机型是在应该支持的列表中。
进行Cert测试需要对操作系统比较熟悉；需要频繁与外界进行交流沟通，如与操作系统的公司支持人员就操作系统本身的新特性、参数、测试流程的更新等进行交流。
系统管理正好是老周的强项，于是Pete找到老周，表达了希望由老周专门负责所有操作系统的Cert测试工作的想法。
老周有些犹豫，首先是因为工作量，所有操作系统的Cert测试工作量不小，即使一切顺利的情况下，一个工程师在一个测试周期里都恐怕难以完成。
如果出点意外情况，就更没法保证按时完成了。
其次，这还要求对所有主流的操作系统都要熟悉才行。
Linux他没有问题，但是，还有Window、Solaris和VMware。
考虑到Linux与VMware比较接近，于是老周答应接下所有Linux和VMware的Cert测试。
其他的操作系统，老周还需要帮手。
Pete重新评估了Cert测试的工作量，经过比对历史记录，认为老周说得有道理，一个人在一个测试周期内很难全部完成所有操作系统的测试任务。
至少还需要一个工程师才可以，那么再找个什么人配合老周呢。
考虑到前文提到的小赵，在一个项目上工作的很久了，可以调换个新岗位给她，让她有新的挑战。
于是Pete征求了小赵的意见。
Cert测试对小赵来说，并不陌生，但是专门负责并进行深入研究小赵没做过。
想到O公司的服务器经过她的测试就能出现在第三方公司的网站上，就能让客户或潜在的客户作为使用或购机参考，小赵感到有些激动，很愿意去尝试一下。
于是，Pete安排由老周带领小赵负责全部操作系统的Cert测试工作，包括协调进度、整理数据、日志、对外联络等。
目标是让这些测试数据有序、可查，并尽可能低地缩短每个操作系统的Cert时间。
这样，老周和小赵就从原来的项目上抽调出来。
他们怀着极大的热情投入到Cert的测试工作中。
首先，他们按照操作系统种类分工，安装、设置好各种OS的Cert测试环境并始终保 17 持环境处于最新、稳定的状态，从而减少了每次进行Cert测试的准备时间。
其次，积极与厂家沟通交流，时时与厂家的最新标准、流程同步。
然后，他们还开动脑筋，设计并维护一个时时更新的Cert测试列表，放在北京团队的Web主页上。
里面包含了何时、在何种配置的服务器上对何种版本的操作系统完成了何种Cert测试，相应的测试日志文件存放在哪儿、何时提交等等。
有关Cert的所有信息，在列表上都一目了然。
很快，老周和小赵的工作成果就展现出来。
首先，各平台的主管不用再操心操作系统的Cert测试了，他们只需要与老周协调好OScert的时间安排然后就交由老周，老周便把余下的事情全做了，平台的主管只需等待结果就行了。
这样算下来，除了Window的Cert需要一周外，老周他们平均2到3天便完成一个操作系统的Cert任务，效率大增。
其次，美国的市场部的同事对老周他们维护的Web网页上的操作系统Cert列表赞不绝口，以往他们要发许多的Email都不一定能拿到准确数据，现在随时就可以从列表上得到了，他们的效率也大大地提高了。
18 3案例分析 3.1理论基础 3.1.1团队建设理论 团队理论起源于二十世纪六十年代。
20世纪90年代，经营环境的复杂多变使组织的反应速度成为决定企业经营成败的关键，强调员工合作的哲学使团队逐渐成为较为流行的组织形式。
在组织行为领域，美国著名的学者斯蒂芬•P•罗宾斯认为，“团队是由为了实现既定目标而相互协作的个体所组成的一种正式群体，与一般的群体不同，团队通过成员之间的积极协同作用，使团队整体的绩效远远大于团队成员个体绩效的总和”
1。
实际上，人们对团队的观点是有些微小差异的，有的学者强调对每个成员知识技能的合理利用，也有学者强调团队成员的行为之间相互依存、相互影响，并追求集体的成功。
在管理科学和管理实践上，人们共同的看法是：团队是一个组织在特定的可操作范围内，为实现特定目标而建立的相互合作、一致努力的由若干成员组成的共同体。
不同的学者从不同的角度和标准对团队类型进行了划分，斯蒂芬•P•罗宾斯（StephenP.Robbins）把团队分成四种类型，即：问题解决型团队、自我管理型团队、跨职能型团队、虚拟型团队。
如图5所示： 图5团队的类型资料来源：StephenP.Robbins组织行为学15th 近年来被西方普遍应用的还有Suan和Diane对团队的研究成果，把团队划分成四种 1赵海霞.团队薪酬体系对团队绩效的作用机制研究[D].华中科技大学,2012.19 类型:工作团队(workteam)、并行团队(parallelteam)、项目团队(projectteam)和管理团队(managementteam)。
从团队的创建和发展过程角度，一般可以分为成立、震荡、规范化、高产和调整五个阶段。
在团队的成立阶段，要有团队创建人，完成一系列的准备工作，如团队规划、定位、目标等。
要得到上层领导的支持。
这一阶段结束时，团队每个成员都应该清楚本团队能达到的组织愿景；团队经过成立阶段后，就进入了震荡阶段。
在这个阶段成员们彼此的性格特征和行为风格的差异会逐渐暴露出来，冲突也不断产生。
团队管理者要认识并处理冲突，积极进行有效的沟通，帮助成员顺利度过震荡阶段；团队经过震荡阶段，开始走向稳定和成熟，沟通之门打开，相互信任加强，成员的人际关系由分散、矛盾逐渐走向凝聚、合作，开始建立工作规范和流程；在高产阶段，团队成员之间已经非常默契，能够及时、准确、高效地接受和完成各项任务。
这时的团队就真正成为了团结合作的集体；随着工作任务的完成，很多团队会进入调整阶段。
大部分任务型团队会解散，有的会继续工作，或许会发展新成员。
团队的效果通常包含团队生产率的客观指标、管理者对团队绩效的评估以及成员满意度的累积结果三个方面的含义。
有效影响建设高效团队的因素有四大类。
第一类是影响团队有效性资源以及其他外在条件；第二类与团队构成有关；第三类是工作设计；最后一类是过程变量，它表明团队中运作的一些事情会影响到团队的有效性。
斯蒂芬•P•罗宾斯（StephenP.Robbins）把这些因素简化成一个相对集中的模型，如图6所示。
20 图6团队的有效性模型 来源：斯蒂芬•P•罗宾斯《组织行为学》第12版 本案例研究主要是围绕着软件测试团队建设在不同阶段的主要障碍，结合团队有效型模型，分析团队领导者在使用解决方法、措施时的绩效表现和理论依据，寻求更好的方法提高团队的绩效。
3.1.2团队激励理论 激励即激发和鼓励，是指激发人的动机，鼓励人们从事某种活动而采取措施的过程。
通俗的说，即是通过精神或物质的某些刺激，促使员工产生内在的工作动力，以积极的工作情绪和状态，朝着组织所期望的目标前进。
激励是一种激发人们行为的持续的过程，是激发员工不断创造绩效的持续的过程。
对于团队来说，员工的激励机制十分重要。
激励机制的合适与否关系到了团队的绩效的好坏与组织存亡。
它的作用主要有以下几个方面：吸引并留住人才，提高组织凝聚力；充分调动员工的积极性；规范员工的行为；激励有助于个人目标和组织目标的结合；提高工作绩效。
很多学者对激励理论进行了深入的研究，下面简要介绍本文中采用的双因素理 21 论和目标设置理论。
双因素激励理论又叫激励因素—保健因素理论，是美国的行为科学家弗雷德里克·赫 茨伯格（PeterickHerzberg）提出来的。
赫兹伯格通过调查发现，一些因素如工资、工作条件等只能消除员工不满，即使改善了，也不能调动员工的积极性，不能使员工满意。
这些因素称为保健因素。
而另外一些因素如挑战性工作、工作的责任及发展机会等能够使员工感到非常满意，这类因素的改善能激发员工的满意感，有助于充分持久地调动他们的工作积极性。
他把这类因素称为激励因素。
赫兹伯格的双因素理论认为，满意和不满意并不是相互对立的。
满意的对立面是没有满意，不满意的对立面是没有不满意。
也就是说，一个人可以同时感到满意和不满意。
双因素理还论认为，员工激励可分为内在激励和外在激励。
外在激励是指外部的奖酬或在工作外间接满足，如薪酬、福利等。
内在激励是从工作本身得到的某种满足，如兴趣、成就感等。
赫兹伯格认为，外在激励只能产生少量的激励作用，而内在激励能促使员工努力工作，积极进取。
目标设置理论是爱德温•洛克（EdwinLocke）提出的。
他认为，目标设置是管理领域中最有效的激励方法之
一，员工的绩效目标是工作行为最直接的推动力。
目标对员工的激励主要有五个方面：
（1）引导工作行为，明确的目标可以使角色分配更清晰，减少了日常活动的不确定性。
（2）目标体系明确了工作的挑战性和考核标准。
（3）目标是评判各种活动和资源利用的规范。
（4）目标决定了组织的结构，将组织的各方面力量集中到实现目标上来。
（5）目标反映了组织所重视的工作，提供了计划和控制活动基本框架
1。
3.1.3团队沟通理论 沟通就是我们通常所说的信息交流，即把某一信息或意思传递给客体或对象，以期取得客体做出相应反应效果的整个过程，是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅
2。
它包括输出者、接受者、信息、渠道等四个主要因素。
著名学者斯蒂芬•P•罗宾斯（StephenP.Robbins）在1997年建构了沟通过程模型，这一模型包括七个部分：沟通信息源、编码、信息、通道、解码、接受者和反馈。
如图7所示。
1卢涛.RL公司员工激励案例研究[D].大连理工大学,2010.2崔佳颖.组织的管理沟通研究[D].首都经济贸易大学,2006. 22 图7沟通的过程 按照不同的划分方法，沟通有多种形式，不同形式的沟通有着各自的特点。
通常可划分为：正式沟通和非正式沟通；上行沟通、下行沟通和平行沟通；单向沟通和双向沟通；口头沟通和书面沟通。
有很多沟通障碍会阻碍、歪曲有效的沟通。
组织行为学大师斯蒂芬•P•罗宾斯（StephenP.Robbins）认为重要的沟通障碍有过滤、选择性知觉、信息超载、情绪、语言、沟通恐惧等六种
1。
过滤是指发送者有意操纵信息，以使信息显得对接受者更为有利。
过滤的主要决定因素是组织结构中的层级数目。
组织纵向层级越多，过滤的机会就越多。
只要存在地位上的差异，过滤活动就会存在。
选择性知觉指接受者根据自己的需要、动机、经验、背景及其他个人特点有选择地去看或者去听信息，还会把自己的兴趣和期望带进信息中。
信息超载指信息超过个体能够分类和使用的能力。
会导致信息丢失，降低沟通有效性。
情绪指接受者的情绪感受会影响他对信息的解释。
语言指沟通双方由于在年龄、教育、文化背景、专业领域、纵向层级的不同而对同样的词汇理解不同，从而导致交流的不畅。
沟通恐惧指一些人（约占总人数5%~20%）总有某种程度的沟通恐惧或焦虑，或是在口头沟通，或是在书面沟通，或者是二者兼有的沟通上，感到过分紧张和焦虑。
从而影响到某一类或某几类沟通技术的使用。
3.1.4团队冲突理论 冲突存在于社会生活的各个层面，冲突也是不可避免的。
由于学者们各自研究探讨的侧重点不同，对冲突的认识及分析也各不相同。
Deutseh(1973)从行为层面对冲突进行界定，认为冲突是不相容的行为活动，它指的是 1斯蒂芬•P•罗宾斯（StephenP.Robbins）.组织行为学[M].北京:中国人民大学出版社,2008:322-325.23 个体行为活动干涉、妨碍或以某种方式介入他人的行动。
冲突的起源可能是两方或者多方之间对立的利益、目标、价值、或对上述的误解引起，然而只有当引起了它们彼此间不相容行为时才会引起冲突。
Thomas(1992)认为冲突既是个体不和谐的反应，又是发生在个人、团队、组织间的意见、目标或利益的不一致。
斯蒂芬•P•罗宾斯（StephenP.Robbins2008）把冲突定义为一种过程，当一方感觉到另一方对自己关心的事情产生不利影响或将要产生不利影响时，这种过程就开始了。
本人非常认同这个观点，因为它是一个广义的定义，可以涵盖所有的冲突水平。
以前的学者结合自己的研究侧重点，分别选取不同的标准对冲突进行类型划分。
Guetzkow&Gyr(1954)首次对冲突进行了分类，将冲突分为基于人际关系的情感型冲突和基于任务实体的实质型冲突，即实质型冲突是与团队工作任务相关的冲突，而情感型冲突则是与人际关系相关的冲突。
Amason(1996)将冲突分为认知冲突与情感冲突。
认知冲突是与任务相关的冲突，由决策时的不同意见或分歧所引起。
情感冲突是由个人的个性与人际关系等方面的摩擦、工作中的误解等引起的
1。
Jehn(1997)则将冲突分为任务冲突、过程冲突和关系冲突三类。
从广义的角度来看，任务冲突和过程冲突都是以任务为导向的，不同的是任务冲突强调的是在任务内容和任务目标方面观点的差异，而过程冲突强调的是在任务过程上观点的差异。
综合以上观点，既使这些学者使用了不同的名称，但其定义与所述的内容却十分相似。
总的说来，以往的学者主要是从对冲突问题所针对的对象将冲突划分为“任务冲突(taskconflict)”和“关系冲突(relationshipconflict)”，或称为“认知冲突(cognitiveconflict)”和“情感冲突(emotionalconflict)”。
早期的学者认为冲突对团队存在着消极的影响，然而随着学者对冲突认识的进一步深化，认为对冲突所发挥的效应有待进一步确认检验。
冲突的早期观点认为所有的冲突都是不良的、消极的，它常常与暴乱、破坏和非理性同时使用。
冲突是有害的，是应该避免的。
20世纪三四十年代，该观点占主流。
冲突的人际关系观点认为，冲突无法避免，与生俱来的，提倡接纳冲突。
此观点在20世纪四十年代末至七十年代中叶在冲突理论中占统治地位。
冲突的相互作用观点鼓励冲突，鼓励管理者要维持一种冲突的最低水平，从而使群体保持旺盛的活力。
相互作用观点并不认为所有的冲突都是好的。
它认为冲突有两类，一类是支持团队目标，并能提高团队绩效的是功能正常的、有建设性的冲突。
另一类是阻碍团队的工作绩效、功能失调的、有破坏性的冲突。
低水平的任务冲突和中低水平的过程冲突是积极的、功能正常的。
而关系冲突则总是降低各种团队绩效，对团队成员的各种工作态度产生消极影响。
目前为止，没有一项实证 1卢红旭.团队冲突对团队绩效的影响研究-基于信任的视角[D].浙江工业大学,2012. 24 调查结果显示关系冲突会产生正向的影响作用。
这是因为关系冲突破坏了团队成员的自我管理过程，当团队内部发生与任务无关的关系冲突时，会给团队成员带来消极的情绪，影响团队成员的理性判断，从而影响团队运作，致使团队任务不能顺利完成，降低了团队绩效。
3.2问题与原因分析 3.2.1团队成立期 总监的疑惑是在团队建设初期发生的重要事件之
一，它反映了团队的沟通问题。
这也是在团队建设过程中尤其是成立阶段常常遇到的必须解决的问题，如果处理不好，轻则迟滞团队的建设或者导致项目的延误，重则影响到团队的存亡。
这里，无论是Pete还是总监做的都有所欠缺，并因此导致实验室建设延期2个月，对团队绩效产生了负面影响。
只有Julie做得比较到位，有力地推动了项目的审批进程。
如何进行充分的沟通问题是团队成立期团队建设的核心问题，在“总监的疑惑”事件中具体表现在几个方面： 首先，团队领导者忽视上行沟通，可能会给团队的初建带来困难和误会。
沟通就是我们通常所说的信息交流，即把某一信息或意思传递给客体或对象，以期取得客体做出相应反应效果的整个过程，是人与人之间、人与群体之间思想与感情的传递和反馈的过程，以求思想达成一致和感情的通畅。
它包括输出者、接受者、信息、渠道等四个主要因素。
按照不同的划分方法，沟通有多种形式，不同类型的沟通有着各自的特点。
按信息沟通方向划分，可把沟通分为上行沟通、下行沟通和平行沟通三类
1。
上行沟通是指信息由下级向上级传递的沟通方式，是企业领导者了解下属和职工意见的一种重要方法。
下行沟通是信息由上级向下级传递的沟通方式。
其作用表现在使下级明确工作任务、目标，增强责任感和归属感，协调各组织层次的活动，增强各级的联系。
平行沟通是指企业内各平行机构之间或同一层次人员之间的信息交流
2。
平行沟通可以加强各部门之间的联系、了解、协调与团结，减少各部门之间的矛盾和冲突，改善人与人之间的关系。
对Pete来说，在自下而上的沟通当中，没有及时主动地将团队的需求、原因交待清楚，以为领导的领导肯定总揽全局，知道和了解各个方面的情况，自己只需要将自己团队的具体需要量化出来，总监根据项目经费的情况酌情审批即可。
他没有意识到总监的工作经验和背景完全不同，导致总监根本不了解或不认为他提出的预算方案是合理的，根本就不认可费用支出的项目。
好在他及时将问题反馈到他的直接上司Julie处。
Julie的沟通就做得很充分，首先她不仅先问清了Lisa的疑问，而且从相关部门拿到了具体的说明，结合实际 1肖胜.小学校长与教职工沟通的现状及策略研究[D].辽宁师范大学,2007.2马倩倩.科技型创业企业成长中的团队沟通问题研究[D].山东大学,2009. 25 需要，彻底打消了Lisa的疑问，是一个比较成功的沟通。
其次，没有意识到的一些沟通障碍，影响了沟通的有效性。
有很多沟通障碍会阻碍、 歪曲有效的沟通。
组织行为学大师斯蒂芬•P•罗宾斯（StephenP.Robbins）认为重要的沟通障碍有过滤、选择性知觉、信息超载、情绪、语言、沟通恐惧等六种。
作为Lisa总监，因为级别高，时间紧（与Pete和中国有时差的关系），没有直接去收集了解事件的背景，但因对工作严谨负责，而导致项目上的合理申请没能及时批复，是要承担部分责任的。
她的表现行为正好体现出了有效沟通障碍中的“选择性知觉”。
“选择性知觉”是指在沟通过程中，接受者会根据自己的需要、动机、经验、背景及其他个人特点有选择地去看或者去听信息，还会把自己的兴趣和期望带进信息中。
这使Lisa不自觉地就用她在美国的经验来作出判断。
好在她及时从其部下找到了期望的答案，没有让项目长久耽误下来。
第
三，权力距离和沟通恐惧，加深了沟通不畅。
Lisa与Pete不是直接领导与被领导的关系，Pete因级别低，通常具有“害怕”越级沟通心理，每当与领导的领导或者更高的领导交流时，会有种惴惴不安的感觉（这在外企中是常见的现象），生怕写错了邮件给自己、自己的顶头上司带来不必要的麻烦。
从某种角度来说，这也可以算是某种程度的“沟通恐惧”。
对于Pete，因为有过前几次沟通的小错误，就更不敢多写、多问了，越是这样就越是导致总监Lisa的疑惑。
Lisa虽然从Julie处得到了清晰的答案，她还是不久就亲自飞到了中国。
Pete抓住机会向她做了一次清楚、全面的介绍，从实验室的设计、实施、配套设备管理流程到项目的进展、人员准备情况一一作了介绍。
并让Lisa进行实地现场参观，通过具体详细地介绍及现场实地的了解，Lisa有了深刻的理解，在随后的项目进程中，彼此的交流顺畅了很多。
当然，这一点上，Lisa采用了沟通渠道上“面对面的”的方式，因为它是最具丰富性的通道，有其它方式无可替代优点，避免了可能的误解。
3.2.2团队震荡期 团队在经过几个月的成立阶段后，原先的新鲜感逐渐地消失，成员们之间性格上的差异、处事方法的差异会逐渐暴露出来，冲突随之产生，这就要求学习如何进行协作，如何沟通，如何处理冲突。
团队的运行随之就进入到了震荡阶段，团队中的各种冲突逐步显现出来。
在“小赵、大李、Tony的恩怨”这个事件中，既有小赵与大李两人之间的个人冲突，也有北京与上海的部门冲突，前者是人际间的关系冲突，后者是任务冲突。
关系冲突中表现为人与人之间的敌对、不和与摩擦，它会加剧人们之间的紧张，使误解增大，从而会影响团队目标的实现。
小赵与大李的矛盾的确如此，她们的不和导致项目的延期完成，影响了团队的绩效。
而后者，北京与上海的部门间冲突是任务冲突，其本质上是有积极意义的。
26 它是因为北京和上海分别基于自己的视角对Bug流程的不同解读所导致的冲突，当它没有演变成高强度的冲突前给予及时的解决会促进整个团队的绩效。
当然，如果没有及时解决，让部门间的矛盾激化，那肯定也是会严重影响整体工作效率的。
这时，是需要团队领导者出面进行及时、有效的沟通与协调，对有争议的任务流程定义进行修正、细化，正如Pete处理北京和上海部门之间关于Bug处理流程时所作的完善和细化，这样，对日后团队的工作业绩有正面的积极作用。
冲突存在于社会生活的各个层面，冲突是不可避免的。
Deutseh(1973)从行为层面对冲突进行界定，认为冲突是不相容的行为活动，它指的是个体行为活动干涉、妨碍或以某种方式介入他人的行动。
冲突的起源可能是两方或者多方之间对立的利益、目标、价值、或对这些方面的误解而引起，然而只有当引起了它们彼此间不相容行为时才会引起冲突。
Thomas(1992)认为冲突既是个体不和谐的反应，又是发生在个人、团队、组织间的意见、目标或利益的不一致。
Jehn(1995)，Jehn&Malmix(2001)将冲突分为任务冲突和关系冲突，认为“任务冲突”关注的是任务本身，是人们对任务的不同观点而引起的冲突，比如团队成员对于所执行的任务目标、内容、工作流程、资源配置等不同观点所产生的差异。
“关系冲突”关注的是人际关系，是由个人差异如价值观差异、人格和偏好的不同等导致的消极情绪。
冲突的早期观点认为所有的冲突都是不良的、消极的，它常常与暴乱、破坏和非理性一起使用，是应该避免的。
而相互作用观点则鼓励冲突，鼓励管理者要维持一种冲突的最低水平，从而使群体保持旺盛的活力。
相互作用观点并不认为所有的冲突都是好的。
它认为冲突有两类，一类是支持团队目标，并能提高团队绩效的是功能正常的、有建设性的冲突。
另一类是阻碍团队的工作绩效、功能失调的、有破坏性的冲突。
低水平的任务冲突和中低水平的过程冲突是积极的、功能正常的。
而关系冲突总是降低各种团队绩效，对团队成员的各种工作态度产生消极影响。
目前为止，没有一项实证调查结果显示关系冲突会产生正向的影响作用。
这是因为关系冲突破坏了团队成员的自我管理过程，当团队内部发生与任务无关的关系冲突时，这会给团队成员带来消极的情绪，影响团队成员的理性判断，从而影响团队运作，致使团队任务不能顺利完成，降低了团队绩效。
对任务型冲突，在一定限度内可以有积极的作用。
然而，无论是关系型冲突还是任务型冲突，通常都是需要团队管理者及时介入处理的。
3.2.3团队规范期 当团队先后经过成立阶段、震荡阶段后，团队开始逐渐走向成熟和稳定，新进入的成员互相之间已经比较熟悉，这时要维持团队的工作效率就需要建立起良好的工作规范和制度。
在无约束的环境下，人的本性是趋向省力，自由和散漫的。
这是不利于团队效率的提高。
那么如何制定工作制度，制定什么样的制度才是有效的呢？“访问控制”事件 27 描述了这一阶段的问题。
O公司的软件测试团队在项目运行上是采用美国的模式，所以员工经过培训，就带回 了美国的项目运行流程和测试规范等。
但日常的工作规范，则具有本地属性，要符合当地政策、法规，由团队领导Pete具体管理。
在美国总部，的访问是自由的，这是因为美国总部的员工有着高度的职业精神，非常敬业，几乎很少有员工花大量时间在上干与本职工作无关的事情，所以公司的IT部门（在美国总部）根本不会限制的访问。
公司本着人性化的考虑，在中国的员工手册上没有禁止员工对的使用。
可能是由于中国的IT员工比较年轻，对上的新鲜事物比较好奇，却不太注意和区分工作时间与私人时间，随意上网。
但是，若要硬性规定在固定时间段才能上网的话，且无强制手段作为保障，是不可能起到非常好的作用。
Pete的第一个措施效果一般的原因便是如此。
Pete的第二个措施取得很大成功是由于其利用了目标设置理论和职业生涯管理理论。
目标设置理论实施的是具体、明确、通常是可见的、短期目标。
而职业生涯管理是指通过员工的工作及职业发展计划的设计，协调员工个人需求和企业组织需求，实现个人和企业的共同成长和发展，这是一种以人为中心的人本主义管理方法，是设置相对较长远的目标。
Pete通过和团队成员的单独面对面探讨（1:1），结合团队的任务需求及员工的爱好、兴趣，为每个成员设计了合适的短期及长期目标（职业规划）。
这些目标都是与员工自身的发展、兴趣密切相关，员工的热情、积极性、主动性自然就高，就不会产生抵触情绪。
以兴趣为引导，调动员工积极性、主动性，再结合一系列配套的规章制度即Pete的6条规定，效果当然是非常显著的了。
这6条规定，表面看是完成不同的任务，其实内部是有着密切的联想的。
前2条是要求团队成员独立完成的，后4条是要求团队领导与团队成员共同完成的，是基于前2条结果的，也就是说，对于前2条的结果，可通过后4条的执行进行检查、核实的，形式却不是那种郑重其事地、非常对立的，而是通过三个主题不同会议，一个单独面对面谈话（1:1）的自然方式进行的。
是比较容易被人们接受的。
做得好的，在会上会通过各种方式加以肯定和表扬，不好的也在会上明确地指出来并加以总结。
因为是大家开会讨论的形式，好的做法得以公开鼓励，大家会跟随效仿；不好的，大家会及时得到警示，避免重复发生。
这里Pete还用到了部分激励手段，如及时奖励（SpotAward）和大范围推广新开发的测试用例，这是应用激励理论的双因素理论中对员工的认可，是从物质和精神两个层面进行激励，效果当然好。
3.2.4团队高产期 测试团队进入到高产阶段，团队建设已经逐渐走上正轨，团队的发展比较平稳。
越来越多的项目，转移到中国北京测试团队的手上。
如何更好地发挥每一员工的作用从而让团队绩效更上一层楼的问题凸显出来。
28 在“老周的工作安排”事件中，Pete敏锐地感觉到了在当前的模式下，老周的工作效能没能发挥到极致。
如何进一步发挥老周的工作效能，激发并提高团队整体的工作绩效，同时还能改变当前操作系统Cert测试的混乱、低效的局面？ 首先，Pete进行了工作的再设计。
在罗宾斯的团队有效性模型中，第三类是工作设计的相关因素。
它包括的变量有工作的自由度、自主性、任务的完整性、重要性等。
对整个团队来说，Pete让Cert测试工作完整地独立出来，对原有的工作流程进行重构，使相关的测试环境、人员、数据相对集中并稳定下来，从而为团队的Cert工作的高效率创造了条件。
对老周来说，Pete让其承担了对O公司服务器来说非常重要的一个环节—做Cert测试，让其有了很强的责任感，从而激发了他的能动性和积极性。
对小赵来说，工作的转换让她减少了工作的枯燥感且对她提出了新的挑战，对于刚刚工作不久、充满工作激情的小赵来说，正是求之不得的。
这也极大地调动了小赵的积极性和工作热情。
其次，Pete针对团队成员的特点设置目标。
爱德温•洛克（EdwinLocke）认为目标设置是最有效的激励方法之
一，是员工行为的直接推动力。
明确而具体的目标能够提高工作绩效；困难的目标，一旦被人们所接受，会比容易的目标带来更高的工作绩效；有反馈比无反馈能够带来更高的工作绩效。
对于老周和小赵来说，完成对自己公司服务器的Cert测试并将结果公示到第三方的网站上，这是一个非常明确、可以达到的目标，而且目标实现的标志是非常清晰的--即能否通过第三方的审查并公示出来，这对公司来讲是非常重要的。
所以，每一次成功地完成Cert测试并让结果公示出来都是对老周和小赵的极大的鼓励。
加上来自公司内部赞扬的Email，这些正向的反馈极大地激励了老周和小赵，从而使的他们取得了很好绩效。
最后，Pete善用激励因素，激发团队成员的主动性和创造性。
赫兹伯格的双因素理论认为，一些因素如工作的挑战性、工作的责任及发展机会能够使员工感到非常满意，员工参与决策、管理过程对员工有激励作用。
首先，Pete打算让老周独自承担Cert测试任务，老周考虑后没同意，经过协商后，Pete同意老周的建议，多安排一个工程师与其一起完成这项任务。
老周的建议得到了尊重。
其次，老周可以自己自由地与平台主管协商工作进度，安排工作完成时间。
这些决定、管理的自主性以及看到的实时反馈（结果被公示）满足了老周他们的自尊、责任、成就、认可和成长的需要，给他们提供了内部工作动力，这符合双因素理论中的激励因素（内部因素）的描述或定义，的确带来高的工作绩效。
29 4对策与建议 4.1团队成立期的全面沟通 事实上，沟通问题往往贯穿于团队建设的各个阶段，包括项目的实施过程，而不仅仅是团队的成立阶段。
团队的成立阶段的主要目标是“要完成团队方案的勾画和其他准备工作，一般要花费几个月的时间。
”，这一阶段结束时，团队的每个成员都应该清楚本团队能够达到的组织愿景。
这当然离不开沟通了。
那么如何做？本文的经验告诉我们要从以下两方面做起。
一方面在团队建设初期，要建立全方位的沟通。
作为团队领导者，在沟通上会有三个方向，即自下而上、自上而下、同级沟通。
无论哪个都不能掉以轻心。
自上而下的沟通常用于给下属介绍工作、分配任务、发布或解释规章制度或指出下属的问题所在等。
这时具体清晰，有时效的沟通就比较重要。
常用的要领有：A多说小话，少说大话。
B不急着说，先听下属的意见。
C不说长短，不议论他人。
D不要厉声指责。
E广开言路，采纳意见。
自上而下的沟通之后，要及时收集反馈，以此来核实并确保下属得到的是你所期待传达的信息。
自下而上的沟通通常发生在给领导写报告、提供信息、对同事、对组织或项目提出意见或建议时。
这个方向上的沟通更要及时、准确还要客观。
原则上是当天的答复当天完成，不拖延。
交代问题要全面，不要想当然地认为领导可能了解事件的来龙去脉、前因后果，就像前文的“总监的疑惑”里的那样。
如果需要较长时间，当天完不成，要马上回复什么时候可以完成。
有必要时，在时间过半时交代进展情况。
让领导知道你的进度。
另外，有相反意见时，不要当着外人，当面顶撞。
这无助于问题的解决。
还有，在向领导反映问题的同时要准备好自己的解决方案或建议，供领导决断。
作为团队领导者，水平沟通指与其它团队的同级别的人员的沟通。
这时往往代表本组织与另一个组织进行对话、协商。
因各有各的立场，此时应该基于双赢及互惠互利原则，以诚相待。
尊重对方才能得到同样的回报，彼此尊重才能平顺地沟通。
另一方面在团队建设初期，还要建立全通道的沟通。
目前在外企的软件公司里一般有如下的沟通方式：通告（电子网站上）、电子邮件、语音邮件、电话、电话会议、事先录制的演说、现场演说（Allhandsmeeting）、单独面对面交谈、视频会议、网络桌面会议系统和及时通信等。
不同的方式适合不同的沟通场合。
在这些方式当中，进行单个个体的交流时，单独的面对面交谈（公司里常常称之为1:1）效果最好，尤其是要沟通关于模糊性的主题。
这是因为面对面的沟通传递的信息最量大， 30 它能同时提供包含语言、体态、面部表情、手势、语调等信息，还可以得到及时反馈，无论是语言的还是非语言的。
大范围的或与人员众多的大部门进行有效交流的方式是现场演说（公司里常常称之为AllHandsMeeting），类似国企里的全体成员大会。
大家可以面对面地进行交流、现场互动，提问和回答问题，但不如一对一进行的深入，有些时候放不开。
常常需要的是AllHands结合一对一来进行。
现场的听众可以通过发言人的语调、表情，理解发言人的真情实感并与发言人互动。
确保双方都能相互准确理解对方所要进行的表述。
对于日常的频繁的项目交流，有条件的可以运用视频会议、电话会议及网络桌面会议系统的方式来进行相关讨论。
视频会议最好，有声音有图像。
网络桌面会议系统不能看到与会人员的画面，但可以共同看到要讨论的项目文件、数据，比纯粹的只能进行语言交流的电话会议好。
单个人之间的交流，除了最好的一对一方式外，电子邮件、语音邮件、电话都可以。
语言邮件用得较少，电话快捷但不如邮件正式和易于记录和保存。
及时通信可以作为辅助手段用于个体间的非正式交流，现在很流行。
这样，无论对上，对下还是平级之间采用前面提到的原则和相应的沟通渠道必然降低误解的可能性。
从而大大提高团队的工作效率和业绩。
4.2团队震荡期的冲突管理 团队在进入震荡阶段后，会出现各种各样的冲突。
我们如何应对冲突呢？根据冲突的变迁，有三种观点，本文比较认可“相互作用的观点”，即维持最低水平的功能正常的，具有建设性的冲突，消除功能失调的，有破坏性的冲突，从而使群体保持旺盛的生命力。
一方面，努力化解关系型冲突。
小赵和大李之间的冲突就是典型的、个人与个人之间的不和与摩擦的关系型冲突。
如果纵容放任它，可能引起连锁反应，加剧团队中人与人之间的矛盾，影响相互间的理解，从而降低团队的工作效率，阻碍团队目标的实现。
对于此类的冲突，就应该像Pete那样及时处理、化解掉。
不能让冲突升级和加剧。
这种冲突是属于功能失调型的，对团队是百害无益的，要坚决、迅速地处理。
另一方面，运用中低水平的过程和任务冲突。
对于中低水平的任务和过程冲突，如本案中的北京与上海在Bug处理流程上的冲突，其本质上是有积极意义的。
当它没有演变成高强度的冲突前给予及时的解决会促进Bug处理流程的完善和细化。
对日后团队的工作业绩有正面的积极作用。
因为它激发员工们针对不同的观点进行讨论和协商，有助于找到高效的方法来完善相应的流程，从而使团队的工作水平及业绩更上一层楼。
这种冲突是属于功能正常的冲突，是可以加以引导和利用的，在一定程度上是有利于团队的发展。
31 4.3团队规范期的机制建设 在团队的规范化阶段，主要目的是要建立和形成良好的团队工作规范和工作流程，这个阶段也是形成和建立团队文化的最有利的时期。
建立良好的团队工作方式是要有一定的方法和技巧的。
如果不切实际地、武断地硬性规定，往往会引起抵触，效果不好。
但是，如果将其转化为员工内在的行为目标，让其从内心进行认可，如本案“访问控制问题”事件里Pete的做法，长期目标与短期目标相结合，即员工兴趣爱好与具体工作任务相结合让员工有了积极性和主动性。
随之建立的6条规则便得到很好的实施。
谈到公司的激励机制，在O公司，团队领导的权利是有限的，也就像Pete那样，给优秀团队成员申请一下及时奖励（SpotAward）但数额往往比较小，其他方面就力不从心了。
像O公司这种大型公司，其绩效考评及激励系统是很全面的，该系统会根据每个员工对应的工作职位码列出一套应具备的能力列表。
每个员工都要在每个财年结束、下一个财年开始时，在系统里填写下一财年的目标、达到目标需要的资源、成功与否的衡量标准等信息。
每个季度结束，要求经理对员工的各个能力目标进行评测、打分，跟进先前设定的目标。
但这套系统在执行时是有些问题的。
其中一个问题是其激励机制不够灵活。
目前O公司中国研发员工的所有经济来源包括国家标准的五险一金、年基本工资、财年奖金三部分。
部分人会有少量股权，这对中国大陆地区的员工来说，可以忽略不计（因不方便交易）。
财年的奖金是根据全公司的效益来定额度。
O公司的财报年年增长，但奖金却少得可怜。
同样在中国CPI增幅超5%时，薪酬的增加总体却固定为2%，而且限定只能30%的员工有此机会。
这对合作精神很好的团队来说很不公平，因为团队每一个人都认真努力了，硬要分出30%来，其他人什么也得不到，还会指望下一年那70%好好工作吗？还有一个显得不灵活的问题是O公司每年的那30%一定要选贡献大的员工，这样一来，资深工程师、项目主管的贡献肯定比年轻的工程师、普通成员大。
按O公司的政策，每年都会是同样的一批员工获得那极为有限的加薪，而这点加薪往往对基数已经很高的项目主管或资深工程师来讲起不到激励的作用，因为对于大基数来说加薪幅度太低了，而对普通的、资历浅的员工来讲，很渴望加薪。
同样那些数目对于他们来讲可是一笔不小的收入，激励效果不可同日而语。
希望O公司在薪酬调整上、奖金发放上不再一刀切，作硬性的规定，这对员工的激励非常地不利。
O公司激励体制的另一个问题是一切统得太死，让一线经理无用武之地。
经理不能根据团队发展和稳定的需要制定薪酬调整比例和幅度、不能申请Offcycle（在年度加薪之外的加薪）。
Pete发现有团队成员有离职倾向，Pete知道其有加薪的诉求，但Pete被领导告知不可申请Offcycle，但严格的比例规定，让有离职倾向员工的预期远远没有达到，即使后来通过很长时间的层层审批后，终于拿到反offer（针对挖人公司开出的offer而开出的反offer，目的是让被挖人员通过接受新开出的、往往在福利待遇上比挖人公司开出的offer 32 要优越的反offer，而愿意继续留在原公司），离职人员往往去意已定，不能挽回了。
4.4团队高产期的流程设计 合理的任务划分能充分利用现有的资源，减少重复投入，也有利于员工发挥最大的工作效能。
在操作系统Cert测试独立出来由专门的工程师负责后，测试环境稳定，工程师熟练，这就为提高Cert测试的效率做好了准备。
进行工作流程设计要注意以下几方面：员工参与、目标具体明确、反馈及时。
1.员工参与在进行团队目标细化、工作流程设计时，首先要充分吸收有经验的、资深员工的合理化建议，增加员工的参与机会和程度，比如Pete与老周协商Cert的人员配置时，尊重了老周的建议，多配置了一名工程师。
对老周来说，他的责任与参与的需要得到了满足，调动了他的积极性，有利于日后工作效率的提高。
2.目标具体明确将整个团队宏观的、长远的、模糊的目标进行细分并落实到具体的员工个人身上时，要遵循我们常说的SMART原则，即目标必须是具体的（Specific）、可以衡量的（Measurable）、可以达到的（Attainable）、和其他目标具有相关性（Relevant）、必须具有明确的截止期限（Time-based）。
3.及时反馈新的工作流程及工作任务划分必须考虑到能够给相应员工提供及时的反馈，与SMART里的M有点重复，但这里强调“及时”两字。
这有利于员工自己能及时感受到其工作成果被接受与否。
比如老周与小赵能通过其测试结果是否被第三方公示了、被同事查询到了而感受到其工作成功或失败。
在测试过程中，类似的情况有很多。
比如安排测试人员参加Bug讨论会，项目进展讨论会等。
会上，其他小组对测试人员报出的Bug的提问、质疑会促使测试人员认真对待自己发的每一个Bug，问题描述是否清晰、重现步骤是否详细、是否误报等等。
参加这方面的会后，几乎都不再需要经理再来对测试人员强调要如何发Bug了。
33 5结论 通过前面的几个事件的描述和分析，我们不难看出，在团队建设的不同阶段，会遇到不同的、影响团队效率的问题，我们总结和归纳一下O公司软件测试团队的经验和不足。
在团队成立阶段，要建立全方位、全通道的沟通机制。
这是贯穿整个团队建设的所有阶段，在成立阶段尤其重要。
通过前面的几个事件不难看出沟通的重要性。
无论是总监的疑惑还是小赵与大李的恩怨，都离不开沟通。
要增加上下级之间，同级之间的信任和理解就必须加强沟通。
我们要充分利用好现有的各种沟通渠道，选择恰当有效的沟通方式，进行充分地沟通。
在团队震荡阶段，需进行冲突的有效管理。
在团队建设过程中，我们常常会遇到各种各样的冲突和矛盾。
总的来说，大部分会像前文提到的小赵和大李，上海与北京之间的人际之间、组织之间的矛盾和冲突。
对百害无益的关系矛盾要彻底清除，而对任务型冲突要限制在一定程度内，及时加以利用和处理，否则也会影响团队的绩效。
在团队规范化阶段，应细化目标，建立柔性规章。
在团队的规范化阶段，应将团队的目标细化并与成员的兴趣、爱好及其职业发展规划结合起来，使员工从内心深处认可和赞同其目标；减少生硬、强制性的条款，代之以灵活、易于接受的方式，并加以正向的激励。
在团队高产阶段，进行合理的工作流程设计。
团队的高产阶段，为提高团队的整体绩效，除了人员、设备、环境因素外，还要考虑团队的当前工作流程是否合理、是否得到优化。
要对团队的整体项目或目标进行进一步细化或分解，找出合理、有效的工作流程安排，就像Pete改变美国的测试模式，把操作系统Cert测试独立出来那样，对原有的流程进行改造，从而在团队整体绩效上产生了飞跃式提高。
软件测试团队建设过程中，有很多要考虑的因素。
如团队的人员、团队的设备、团队工作流程、团队目标、团队文化、团队激励、团队的沟通与冲突、决策、绩效等等。
本文就团队发展的几个不同阶段，分别选取了几个影响团队有效性的案例加以讨论分析、抛砖引玉。
不同的团队建设，遇到的问题顺序可能不同、也可能遇到的问题会有所不同，但总的来说，离不开本文讨论的团队的冲突、团队沟通、团队的激励及团队工作流程的优化等几个方面，可以借鉴本文方法和经验。
如果从公司层面再加以配合，如在激励方面，那将更大地提高团队的绩效。
34 参考文献 [1]陈娟.科研团队成员知识共享行为意向研究[D].杭州电子科技大学,2012.[2]崔佳颖.组织的管理沟通研究[D].首都经济贸易大学,2006.[3]戴昌均.人力资源管理[M].天津：南开大学出版社,2008.[4]弗雷德曼，威尔逊.第五项修炼教程：学习型组织的应用[M].北京：经济日报出版社, 2002.[5]胡琨,刘浩,刘涛.初议软件测试[J].科技广场,2008,(05):241-242.[6]贾硕林,颜寒松.团队精神[M].上海：上海财经大学出版社,1999.[7]李宝元.人力资源战略管理：案例教程[M].北京：清华大学出版社,北京交通大学出 版社,2010.[8]李秀娟.组织行为学：先知而后行•行必有所为[M].北京：清华大学出版社,2012.[9]梁杰.软件测试工程师薪资走高[N].市场报,2003-7-25.[10]卢红旭.团队冲突对团队绩效的影响研究-基于信任的视角[D].浙江工业大学,2012.[11]卢涛.RL公司员工激励案例研究[D].大连理工大学,2010.[12]路易斯•R•戈梅斯-梅西亚，戴维•B•鲍尔金，罗伯特•L•卡迪.人力资源管理[M].北京： 北京大学出版社,2011.[13]马蒂•布龙斯坦.团队管理[M].北京：机械工业出版社,2006.[14]马倩倩.科技型创业企业成长中的团队沟通问题研究[D].山东大学,2009.[15]麦克莱恩.提高团队协作能力：创建信任与高责任意识的团队[M].北京：电子工业出 版社,2011.[16]斯蒂芬•P•罗宾斯（StephenP.Robbins）.组织行为学[M].北京:中国人民大学出版社, 2008:322-325.[17]王刚,李迎,白祎花.软件测试人员应具备的素质[J].软件导刊,2011,(02):34-35.[18]王娇娥.关于教育生活中沟通缺失问题的思考[J].现代交际,2011,(12):83-84.[19]王挺，卫宗荣，赵玉建.信息时代下的虚拟研发团队管理[M].北京：中国轻工业出版 社,2010.[20]伍传林.FTH公司成都厂区生产导入项目团队管理研究[D].吉林大学,2012.[21]肖胜.小学校长与教职工沟通的现状及策略研究[D].辽宁师范大学,2007.[22]辛海.团队为赢[M].北京：中华工商联合出版社,2007.[23]姚裕群.团队建设与管理[M].北京：首都经济贸易大学出版社,2006.[24]余世维.打造高绩效团队[M].北京：北京联合出版公司,2012. 35 [25]张雷,李红光.团队管理新模式[M].北京：中国时代经济出版社,2006.[26]赵海霞.团队薪酬体系对团队绩效的作用机制研究[D].华中科技大学,2012.[27]2011年中国软件测试从业人员调查报告[EB/OL]./ html/08/n-811608.html,2012-04-13.[28]关于冲突与谈判-百度文库[EB/OL]./view/09d007a1 bff12184ca.html,2012-09-12.[29]软件测试的发展现状与前景[EB/OL]./view/c4ecfa22a5 e9856a561260dc.html,2013-01-25.[30]我国测试行业之现状分析[EB/OL]./92/n-232092.html, 2011-03-17.[31]2012年中国软件产业经济运行现状分析[EB/OL]./news /201301/25/25.shtml2013-01-25. 36 致谢 三年的边工作边读书的学习生活即将结束。
回首往事，心中颇多感慨，感激之情难以言表： 首先，我要将我深切的敬意献给我的导师，她在我写作论文的过程中给予了我非常大的帮助，不论是论文的篇章布局、论述逻辑，还是论文的标点符号，她都仔细、认真、不厌其烦地多次指导，使我受益颇多。
在这里向导师表示深深的感谢！ 其次，感谢北师大经济与工商管理学院的诸位老师对我精心培养和严格要求，使我在理论学习和实践水平上都有了长足的进步。
同时他们严谨治学的态度、对学问的执着追求以及对学生极其负责的精神，使我受益匪浅。
最后，要感谢所有同学，在这个和睦，团结，热心的集体里，我不仅愉快地度过了三年难忘的学习生活，还结交到了很多有理想，有才干，有抱负的好友。
谢谢你们!
作者2013年5月 37
声明：
该资讯来自于互联网网友发布，如有侵犯您的权益请联系我们。
相关文章
