突如其来的合并
今年年初，公司因业务调整，将我带领的项目组（称为A项目组）与另一个团队（称为M项目组）合并成一个新的研发部门，由我出任研发部门经理，做部门管理。整个部门人也不多，三十多个人，有项目经理、需求、架构、开发、测试外加设计。M项目组的人员总体上偏少偏弱一些，A项目组是新项目，高峰时约40人，且部分人员技术水平较高，导致M项目的同事组有被“吞并”的感觉；再加上M项目组的项目经理因个人原因需要离开项目组，导致全组人员失去带头人，更加没有方向。虽然我自己并没有吞并别人的感觉，但如果让大家带着情绪去工作，肯定不好，所以这是我作为部门经理首先要解决的一个问题。
先做了解和沟通
刚接手时，我连人名都报不全……于是我请人事给我每一位同事的简历，了解个人背景，做到对每个人的背景资料了然于胸。紧接着我向原项目经理了解每个人的工作情况及具体的工作职责，这样做到了对整个项目人员的初步了解。
对于新项目经理的人选，有领导建议“空降”，而我经过慎重考虑，决定从原项目组内部提拔任用一个人，好处是对原来的工作内容、方法、人员都很了解，也容易被项目组人员接受，如果能力不能完全达到，我可以从旁指导，度过刚开始的适应期。
另外有空我就参与M项目组的会议，了解大家的工作状况，时不时说一些鼓励的内容，希望大家放下包袱。
在这一切做到后，我花了一天的时间，与每个人做了一次单独的沟通交流。对话的内容无非是介绍项目组现状，部门现状，部门及个人未来发展的前景，宣布新老项目经理的工作变化，询问工作困难等。这样做，既增进了我和同事们的了解，也让同事把心稍稍放下，同时在正式宣布新项目经理的人事任命前，进行了沟通，满足了管理学中所说的中国人“会前沟通”的特点。
保持团队工作现状
M团队的工作方式、项目管理方式在一些地方和A团队不太一样，作为一个程序员出生的管理人员，很多人都追求“完美”，“眼睛里揉不得沙子”，“看不惯不一样的地方”。但此时我要求自己应该让团队保持现状，因为存在即是合理的，我需要了解M团队的优点，让互相的优点在两个团队中融合、生根。
慢慢的，M团队的优点体现了出来。他们有增进感情的周例会，有细粒度的版本测试……我及时的将这些优点在部门中传递，有的方法在A团队中使用，使得M团队的同事比较有成就感，觉得被认可；同时，他们也更容易客观的看待A团队优点以及我的一些个人风格，当我们一步步的做出改变的时候，进行的会更加顺利。
在刚接手时保持团队的工作现状有利于团队的平稳过渡，同时也有利于我发现团队的优缺点，做到取其精华，去其糟粕。
逐渐的改变
在熟悉和了解之后，一些问题也会暴露出来，此时需要作出一些改变。在改变之前，需要和新任的项目经理及骨干员工做好沟通，降低“改革”的阻力，这样才易于推进和成功。
首先要改变的是项目进度的跟踪方法。原先的进度跟踪方法一般是一周2次，而我要求对于版本任务做到每天跟踪一次，重点任务半天跟踪一次进度，这样可以提前预防进度风险。这一点由于项目经理是新上任的，所以推进起来阻力很小。
其次是改变系统设计任务的人员分配方法。M团队虽然人员不多，但是资历老一点的程序员承担比较多的设计，而新程序员主要从事编码工作。这样做确实可以保证一定的质量，但是面对的版本任务越来越多，编码人员的吞吐量已经到达了极限。此时我需要建立“外科手术式”的设计工作方法，即让一个资深的程序员主要从事重点工作的设计以及底层代码的编写，其他人员均投入到一线从事设计（简单任务的设计）、编码工作。所有人的设计都需要由核心人员审核，保证设计质量。这样做增加了工作的吞吐量，减少了部分工作的沟通成本，从而提高了效率。此外，对于新程序员来说，承担一部分设计任务，也是对自身能力的锻炼，大家还是乐于接受的。
第三点改变在绩效考核上。作为一个有一定规模的互联网公司，绩效需要和各自的KPI绑定，这点公司之前一直做的不够好，考核比较模糊。我在A团队摸索出了一套客观透明的任务考核方法，在公司内部基本得到了认可，所以我也将其推广到M团队。面对一套以多劳多得，促进成长的透明绩效考核方法，团队成员都表示认可。此外，为了考核更加客观、准确，我要求项目经理在分配任务，安排工作计划时要比从前更加细致，这也算是额外的改变。
总结
所有的沟通、妥协、改变都是为了团队能够尽快融合，工作的节奏能够一致，形成合力，这点我们最终做到了。做管理首先要做到的是沟通和妥协，这样做使自己可以客观的看待事物，找到合适的解决方法，同时也可以在自己与团队成员之间建立信任，信任是一切活动的基础。
管理者也是导师，给人以支持和帮助，这样更容易与陌生的团队成员建立信任，也能建立自己的人格魅力。同时，威望不是靠管出来的，而是从点滴交流、帮助做起，在对方心中逐渐生根、发芽的。