这是鼎叔的第十七篇原创文章。
行业大牛和刚毕业的小白，都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》，大量原创思考文章陆续推出
4 月 3 号晚上，鼎叔作为嘉宾参与小道消息播客的直播分享节目，和主持人老徐和兔子畅谈测试管理的那些事。本文是分享的第二部分，包括：跨部门合作，对管理者的选拔，团队成果汇报，线上事故追责等听众关心的热门问题。

第一部分内容看这里：https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483800&idx=1&sn=96aa54572e672ec236b8bfb3dc9b9ac7&chksm=c24fb4faf5383dec9369e842487b711d55121fb8fd6d08fc4f9fb092c3ecdebf72ee501d6e7e&token=676623611&lang=zh_CN#rd

01

跨团队跨部门合作的经验分享

测试团队在所有项目中通常都是一个不可或缺的角色，并且上线前都要测试通过再发布，所以我们测试团队会面临较大的沟通压力。甚至很多时候，我们发现事情不对，但是到了测试这一环已经没有办法，只能扛住。这些都是测试这个角色在很多公司面临的一个困境。

个人建议可以从如下几个方面着手走出困境：

1）前瞻型的思维，也就是所谓 “测试左移” 的思想。有些公司甚至直接说：测试就是最后兜底的。如果承认了这一点，做为测试我们在所有的沟通中都会处于下风。所以我们要努力地做沟通的转型和改变，拒绝做最后一道网。我们的终极目标，或者说努力的优先级，一定是把风险往前推——这是我们跟所有其他角色沟通时的根本逻辑。

把风险往前推，就意味着把质量推到需求评审，推到开发的自测，推到技术设施建设，而不是靠后面的人工测试——那么就需要其他团队的支持。如何让大家都支持这一点？怎么把质量内建的道理灌输给所有人？有一个起决定性作用的角色，那就是高管，高管是我们跟其他角色沟通的基础。但是跟高管沟通之前，要准备好方案，准备好能反映现状的数据，才能够说服高管接受。另外要把如何解决问题的方案展示给高管看：比如需求评审，一定要完成哪几件事情，才能进入开发；一定要做完哪几件事情，才能进入测试。

把这些都准备好以后，就容易得到高管的支持。

2）一定要双向思考，要站在别人的位置上思考。这一点其实不仅适用于测试，各个角色和团队都适用。

比如说你是一个做中间件平台的团队，你想推自己的东西，别人却不支持，为什么呢？无非就是别人觉得你会影响他的业绩。所以在沟通前，要先站在别人的角度上想一下他们为什么要用你的平台？会有什么样的好处？如果你让他们觉得可以分摊利益，就会更容易接受。其次是想办法提前打消对方的顾虑，如果对方可能担心你的平台的可靠性，准备好报告来证明自己平台的质量是达标的。再其次，给对方提供清晰明确的合作方案。如果能做到这几步，跨部门沟通的效果会提高很多。

3）沟通不一定要一步到位。可以先劝对方试一试，如果效果好再进一步扩大合作：这个是跨部门沟通的一个精髓。

4）底线的沟通。我们需要联合应急响应部门（比如故障处理部、客服部）制定 SOP（Standard Operating Procedure 标准作业程序），在公司做一个红线的宣导：明确在哪个阶段出现了怎样的状况，各个相关部门要停下手头的工作，或者说部门接口人要先暂停手上的工作，第一时间响应问题；以及要在多长时间内要给出解决问题的方案。

总结一下就是向上达成一致，让老板为你站台；站在对方的角度，与其他团队做好双向利益的沟通，同时把对自己的影响降到最小；采用阶段性的，灰度的合作；最后一个就是制定 SOP，拉齐对红线及处理方式的认知，做好应急响应的流程。

02

上级选拔测试团队管理者的关注点

基于不同公司的规模和公司文化，这个问题没有绝对的标准答案。

对于行业里处于 Top 位置的大公司或者优秀的公司，在选拔管理者时，通常对专业程度是硬要求，在这个基础上要求有管理 sense。因为优秀的团队和公司，有相对更多优秀的人，如果挑选一个专业上比较弱的人做管理者，其他的同学可能会不服：你好像并不太懂，为什么还要发号施令。除非说你有其它的过人之处，让别人无法质疑你。比如说创业做了一个很牛的产品，然后被大公司收购了，原来的创业者成了大公司的管理者——如果有这么强的背景，在大公司是可以被破格提拔的。但是通常而言，在强大的公司或者是人才密集度比较高的公司，专业程度都是基础，然后再判断你是否适合做 leader。

