笔者曾经参加过这样的专题讨论会，和企业的管理者以及身边朋友多次聊过这样的话题。笔者自己也有过多次空降兵的经历，也是在交足学费后才能游刃有余。现对2005年初笔者所在的深圳公司引入空降兵的案例进行分析，希望供广大同仁参考。

　　笔者所在的公司以核心员工两倍的薪水引进了一位人才，公司的技术总监出任研发部经理，负责公司战略技术的研究，希望能有个信任的人才顶替他的位子。

　　高薪人才小张以空降的方式，被直接任命为公司战略产品的项目经理，其权限可以调动公司开发部、测试部和实施部的所有人员以及部分研发部的成员。对熟知业务和客户需求的市场部和销售部的关键人员可以通过预约的方式会谈，在财务报销上也开出了相对大的空间。

　　可以说，公司从上到下，都会非常配合他的工作，而且技术总监仍在背后帮助主持这公司的战略产品项目。公司高层希望通过小张成功领导这次战略产品的开发，让技术总监退出具体业务层和基础技术层的工作，而技术人员拟分成事业一部和事业二部，由他和现在的部门经理来共同负责。

　　公司非常隆重地开场，将其任命为战略产品的项目经理。新官上任第一天，小张就请大家去相对高档的酒家，体味小资生活。这样的合作方式自然大家都喜欢，项目中的相关人员基本上参加了，对高级人才小张的关系自然也亲近了不少。

　　新官上任三把火，找准了点火的地方，却烧反了方向，让小张逐步陷入孤立。

　　小张在团队管理上开始烧的第一把火是：提出管理的标准，希望大家都能按业界的标准和规范进行，实行CMM标准管理。

　　会议上，小张滔滔不绝地讲了近四个小时，会议的中心是标准化作业和标准化管理。内容包括请假人员的管理，以保证项目组始终有80%以上的人在岗;对源代码编程的规范和注释的说明，以保证代码的易读和内部可移植性;对项目组成员工作进度的管理，保证对每个人的进度都有所了解的同时，控制住项目的进度;对开发中出现的BUG和问题的管理……

　　从团队的管理谈到需求调研、需求分析、概要设计、详细设计、开发编码、测试、实施、维护、软件升级等软件生存周期中的每个环节。会议开了整整一个下午，因为会议时间太长的缘故，大家最后吸收的效果反而不多。随后的工作也是按照这样的标准进行。

　　小张这会议的主旨是非常必要的，统一大家的思想和认识，提高团队凝聚力，提出团队工作标准。只是太长没有了重点，而且小张一副高高在上的态度主导一切。期间部门经理委婉地暗示小张，让公司一直想培养的两个核心级员工出任副职，以帮助他工作。小张一口回绝，说他一个人就可以了，使得这两位同事心里不快。初衷虽好，执行过程却不尽如人意，这是小张的第一个失误之处。

　　小张烧的第二把火是需求文档的标准，目的是让公司的文档统一标准，方便客户、公司的管理层、市场部、销售部、测试部以及开发部、实施部所有相关人都能看得懂文档。

　　小张组织大家对项目的需求重新分析，同时提出需求按新的文档格式进行整理。因为小张本身比较固执，听不进同事的话，而且和同事说话时总是以命令的语气，系统分析员也就按其提出的格式重新编写需求说明书。然而按新的格式要求编写的需求说明书，除了小张和技术总监认同外，其他同事却全部反对。

　　项目经理们当场表示不认可，还加上一句话：这格式就这项目用，他们所负责的项目绝对不采用这样的格式。于是经过近一个月三次修改，中和采用了一种文档的格式。因为小张每次都认为是定格的格式了，以命令的语气要求系统分析员按新格式编写文档。同样需求的文档系统分析员重新写了三遍。

　　系统分析员的工作阅历和技术水平以及项目经验是公司中最强的，远在小张之上，只是空降的小张并没有花太多的心思去了解大家的阅历。系统分析员的脾气倒很好，没有说什么抱怨的话。但同事们看在眼里，对小张主持工作的能力开始质疑和不信任。

　　之后的工作中，甚至在某些方面出现了公开场合的不配合，反而是系统分析员事后找这些同事谈话，说支持小张的工作实际上是支持公司的元老——技术总监的工作，而且大家都是为了公司发展得更好而相互支持、相互帮助的。

　　其实小张的初衷并没有错，建立一个标准统一的文档，方便公司内部交流，同时也方便客户的理解和确认。小张为建立标准格式文档，专门去书店买了两本需求管理的书，除了每晚加班整理资料，连周末也在研究标准的制定。

　　然而在制定标准时，却太过依赖书本知识，加之固执和草率，在没有和同事特别是系统分析员交流的情况下，就强制要求大家执行，效果达不到预期，使得在核心层同事中失去了同盟，开始走向孤立。

　　小张第三把火是编程规范和标准，提出了比较好的编程规范，完全符合业界的标准。这也是技术总监一直强调的事情。