小道消息跟鼎叔聊聊测试团队管理（第二话）

兔子🐰 · 2022年04月15日 · 最后由 li3453576 回复于 2024年03月15日 · 7996 次阅读

本期嘉宾鼎叔 @dylan.zhang ：互联网/通讯行业大厂技术总监，高级架构师，测试专家，敏捷教练。公众号「敏捷测试转型」作者，在 TesterHome 论坛著有同名专栏《敏捷测试转型》。
主播 / 老徐，兔子
策划 / 小道消息播客节目组

先来三个小链接，大家各取所需

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 的好感和信任度会急剧提升。

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

05 三十五岁以上的测试工程师何去何从？

关于这个问题，我在自己的文章里也有提及（聊聊没有 35 岁焦虑的《人月神话》）。先援引文中一句话来概述这个问题：如果你理解软件发展的规律，那我觉得三十五岁的恐慌实际上是没有必要的。下面展开说下我自己的看法：

首先从技术层面上来说，肯定还是需要 35+ 的工程师。

为什么呢？与软件工程复杂度的根源有关。软件工程的概念复杂、合作复杂、多变性和复杂的因果关系，是决定其复杂度的几个本质原因。对于一个毕业生，或者入行不久的工程师，在什么方面可能比老员工更擅长呢？无非就是他们掌握了更多新的工具，掌握了更新的编程语言，还有他们更愿意加班。但他们对软件工程本质和内在的理解相对还是欠缺的，并且他们所擅长的东西都不是能够让软件更强大的主要动力。

在这个前提下，什么样的人能够成为三十五岁以后继续发挥价值的工程师呢？就是能够不断寻找规律，不断建立方法论，不断引领团队提高效率，能够看清业务本质的人。成为这样的人，是需要时间的积累的。一个高校毕业的天才少年，或者是工作了三五年特别聪明的人，学习能力强，可以很快掌握新业务进行测试；但是不太可能马上了解这个业务背后的架构和本质，还是需要继续打磨几年。

不断学习，挖掘本质。并且多做复盘，不是测完一个东西就扔到一边。如果别人面试你的时候，你可以分分钟拿出一个不断改进的方案，那这个面试官就不会放弃你；但如果你过去的十年是把一个工作重复了十次，那面试官当然不想要你了。所以如果大家保持一种不断积累和进步的修炼态度，到了三十五岁以后也不用担心被淘汰。

所以三十五岁以后是可以继续走技术路线的。前提是你能够不断寻找方法论，不断改进每个阶段的学习方法和成效。有些人是所谓的 “躺平 “，接到任务后测完就收工，也不总结也不思考，这种人确实容易被淘汰。如果技术提炼能力和自我改进能力比较弱，那就尽早地向新知识迁移。看一下新入行的同学们擅长什么样的编程语言和技术方向，如果是自己不会的，就多上上课，多学一下补上自己的短板。然后包装一下自己的简历，做一两个相关的项目，也一样能找到心仪的工作。

再者说，管理路线也是一种选择。管理是没有边界的，它本身既是科学，又是艺术。是需要花时间学习和修炼的。很少有刚毕业三四年的人，就可以成为一个好的管理者。管理的艺术需要在大量的项目和跟人的交流当中去碰撞灵感，不是在学校里学习能搞定的。

综合以上几个方面，我觉得不用担心年龄 35+ 之后的职业发展道路。

换一个思路，不从个人角度来看这个问题，而是从社会发展的角度来看。当互联网处于快速发展的阶段时，不断有新的东西涌现，所以导致这个行业会出现所谓 “三十五岁定理 “。但是当行业的发展已经处于稳定状态，更需要什么样的人呢？就是能够慢工出细活的人。在产品的用户量较为固化时，如何深挖产品价值，经验就比年轻肯加班更重要。

还有一个明显的倾向，为什么现在的互联网公司估值下降以后，它的很多业务要掐掉？因为之前是各种试错，巨头之间互相 pk，所有的新业务都试一轮。让 35+ 的同学们感觉好像跟不上快速变化的互联网世界。但这种情况在未来其实不会延续，因为经济没有那么好了，公司不再会无限制地尝试。以前是大家拼命地学新业务，所以招了一些新人，包括很多新业务是面向零零后的，所以需要很多年轻人。但是未来，公司首先是求稳，把该赚的钱赚到。你手上这些已经做了好多年的业务既然还能够生存，就说明这个业务是稳的，所以你要抓牢手上的业务，被新人淘汰的概率就低很多。但是你也不要只守着老本，碌碌无为。

从目前各公司的政策来说，你会发现各个公司在福利建设和增加员工幸福感上面，逐步投入了更多资源。也而且国家也在对年龄上的歧视，或者是消极的用工理念，进行限制。我看到过的一些新业务，负责这些新业务的同学很优秀但是不够善良：他们是以 KPI 为导向做产品设计，并不是考虑用户体验。一方面在未来的时代，国家的管控会更加严格；另一方面，如果你伤害了用户体验，那么产品的生命力就会大打折扣。什么样的人更懂用户体验呢？我觉得是那些有多年用户体验一手经验和相关思考的同学，而不是那些掌握了最新工具能够加班熬夜的人。

像硅谷和海外的那些公司，他们的工程师的年龄跨度都很长。我们互联网行业之前的发展模式肯定是要调整的，国家也已经开始在调整，未来我们迟早也会像现在海外的互联网公司一样。并且我们的互联网产业经过短期高速的发展，基础设施都 OK 了，下一步就是如何把现在能赚钱的业务继续打磨，提供更好的服务：这些都是经验活。

所以综合考虑多方面的因素，在未来，资深的码农，资深的技术人员，有觉悟的体验设计师和团队管理者，一定有更大的发展空间。

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

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

如何体现功劳和价值呢？

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

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

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

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

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

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

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

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

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

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

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

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

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