也有很多的公司，相对而言它的市场竞争力没那么强，也相对比较难找到或者留住专业过硬又很擅长管理的人做管理者。

综合以上情况，我觉得成为 leader 的基础条件是正确的价值观：站得稳行的端，对员工相对是公平的，能稳住整个团队。把团队交给这样的管理者，做为上级是比较放心的。

在这个基础上，同时学习能力比较强。哪怕当下专业程度稍微差一点，或者是转行过来，暂时对某个专业领域不是很熟悉，但只要虚心好学总是能够成长的。当然，理想状况上，还是希望 leader 的专业背景深厚为佳。

我在这里也分享一下自己提拔管理者的做法：

第一：不会凭空出现一位 leader

绝对不是今天发现某个团队缺一位管理者，那我赶紧提拔一个人上来——做为一个高级管理者来说，这种做法是不称职的。作为一个高级管理者，要建立自己的人才梯队：每年甚至每半年就要刷新一下自己的梯队。这个梯队包含：自己下级成熟的 leader，backup 的 leader，还有培养一年，甚至两年就能上岗做 leader 的人。这样你的管理就非常安稳和健康。

第二：比较透明的选拔机制

如何进行透明化呢？一个是述职，我们会让候选人参加有部门核心人员在的述职会。这样的话，如果其他的 leader 都认为这个后备 leader 确实是最靠谱的，那么 ta 升职也不会引起其他人的不满。我个人在这方面是比较谨慎的，尽量避免部分同学认为我是提拔嫡系或者倾向老员工，不够公平公正。

还有一个机制，是包括腾讯在内的很多大公司都在实行的，就是做 360 度评估问卷。这个问卷收集到的信息也是非常宝贵的。因为一般而言，老板对即将晋升的人的评价都不会太差，但是这个人的同事或者下属可能有不同意见。如果有不同意见出现，是需高级主管认真审视这种情况，可以暂缓提拔，不要着急去任命一些可能不太符合要求的 leader。

03

如何看待被团队成员顶替了自己管理者的位置？

——要想走得更高更远，就要有一个更豁达的格局和心态

我认为不能只看短期效应和短期利益。过于看重短期利益，会阻碍管理者树立良好口碑。为什么呢？因为一个管理者，如果把怕被下属顶替位置的想法埋入了自己的管理哲学，就会在招人和团队建设上有失公正，不敢让自己团队里有潜力高冲得快的成员。比如一看到有人比自己强，就把他们赶走或者不招，个人的境界就止步于此。或者对于被从其他团队派过来的下属，觉得这个人对自己造成了巨大威胁，但又不能拒绝 ta 加入，后续就会暴露出一系列管理上的变形。诸如：不培养这样的团队成员，刻意给 ta 负面评价。最终会导致管理者自己在管理上的口碑被急剧拉低。

如果豁达一些，敢于招可以替代自己、比自己更强的人到团队里——我觉得这种管理者未来五年十年的职业发展会非常出色。就我亲身经历而言，之前我认真提拔或者培养的 leader，如今在各个公司很多都是总监，或者高级别的 leader，我们的关系一直都非常好。虽然现在大家不在同一家公司，他们如果有合作的意向，或者是有人才推荐，都会找到我；包括我写个人公众号这件事情，他们也会很支持。

我们在职场上奋斗个十年二十年的最大收获是什么呢？其实就是自己的口碑。做测试到一定程度，换不同的工作（在物质上）其实不会对自己的生活有太大影响，但是口碑就不一样了。如果你真的能从众多的人才中找到一个高潜，从 ta 刚毕业一路培养 ta 到高级工程师再到 leader，或者把一个核心骨干培养到总监，或者你的下属去了别的公司成为非常重要的管理者——这些都是你值得你拿出来说的成绩，而且对方也会非常感激你。反过来，如果你看到很优秀的就 Pass 掉了，从老板的角度，他会觉得你心胸比较狭隘，同时你也失去了一个跟优秀同事共事的机会。

