测试经理只是个title。小一点的比如测试主管，大一点的如测试总监都有类似的困境。看似有资源，但发现测试资源打散在业务线，对于实际任务工作任务的掌握在相应业务线的研发leader或者如PMO这样的角色，好一点的是自己还能给组员打一些绩效，做的不太好的发现绩效自己也未必能完全做主，一些业务自己也不了解，不太能插上手；所以一些测试leader会强推一些测试平台和工具，这样自己这块就有产出了，但随着行情下滑，公司愿意投入在测试技术这块的成本也越来越少了，这些测试平台停工或者维持现状似乎对于公司也没啥影响，这无疑对部分测试leader来说基本盘都会丧失。总结一下容易被架空的测试经理行为特征：
- 对于公司项目参与程度低，只做任务分配和进度收集。
- 忽视项目本身的业务测试问题，只做技术测试。
- 喜欢组织团队分享，但自己不输出，流于形式和汇报。
- 与项目经理以及业务部门交流少，存在感低。
测试leader自己也困惑，不清楚自己的定位是啥，因为测试这行业的立身之本似乎就不明确，业务？技术？沟通？流程管理？每一项似乎都沾边，但是你陷进去其中一项你会发现测试管理未必就能做好，这种情况是你看到了事情本身，但缺乏一个管理者的底层逻辑去指导你，底层逻辑是你的管理思维，关于业务，技术沟通这块是呈现出来的部分，这篇我先聊聊做leader的管理的几个核心的思维能力。
测试管理最重要的是满足公司核心利益，拆分下说是满足兄弟团队的共同利益以及自身的利益；是的，我把兄弟团队放在前面，比如开发团队和业务团队，对于测试团队的属性咱们不用特别高估，本身就不属于第一生产力，所以他的价值就是把核心技术团队的价值维护好。那对于测试leader如何把这件事情做好呢？从思维上来说，这涉及到三个管理逻辑，同级管理，向上和向下管理。先说个前提，这里说的管理，不是说组各种利益团体，而是如何把事情攥在手里，并且做好。
同级管理我们经常遇到一个问题是跨部门合作好像蛮难的，为什么难？因为别人觉得是你自己的事情，为什么需要用我的资源帮你达成？但事实上，最终能够产生价值的事情从来不是一个团队的事情，这部分前提是要找到共同的目标价值；比如我拿精准测试来说，一些改动和实验是需要研发配合，这件事情做之前就需要拉上研发一起，找到共同的价值诉求以及制定捆绑的kpi；而不是遇到问题了，去找别人，别人才知道你在做这件事情，而且还需要来抽资源帮你，这部分资源和时间也不在我原来的规划里；像这种情况，你觉得你能够做好的概率有多大？做不完说别人不配合你？说团队没有技术追求？我相信这样的话很多人听过，但可以反思下自己的做法是否也能优化下。
提醒一下，不要因为你觉得跟同级管理有利益竞争就放弃合作，这样等于给自己画了一个句号，尽量做到我中有你，你中有我，寻找双赢的机会。
向上管理对于测试来说向上管理尤为重要，小到每天站会，大到部门例会，测试往往发言的机会都不会很靠前，所以主动向上管理就变的比较关键，向上管理有哪些注意点呢？
- 不要觉得自己做的事情越多，就一定会有结果，做的事情和价值要能呈现出来，且有一定的思维高度的总结。
- 不要闷不吭声，绝大多数leader还是喜欢能表达的同学，不要去吐槽，能说问题也要能说解决方案。
- 遇到机会，敢于承担，风险预控，提前暴露，不要还没做就怕做不好，0-1的经验很关键。
- 站在leader的角度看问题，甚至可以到N+2，当思维趋于一致时，就容易与leader产生共鸣，这样的人leader自然喜欢。
向下管理
- 不要跟下属一起去吐槽人或者事情。吐槽本身就不积极，会带偏团队节奏，而且吐槽是最容易，最“爽”的事情，会传染，如果你作为leader喜欢吐槽，团队可能会被带垮。
- 学会沉淀和分享，不要流于形式，真正从问题出发，从方法到方法论的提升，让团队成员能够看到你的认知水平，提升自己的影响力。
- 参与核心项目，不要只做任务的传递者，分析问题并解决问题，有公信力的leader是带队打仗打出来的。
- 管理的核心要素在于事情梳理，在平时一些无关紧要的事情上，不要喜欢用职级去干预。
- 作为leader保持谦虚，遇到自己不了解的技术问题或者业务问题也是正常的，虚心请教，不要说放不开面子，面子是一些同学的死穴。
如果上述的一些情况你有很多都没做，那你作为leader还是需要加强自身的管理能力，不要被每天的会议带的晕头转向，然后只做一些任务的简单分配，这样的管理者价值不大没有粘性，一旦公司成本收缩，你这样的角色要不要就难说了。每天睡前留一些独立思考的时间，把团队和个人目标达成都能想一想。下面是具体的一些实践思路，我以前写过，测试管理也要学会下地干活儿，通过实践才能更好的优化你的管理思维，才能更容易达成管理目标，脱离事情本身做管理，会极易产生脱节。下面我再阐述四点。
技术：作为一个团队的管理者，各种技术细节很难事必躬亲，但是你需要有基本的认知，比如你们公司的微服务架构，各种组建解决什么问题，能不能自己搭建一套实施一下，这样的技术成本不是很大，但可以很大的提高你的技术对话能力，比如业务一些开源的自动化平台以及框架，部署试用发现其优缺点和适用性，这些小尝试都可以提升技术视野且性价比也是高的。如果没有一定的技术基础，你怎么与相同level的开发或者运维去对话呢？而你没有对话能力，不仅是你个人的问题，必然也会带来团队的被动。
业务：业务能力在于整合资源，识别风险，保证项按时交付。虽然简单一句话，但是需要你具备多个能力，首先是对内的管理机制，在资源相对紧缺的情况下，组内能不能有backup快速上手，对外有没有分析造成项目紧张的原因去battle更多的资源。而且我的建议是虽然你是管理，但最好带一支核心的业务，这样看问题才会更全面，做决策才更有依据，而执行的颗粒度你也是可以自己控制的，一些管理者由于每天琐事的插入和自己的惰性会逐渐远离繁琐的业务，这一点是不可取的。对于测试管理来说，这个岗位本身就在被稀释，当你跳槽了，是不是还是管理属性或者管理属性会不会打折扣，是打个问号的。
质量体系：这事情的前提也是认知，不知道大家有没有一种感觉，往往在一些作坊式的公司，测试层面从单点解决问题往往比较难，通过一些零碎的资源去做一些长期建设的工作，也不太能保证收益，包括软硬件环境，团队组织，这是一种现状，有的同学经历过多家公司会发现在一些公司很难做成的事情在另外一家公司就是基本操作，比如说业务测试中的单元测试，比如说冒烟执行的通过率，比如说性能测试的数据需求分析，这一点最大的区别已经变成基本操作的公司都已经在做执行质量内建的实践，而很难做成的公司别说实践，他们可能连质量内建的意识都么有，或许根本也不了解什么是质量内建。对于我们测试人员来说，说小一点会影响我们的工作环境，工作环境的好坏会影响我们的心情；说的大一点，一些局面没有打开，有可能会影响我们的职业生涯。当你所在的公司是我说的小作坊模式时，其实你是存在大量机会的，可以认真思考下质量内建这件事，我稍微引申下：
测试左移+持续反馈+测试右移+全员参与测试左移：尽可能在测试本身活动开战之前就接入测试，包括在需求和设计阶段（形成规范+落地实例）。持续反馈：保持高度的信息透明和及时的信息反馈，才不至于由于信息盲区导致的风险变大（尽早接入+固化流程）。测试右移：项目交付后的线上运营也是至关重要的一环，获得用户的反馈并不断的迭代优化（灰度发布+用户调研）。全员参与：质量内建是项目全体成员都需参与并为之负责，结合自身和公司情况，先做好自己（日志+告警+资源），形成影响力，再落地体系。
沟通：沟通这个事情看似简单，但其实是多种能力多种要求，也很重要，在一些公司，会沟通可能比你会做事情会更重要。做好沟通需要你有一定的情商，同时也要求你的技术认知和业务认知能够做到同频，这样才能深入的去讨论各种问题的细节。这些跟我上文是一脉相承的。
