互联网测试经验和管理杂谈（测试团队管理）

   非常惊讶上一篇文章已经有200多个读者了，第一次写一些工作的经验竟然还有这么多人看。笔者最近比较懒，主要原因没有啥思考的结果，所以没更新，但是我一定会继续写下去的，哪怕就为了那几个点喜欢的读者。

    今天讲讲测试团队的管理，笔者入行时间并不长，到现在也就4年多的工作经验，但从事管理以及两年多了，在团队搭建，梯度培养，跨团队沟通等方面有一些拙见，再次跟大家分享下。由于站在角度的不同，看完本文的管理者和工程师会有不同的理解，再此也提前说下，我所述的一切的利益点是站在一个公司的维度进行阐述。

    先阐述下行文思路，管理的对象-->管理的目标-->管理的方式-->管理的思考。

    【管理的对象】

        测试工作的管理的对象是什么呢？这问题有点废话的感觉，当然是测试工程师和测试开发工程师了，我的表述的点在于这些人的诉求，人只是工程师角色的载体，人的诉求才是管理对象的关注点。这个道理就有很多管理者没有弄明白，觉得管理就是把活分给他，不要出问题就万事大吉了，如果工程师们遇到这样的管理者，那你还是尽快离开吧。在现阶段互联网飞速发展和员工年龄端普遍在90后的大背景下，单纯的关注工程师能不能完成工作这一个维度已经无法全面的评价一个工程师了，因为可能他什么做的都很好，最后被新技术淘汰了，他的错只是因为他老了。所以关注管理对象的未来发展，无论是在技术上还是项目上，甚至在一些软实力，比如沟通能力，ppt能力，逻辑思维能力，都远比最后在项目最后那个结果好很多。让测试工程师在你的团队有成长，在软实力和硬实力各方面的提升都会对你的团队和工程师本人有长足的收益。

PS：做好管理的第一步，先了解团队工程师每一个人的成长诉求，这远比薪水诉求重要的多。

    【管理的目标】    

    当你明确管理对象是谁的时候，那么你就自然之道你的目标是什么了。管理对象是工程师的成长诉求，而不是工程师这个人，那么你就带着大家的诉求，拆分细化目标，比鞥针对细化目标给出解决方法，最后达成想要的目标。我想这时候就有人要问了，管理目标不是完成上边分配的项目工作吗？不是根据公司的战略做相应的项目吗？没错，你说的这些都是管理的目标，但这在笔者看来是过程目标，不是管理者对团队的目标。因为管理者要是做到了团队成名的成长目标，这些过程目标自然就会达成，而达成的会更好。工程师在做项目的时候不是想着这事公司的项目，这是哪个老大的项目，而是想着这是在达成成长诉求过程中的一次次实践而已，实践越多，经验越丰富，离目标就越近，当一个团队打造出这样的氛围，团队还会有怠慢工作或者无为撕逼的状况吗？

PS：每当有些管理者跟我说，团队激励太难做了，每次请大家吃饭，还发红包大家就是没有工作状态。其实管理者抓不住问题的关键点是最可怕的事情，工程师的状态不是搞几次团建就能起来的，人的本性都是利己的，但是不可能那个公司就是给钱，一直给钱，就算有工程师也不会满足的，因为人的欲望是无限的。但是人的成长诉求在某一阶段是清晰可见的，这就是管理者的机会和体现管理者能力的时候。

【管理的方式】

    管理的方式比较多了，初期组建的团队怎么管？管理者空降怎么管？管理者的上级怎么管理（管理好自己的上级很重要）？再次就不一一展开了，笔者发现每次自己找的话题都比较大，每一个展开聊都要很久。这次就说说大家遇到比较多的情况吧，就是在10~20人的测试团队，管理者算是不新不老的这个场景吧。

    从一个团队的稳定到达成目标的维度触发，唐僧的团队是比较理想的模式，这也是很多管理学的书说的比较多的了，我就不展开了，但是往往每个管理者看到的都是想找到他们的孙悟空，而忽略沙和尚和白龙马的角色。

    所以我列一下一般团队存在的一些角色，我尽量列全，因为对于管理者而言，团队拥有什么样的人在一定情况下并不是由自己决定的，比如团队有老板家的亲戚，这就会对你管理工作带来很大的成本。

    （老油条）

这种员工一般是工作年限较长，自己早已遇到天花板了，从个人意愿和能力都不愿意去突破天花板的。优点：工作经验丰富（不止是专业技能），在一个公司就职时间较长，公司内有一定人脉基础。缺点：懒惰，负能量传播多余正能量，做芝麻大点事都恨不得全公司都知道。

    （老黄牛）

这种员工一般是只会被动的接受管理者分派的任务，而且不管什么样的活，不抱怨就是干，但是往往得到的并不是管理者想要的。优点：任劳任怨，也有向上突破的渴望，但失败于自身能力或者没有找到正确的思路。缺点：不会总结，不会向上反馈，属于死扛型，实在扛不住就会离职了。

   （毕业3年内的新人）

这种员工一般是有迫切的成长欲望，干活不怕苦不怕累，胆子比较大，也是最容易出现大问题的。优点：成长意愿迫切，想被认可。缺点：经验缺失，盲目自信。

  （孙悟空）

这种员工是可遇而不可求的，也就是这样有的管理者自己充当这个角色。其实孙悟空这样的人如果团队有那对管理者比较幸运了，没有那就抓紧去培养一个。优点：业务和技术能力都很强，沟通和软实力也兼具。缺点：容易自傲，对团队氛围有时有负面影响。

举一个笔者在管理中让上边各特点员工发挥各自优势的例子。近期有个在业务上非常核心的功能迭代，研发想趁机把老框架的缺点统一解决下，思路基本是要重构，还要支持此次产品的需求。笔者做法是让老油条带着一部分新人去了解此次变更的业务，让孙悟空带着另一部分新人去跟研发一并了解底层框架的重构，让老黄牛去把老油条和孙悟空对业务和技术的积累总结到wiki，并去把这次项目涉及一切的边界测试case执行完成。由于项目改动比较大，团队涉及大部分角色都参与了。

【管理的思考】

   怎样评价一位管理者做的好不好呢，我看到一句话非常认可，“如果一个团队管理者很‘闲’，那么这个团队就很好”。怕大家理解有误，我把这个闲字打了个引号。其实也很好理解，管理者要站得更高才能看的更远，如果天天在一线忙的不可开交，不仅下边的人成长不起来，自己也成长不起来，思考的时间太少，那团队肯定就好不到哪去。所以管理者要培养自己的梯队，让他们帮着你去观里一线的事情，但是你不能脱离一线，你要时刻关注一线的动态，要多看少说多做。多看是发现一线的问题和梯度管理的问题，少说是少在一线发表自己的见解，尤其在具体项目上，你不了解具体情况你说了工程师执不执行，执行就带沟里了，不执行没法跟你交待。多做指的是多做解决一线困扰的问题，比如测试环境，跨端沟通，项目下边推带不动了，工程师效率低的地方就是技术工作发挥优势的地方，这都是管理者要做的。

    最后总结下，经过笔者的实践，要想做好管理，抓住问题本质，让工程师有自我成长，让每一个人反哺团队。文章中很多地方说的不是很透彻，后续会有针对性的讨论。读完后欢迎各位留言评论，我们一起思考，一起成长。