并且从我的个人经历来说，所有我帮助过他们成长的核心骨干，也给我做了贡献。什么贡献呢？例如我很多的职业成果——包括我写的文章，或者是我要出版的专业书刊——这背后其实有很大一部分是他们的功劳。我只不过是做为他们的 leader 带着他们一起干活，但这些实践背后的思考和技术实现，不可能都靠我自己完成。代码不可能都是我写，那么多详细的设计方案不可能都是我来做。作为一个团队管理者，我要做的就是把先进的案例引进门，输出自己的思考，核心骨干成员才是把自己的想法落地的关键角色。所以你在培养他们的同时，就积累了自己的人脉。同时丰富了你自己的案例，凭着这些案例，可以去任何一家公司找到更好的岗位。

所以我们一定要从在职场上的长期发展和人脉口碑的角度来看待这个问题，千万不要狭隘的觉得用了这个人自己的位置就不保，其实并不会出现这样的事情。如果你真的遇到这种情况，那我觉得你的老板本身可能有问题，就算你离开这家公司也不可惜。而且我看到更多的案例是，你培养出一批的优秀的管理者后，你的老板也会更看重你。

04

做为管理者，如何把握与团队成员关系的度？

对于这个问题，在不同的时期，我的答案会有所不同。在这里分享一下我现阶段的认识：

首先，我们不能够教条的来理解这个问题。有些所谓的管理者，他的一条成功经验是：作为 leader，一定要跟下属保持距离，要维护威严。但我觉得作为管理者，首先要明白，自己的职位不是用来显摆和威压下属的工具。现在这个时代，特别是零零后，他们最讨厌的就是管理者仗势欺人，用职位欺压他去做一些他并不认为正确的事情。

一个靠谱的 leader，首先能够以理服人，你的道理能够让八零后、九零后、零零后都理解——这是沟通的基本功。在这个基础上，你能够跟团队成员在很多方面达成共识，才能够让沟通非常顺畅。并且沟通可以随时进行，可以随时跟团队中不同层级的成员沟通。不能因为我手下有一百个人，所以我只跟 leader 沟通，不跟普通员工沟通。只要我觉得有必要，不管是下属 leader 还是普通员工，我都会直接跟他们尽快沟通。而且作为普通员工，如果有机会跟他们的 leader 或者是高级 leader 面聊，他们对这个 leader 或者高级 leader 的好感和信任度会急剧提升。

如果你只是在会上说一些虚头八脑的东西——所谓正确的废话——就不够真诚。你在这个团队中的地位和跟员工之间的联系，就会非常弱。

鼎叔给测试 leader 的小忠告

如果你在沟通当中能够给员工一些指点，那沟通的效果就更好。最怕一些端着型的 leader，自己在专业上并没有什么独特的见解，纯粹是因为自己是个 leader，就要定期说下自己的大道理和对下属提出批评。这种虚张声势的 leader 口碑也不会好。

各位已经成为或者想要成为测试 leader 的同学们，首先要保证自己的专业度，这个专业不一定是写代码厉害，而是对测试理论有深刻理解，掌握什么才是好的测试的标准，能够抓住员工的痛点。其次要掌握一些说服员工和 “教练 “员工的方法论，并付诸实践。

05

如何将团队价值可视化地展现给上级？

作为一个管理者，一定不是给老板体现自己工作有多苦，而是要想办法体现功劳和真正的价值。你如果向上表现自己加班多，老板又真的只关心你加班，那你以后只能不断加班和内卷。

如何体现功劳和价值呢？

第一：不能空喊口号、自我标榜，一定是用数据说话。

比如团队最近很辛苦地工作，做为团队管理者，找机会给老板汇报时，不要刻意强调大家加班的情况，而是拿之前和现在的数据做对比来体现成效。并且把所做事情的复杂度阐述清楚，让老板看到我们用了多少种方案，做了多少项改进，申请了多少个专利等等。

还可以用别人的输入作为佐证。比如你的合作伙伴，比如开发，他们是怎么称赞我们所做的项目的。或者跟其他团队 PK 时，我们给了一个建议，对方接受了并且很真诚地点赞。还有用户对我们的认可。这些体现我们工作成果的相关 “证据 “，都可以在老板面前呈现。

第二：证明团队所做的事情是促进增长的动力。

