编者按：空降机会越来越多。如何处理好各种关系让自己如鱼得水，而不是空降不成反被干掉，或功成后被企业辞掉？亲爱的读者，也欢迎您来稿来电，联系本文编辑（MSN：bunnybunny505#hotmail.com TEL：021-33680077*265），一吐为快。
【IT168 专稿】空降兵也叫伞兵，是形容从飞机上带着降落伞从天而降的士兵。在企业发展过程中对某些引进的高级人才冠以这样的称呼。关于企业对空降兵的管理和身为空降兵的人员如何处理好工作，是企业发展和个人职业发展都非常关注的问题。
笔者曾经参加过这样的专题讨论会，和企业的管理者以及身边朋友多次聊过这样的话题。笔者自己也有过多次空降兵的经历，也是在交足学费后才能游刃有余。现对2005年初笔者所在的深圳公司引入空降兵的案例进行分析，希望供广大同仁参考。
笔者所在的公司以核心员工两倍的薪水引进了一位人才，公司的技术总监出任研发部经理，负责公司战略技术的研究，希望能有个信任的人才顶替他的位子。
高薪人才小张以空降的方式，被直接任命为公司战略产品的项目经理，其权限可以调动公司开发部、测试部和实施部的所有人员以及部分研发部的成员。对熟知业务和客户需求的市场部和销售部的关键人员可以通过预约的方式会谈，在财务报销上也开出了相对大的空间。
可以说，公司从上到下，都会非常配合他的工作，而且技术总监仍在背后帮助主持这公司的战略产品项目。公司高层希望通过小张成功领导这次战略产品的开发，让技术总监退出具体业务层和基础技术层的工作，而技术人员拟分成事业一部和事业二部，由他和现在的部门经理来共同负责。
公司非常隆重地开场，将其任命为战略产品的项目经理。新官上任第一天，小张就请大家去相对高档的酒家，体味小资生活。这样的合作方式自然大家都喜欢，项目中的相关人员基本上参加了，对高级人才小张的关系自然也亲近了不少。
新官上任三把火，找准了点火的地方，却烧反了方向，让小张逐步陷入孤立。
小张在团队管理上开始烧的第一把火是：提出管理的标准，希望大家都能按业界的标准和规范进行，实行CMM标准管理。
会议上，小张滔滔不绝地讲了近四个小时，会议的中心是标准化作业和标准化管理。内容包括请假人员的管理，以保证项目组始终有80%以上的人在岗；对源代码编程的规范和注释的说明，以保证代码的易读和内部可移植性；对项目组成员工作进度的管理，保证对每个人的进度都有所了解的同时，控制住项目的进度；对开发中出现的BUG和问题的管理……
从团队的管理谈到需求调研、需求分析、概要设计、详细设计、开发编码、测试、实施、维护、软件升级等软件生存周期中的每个环节。会议开了整整一个下午，因为会议时间太长的缘故，大家最后吸收的效果反而不多。随后的工作也是按照这样的标准进行。
小张这会议的主旨是非常必要的，统一大家的思想和认识，提高团队凝聚力，提出团队工作标准。只是太长没有了重点，而且小张一副高高在上的态度主导一切。期间部门经理委婉地暗示小张，让公司一直想培养的两个核心级员工出任副职，以帮助他工作。小张一口回绝，说他一个人就可以了，使得这两位同事心里不快。初衷虽好，执行过程却不尽如人意，这是小张的第一个失误之处。
小张烧的第二把火是需求文档的标准，目的是让公司的文档统一标准，方便客户、公司的管理层、市场部、销售部、测试部以及开发部、实施部所有相关人都能看得懂文档。
小张组织大家对项目的需求重新分析，同时提出需求按新的文档格式进行整理。因为小张本身比较固执，听不进同事的话，而且和同事说话时总是以命令的语气，系统分析员也就按其提出的格式重新编写需求说明书。然而按新的格式要求编写的需求说明书，除了小张和技术总监认同外，其他同事却全部反对。
项目经理们当场表示不认可，还加上一句话：这格式就这项目用，他们所负责的项目绝对不采用这样的格式。于是经过近一个月三次修改，中和采用了一种文档的格式。因为小张每次都认为是定格的格式了，以命令的语气要求系统分析员按新格式编写文档。同样需求的文档系统分析员重新写了三遍。
系统分析员的工作阅历和技术水平以及项目经验是公司中最强的，远在小张之上，只是空降的小张并没有花太多的心思去了解大家的阅历。系统分析员的脾气倒很好，没有说什么抱怨的话。但同事们看在眼里，对小张主持工作的能力开始质疑和不信任。
之后的工作中，甚至在某些方面出现了公开场合的不配合，反而是系统分析员事后找这些同事谈话，说支持小张的工作实际上是支持公司的元老——技术总监的工作，而且大家都是为了公司发展得更好而相互支持、相互帮助的。
其实小张的初衷并没有错，建立一个标准统一的文档，方便公司内部交流，同时也方便客户的理解和确认。小张为建立标准格式文档，专门去书店买了两本需求管理的书，除了每晚加班整理资料，连周末也在研究标准的制定。
然而在制定标准时，却太过依赖书本知识，加之固执和草率，在没有和同事特别是系统分析员交流的情况下，就强制要求大家执行，效果达不到预期，使得在核心层同事中失去了同盟，开始走向孤立。
小张第三把火是编程规范和标准，提出了比较好的编程规范，完全符合业界的标准。这也是技术总监一直强调的事情。
公司的元老早期都是写C出身的，在采用面向对象的编程工具时，所有的编程规范仍然沿用C的风格，包括各变量的命名和参数的格式；而早期的同事也因多年潜移默化，认同并继承了这样的编程风格，使得所有的源代码看上去都有些不伦不类，难读懂，自然更不易维护了。有些老总初期写的程序，连他本人现在都不好理解，更不用说新同事了。
小张参考他以前所在公司的编程规范和标准，严格要求项目组成员按其标准执行。因为小张之前所在的是个大公司，有很好的架构，所有的程序填鸭式地照搬就可以了。而我们公司还处于发展中阶段，技术框架和底层没有那么高的水准。
但小张的思想还停留在之前那家公司，规定编程人员原则上不能修改编程标准格式和规范，如果要增加其中任何一个实体的一个方法或属性，都得向小张提出申请。于是编写程序时，难免会遇到很多底层无法支持的东西，而不断和小张讨论，最后按小张的要求将原本二三十行的程序扩了一倍多，代码繁杂。
小张这样的管理方式，理论上是相当不错的，可实际工作中，其直接下属当着小张的面向笔者抱怨，说其编程规范不实用。打开源代码让笔者看，笔者也很意外，一些非常简单的程序因为要采用标准的格式，变得繁琐复杂。
比如，数据库表中的每个字段都作为一个参数，编写一行代码。要知道之后的核心业务中，我们的主表就有近百个字段，一套软件的表对象都在百张之上，近万行的代码都要复制粘贴再修改，工作非常枯燥且无聊，难保不出错。
笔者当场提出，为何不在底层用递归的方式编写程序，解决每个字段都占用一行代码这种非常无效的编程方式，同事回答说这不符合小张的标准。
小张的这第三把火，应当说是烧进了管理层的心里，但执行时却忽视了一线的编程人员。因为程序在结构上变得整齐、严谨、规范、直观、易读懂、易维护，但程序编写和调试时却非常低效，代码多了好几倍，容易出错，跟踪麻烦和低效。同样，编程的时间比正常的工作进度慢了一倍以上。因为小张的固执，不少核心级同事以各种借口逐步淡出了项目组，程序编写没有了核心员工的参与。