除了说明团队的辛苦带来了业务的增长，另一方面也要能列出具体做了什么达到了增长的效果。列出的事情不一定直接带来了增长，但是能证明相关性也可以。

做为 leader，要定期带着团队做复盘，看一看每一阶段结束后是否比上一个阶段更好。多做几次复盘，跟老板交流的时候就能说到老板关心的重点。比如每双周或者每个月有个复盘，过三个月以后跟老板汇报时，你就会有一个非常清晰的汇报逻辑：我们第一阶段是这个水平，第二阶段是另一个水平，第三阶段达标了——进展过程可信度更高。并且通过这样一个自我对比，你能找到重点，清楚做了什么带来了进步。

带四五个人 VS 带二三十人

带二三十个人肯定比带四五个人对管理者的要求更高，其中最显著的是：要求管理者在识别人才、识别高潜以及明智授权方面的能力更强。其它方面的要求可能差不太多。当你带一个二三十人的团队时，一定要从这二三十人中找到几位能组成管理梯队的人。其中有能胜任小组长的人，直接帮你代管团队；有能力但不足以胜任小组长但是可以帮忙做一些横向工作的人，比如组织培训、专题研讨等。然后这些人就是你的左膀右臂，你只要定期跟他们做沟通和同步，细节工作由他们把握。这样你的管理工作就会轻松很多，相当于直接管理的还是四五个人。

06

测试团队管理者如何应对线上事故追责？

先说一点：专业的公司肯定不会这么幼稚地针对线上事故单纯追责。专业的公司会认为，只要是事故，那通常都是涉及多个角色的问题（除了极少数恶意操作，或者没有按照 SOP 进行的操作）。大部分操作问题实际反映出我们的应急响应，或者自动识别的能力不足。所以线上事故通常都不是单角色的问题。另一方面来说，很少有要测试独担责任的问题，为什么呢？比如一个 bug，首先这个 bug 是开发写出来的，不能只怪测试没测出来 bug，反倒说这个 bug 跟开发没关系。所以说，就算测试担责也一定是共同担责。除了一种情况，就是用例评审的时候已经明确说了要测的点，当时测试的人就是不测——这种极端情况确实都是测试的责任。

基于上文所述，做为测试我们首先不要惧怕共同担责。只要是能够通过测试发现的问题，我们就要勇敢地承担责任。一起担责其实也是好事，既避免大家觉得项目里对测试的要求低，也可以通过分析线上事故提高测试用例设计的水平。有些测试 leader 会出于保护团队成员的角度，不愿意 “背锅 “、担责，这样其实不利于提升测试团队用例设计能力。我个人认为，只要确定是增加测试用例就能发现的问题，我们可以承担一个次要责任。

但是也有一些情况下，我觉得可以完全不担责。比如完全没有规律的随机性问题，现阶段哪怕给测试提要求也没办法避免，除非像谷歌那样投入高成本建设一个专门的随机性测试团队。再比如线网配置这种属于人为错误的，还有一些是软件本身就是模拟两可的。

除了是否担责，我觉得测试团队可以做一些数据分析的工作。对用户反馈的所有问题进行梳理，来判断哪些是有效缺陷：有效缺陷是需要改掉的软件的 bug。哪些并不是缺陷，只是个建议，甚至就是一个吐槽——这种就直接过滤掉。还有一些是内容问题，比如说内容质量低俗之类的，这个不算真正的软件 bug，但还是要拎出来留做后续的二次分析。

对于有效的软件 bug，我们再来分析是否可以通过特地的测试用例来覆盖，那么这部分可以当做漏测来看待。所以说有效缺陷的子集才是漏测的问题。但我们不是只关心漏测的部分，也可以分析非漏测的问题寻找改进办法。如果是通过开发的一些白盒测试可以发现的，那我们就要求开发增加这种白盒测试；如果是通过配置管理可以优化的，我们可以要求配置管理的同学进行优化；或者是现阶段测试环境无法支持的，我们可以要求工具团队提供更好的测试环境。

总而言之，如果我们测试团队要提升，一方面我们要分析漏测，另一方面对于非漏侧且有效的 bug，我们可以推动大家一起解决。这才是从事故当中吸取价值的比较完美的应对方法。

点击这里，收听完整音频节目 https://www.ximalaya.com/sound/521665526?source=m_jump