敏捷测试转型 聊聊 leader 的向上管理和向下管理

鼎叔 · 2022年04月25日 · 最后由 t-bug 回复于 2022年04月27日 · 9298 次阅读

这是鼎叔的第十六篇原创文章。

行业大牛和刚毕业的小白,都可以进来聊聊。

欢迎关注本人专栏和微信公众号《敏捷测试转型》,大量原创思考文章陆续推出。

上周日(4 月 3 号)晚上,鼎叔作为嘉宾参与小道消息播客的直播分享节目,和主持人老徐和兔子聊了近两个小时,回答很多团队管理者关心的问题, 完整内容会分为两期和大家分享。

第一部分的话题聚焦在 leader 的向上管理和向下管理。

这里可收听完整音频节目:跟鼎叔聊聊测试团队管理(第一话) https://m.ximalaya.com/sound/520074513

01
如何进入了测试行业?
——推开一扇窗,打开广阔新世界

自己的计算机根基主要来自中学时期,大学里主修数学专业,也做过一些计算机的课题,但是整体上自己的编程能力偏竞赛方向。

大学毕业时,依靠编程竞赛的成绩进入一家外企做开发工程师(也叫做 Designer)。做了一年后发现,自己对通信行业核心网方面的编程,实在没有太大兴趣,自己的进步也比同期加入公司的同学们要慢一些。后来我被调派到测试部,因为对业务逻辑和测试范围这些都非常感兴趣,在测试部做的非常不错。我就萌生了在测试这个方向继续发展的想法,然后逐步从测试工程师,做到高级测试工程师,再到更高级的管理者。

鼎叔给测试同学的小忠告
做为招聘方,我也参加过不少校园招聘,就发现包括毕业生在内的很多同学:对测试行业并不了解,是糊里糊涂的就进入测试这个行当;还有一些同学是觉得自己的开发能力和经验不够强,所以软件测试这个行业可能更适合自己。严格来说,这个想法也没有错;只要是对业务和软件逻辑感兴趣的同学,都欢迎加入到测试这个行业。

但是我们也希望大家不要忘记:软件测试还是一个强技术的岗位。如果我们之前的代码编程技术不太扎实,那么入行以后千万不要松懈。否则的话,就会在测试这条职业道路上越走越窄。

02
如何向上体现测试团队的价值?
从业这么多年,我自己也接触过各种不同的上级:跟有的上级在管理理念上非常合拍,做事就很顺;也遇到过不太理解测试,或者是跟自己的测试管理方向不一致的上级,在这样的上级手下带团队就会做的很痛苦。

总结我个人的经验教训,我认为跟上级沟通最重点的事情就是:我们首先在概念里要有这样一个自我认知,就是测试团队在公司里是一个成本中心。什么叫做成本中心?就是一般从上级的角度,或者从公司高管的角度来看,测试团队里的人越少越好。明确了这一点,我们就容易理解:做为测试团队的管理者,如果找老板要尽可能多的资源,是很容易引起上级的负面看法的。因为从经营者的角度,是希望控制测试团队的成本。

但是另外一方面,我们怎样给测试团队争取到更多的利益或者更好的发展前景呢?那就需要我们对老板的认知进行一些拓展:让老板从把测试团队当做一个必须付出的成本,变为认可测试团队也可以带来更多的价值。

具体应该怎么做呢?我们后面会聊到一系列的相关技巧,在这里先列出几点。

除了找 bug,测试团队是不是能给公司的业务带来更多贡献?比如帮助整个团队的品质得到进一步的提升:“品质 “要比” 缺陷 “的范围大很多。比如帮助提升用户满意度:与一般的客服人员相比,测试团队在这方面是不是可以带来更多的价值。如果我们从这些角度去跟老板交流,并给出我们测试团队的打法和策略,我觉得老板是会愿意在这一块付出更多投资的。

总结一下就是,我们可以从给公司带来更大回报的角度,去提供更多的可能性和更多的方案。

还有一方面是我比较喜欢的,就是测试是否一定要等到最后才去做一些必要的检查呢?如果我们只做必要的检查,那么老板愿意在测试方面付出的钱是非常少的。但是如果我们告诉老板说:我们可以把测试往左移、往前推,我们可以帮助产品经理提高所输出需求的质量;让项目中用更少的产品经理,给出更高质量的需求,让用户更加满意——那么这个价值就会大很多。

另一方面是,作为测试如何帮助开发提高所提交的代码质量。一般而言,开发是公司中最大的一个主体。如果我们能在开发方面做出更大的贡献,让我们的 CTO 了解到测试团队能给公司业绩和工程效能输出较大的推动力,就会让老板对测试团队有一个更好的印象,ta 也会愿意给测试团队更多的支持。

03
如何向上维护关系?
作为一个测试 leader,首先我们不能默认只要好好工作就可以,平时不需要跟上级有太多沟通。不能等到出了故障,或者是出现了一些负面舆情的时候才出面,才跟老板汇报。

第二点是,我们要面对的老板可能是测试方面的高管,可能是技术的高管,也可能是综合性的高管。来自不同背景的人,对于测试的理解差异也非常大。哪怕是测试方面的高管,也可能不是测试出身。做为测试团队管理者,要主动了解上级对测试团队的需求。

我的习惯是,每次绩效考核周期的早期,比如说每半年、或者是三个月的时候,我都会主动跟自己的上级管理者聊一聊,聊什么呢?比如工作的规划,以及过去几个月核心的成果进展。在聊天的过程中,我会刻意搜集 ta 对测试团队的诉求。对于上级管理者来说,我们主动发问,了解 ta 对测试团队有什么抱怨,有什么期望,对 ta 来说就是一个很好的反馈。ta 会认为测试团队正在关注自己的痛点,我们跟上级管理者之间的距离就可以被拉近。

另外,我会趁这个时候跟 ta 汇报一下自己是如何开展工作的。比如说我的重点工作是怎么提效,那提效的具体打法策略是什么,效果怎么样。我会尽量的找一些恰当的时机给上级管理者做 demo,比如在月度会议的时候。如果没有刚刚好的机会,那就单独约 ta 的时间,跟 ta 说测试部有一个很重要的项目,希望 ta 给一些评价。在 Demo 时,可以把自己团队中做得最好的一个测试案例,当做 showcase 展示给上级管理者,然后搜集 ta 的反馈。

简而言之,我们做为测试团队管理者,首先要了解上级管理者对测试的痛点,再把痛点传递给一线测试骨干,让测试骨干把它作为个人的 OKR 或者个人要公关的一个堡垒。另外一方面要定期跟你的管理者有一个规划上的同步,及时展示测试团队近期的里程碑,给管理者一个直接的、面对面的,或者是一个可视化的成果展现。做到这几点,我觉得管理者对我们的信任度和满意度,都会在一定程度上得到提升。

还有一个提醒:我们不能忽略了产品(部门)。有的团队中,测试可能跟技术走得比较近,但是跟产品走得比较远。产品中相关的平行高管或者平行管理者,也是我们作为测试团队管理者需要打通的一个重要资源。我在工作中可能跟产品的打通会少一点,但我也会让产品经理搜集他们对于质量的一些痛点要求。同时我也会试探,看测试能给产品经理的需求带来哪些帮助。

那么还有一个角色跟测试的关系也比较重要的,那就是 PMO——项目总监。测试团队和 PMO 如果是一个正向的合作关系,那就双赢。项目经理最怕的就是项目延期;遇到项目延期的情况,很多时候上线的负担就会压到测试头上。如果项目总监跟测试团队管理者是站在一个战壕里的队友,那么测试会尽快把风险暴露给项目经理,然后借助项目经理去把这个风险往前拉。如果反过来,测试总是被项目经理摧着问 “你有没有人,或者你有没有风险”,那么测试一方面很被动,另外一方面,项目经理会把这种负面信息传递给高层,那对测试的发展就不利。

综上所述,测试团队管理者一方面要定期跟上级沟通,进行比较好的工作成果的里程碑汇报;另一方面跟相关角色的拉通也非常重要,包括开发 leader、PMO 以及产品 leader。

04
向上沟通的正确姿势:该强势还是含蓄?
首先,测试的 leader 做为管理者,沟通是非常重要的基础技能。如果一位测试同学,他的技术非常强但是沟通比较弱势,那么他其实更适合走技术专家的路线,不一定适合做管理。但沟通是可以修炼的,并不是说现在沟通水平一般以后就都不行。我也带过很多 leader,刚开始他们在沟通上比较内向比较保守,但是经过长时间的修炼,也是能够胜任沟通的角色。

那么再回到这个问题本身,我们在沟通 PK 的时候一定会遇到一些非常强势的核心角色。比如说,我就遇到过一些产品总监,会觉得漏测就是测试的锅,为什么你不多投人——是一种非常简单粗暴的逻辑。我觉得这种情况下,不要陷入鸡同鸭讲的无谓的争吵。

面对比较大的冲突(或者预想到可能有冲突),我倾向于提前将我的分析写下来,把我的逻辑放到群里面——可以事前也可以事后放,目的是让群里相关的人看到我的分析逻辑。我会一步步的说明,为什么这次出了问题并不是我们要加人的锅,更多是因为我们没有排好优先级;或者是因为我们的一些信息没有做评审,如果做了评审,我们根本就不需要加用例,就能够拦截这个问题。

在看了这个清晰的逻辑后,相关人员在跟我沟通的时候,就不会争吵。尽量避免陷入在现场靠声音的大小去 PK 胜负的困境。

总而言之,在跟那些强势的人沟通之前,我们要做好充分的准备。这种准备最好是可视化的,不要陷入完全靠情绪去争吵的情境。但如果真的陷入了这种争吵,那我们首先要及时刹车,晚一点再进行沟通会议,或者会后再单独聊。把刚才提到的所要准备的数据和逻辑列清楚后再聊。

作为相对而言 “羞涩” 一点的 leader,就尽量利用我们的逻辑做武器,还有数据分析作为沟通交流的道具。在聊的时候,如果是有第三方在场,我们也可以把一些内容投屏出来。当然,我们也要储备一些必要的小证据,把得到共识的证据抛出来,尽量减少无谓的争吵。这些证据可以是公司里一些高管的要求,或者高管的一些认可,包括历史上出现过的典型的问题等。

最后一点是关于管理者的性格,如果本身性格比较 “羞涩” 一些,那我建议你先在团队内创造一些交流 PK 的氛围。比如在自己团队中,针对一些可能的问题,在每次的周会或者月会中多找一些话题进行演练讨论。然后在团队之外讲遇到的问题,就不会那么被动,在谈问题时更容易把控自己的情绪。

我个人有一个习惯,就是每隔一个周期(比如月会时)都会跟团队成员聊一下现在遇到了哪些困难,我们的对策是什么,我们怎样去说服别人;或者是我们遇到了哪些事故,背后的真正原因是什么。在团队内已经做过事故原因的同步和研讨之后,再跟其他团队 leader 甚至上级沟通时就不会那么怯弱。

05
优秀测试团队的标准?
首先我们要承认一个现实,虽然都是测试,但是因为各种各样的原因,测试团队间的差距是很明显的。这中间的差距,就是需要我们不断自我突破、自我积累的一个过程。团队也有不同的发展周期,下面是我个人总结的一个测试团队从普通到卓越的演化过程。

1)最初级的测试团队,或者说 “原始社会” 时期的测试团队更多就是接活。比如老板给你三个人力的活,你把活接下来并好好完成,必要时候加加班。

2)升级一小步:慢慢的我们就会有一些基本的自动化建设,有一些基本的自动化工具,形成基本的测试和分析流程。做到这些,就成长为自组织的初级熟练型的团队。

3)再往上,就是逐步成为一个优秀高效的团队。优秀的测试团队是什么样子的呢?首先要求团队中的个人要优秀:团队里不应该有混日子,或者是对于测试没有什么兴趣的人。团队成员首先关心问题背后的根因是什么,对业务逻辑非常精通,其次对所使用的测试工具能够不断精益求精,愿意开阔眼界,从外部找一些更合适我们业务现状的测试工具。

4)后面的修炼会越来越困难,个人认为要从 “优秀 “变到更高一级的” 卓越 “的专家型团队,在有些方面需要至少数年的积累。
第一个就是我们的现在的技术方案,是否具备方法论的潜质?所谓的方法论就是我们能否把自己团队做过的一些事情变成一个,大家都能够快速掌握,快速复制的体系化打法。
另外一点,一个卓越的专家型团队,是能够找到现在的创新点,能够用比较少的精力突破低效的现状,拉高大家的效率上限。
最后一点要求,算是针对持续改进型的变革型的团队(比如阿里的 P9、腾讯 senior 的专家所带的团队),我们会期望这种团队能够找到突破行业普遍困难的抓手和技巧,能够有一套让优秀团队再向前进步的方案。并且这些方案是通用的,可以在不同部门甚至整个行业都可以复用和受益。

06
如何有效地激励团队成员?
无论对于优秀的测试管理者,还是任何技术团队的管理者,这都是一个非常好的问题。解决这个问题所涉及的理论,或者是行业中的打法各种各样,我在此分享一下自己个人喜欢使用的激励方式。

首先,作为一个普通的 leader,你一般没有太多给下属加薪升职或者发奖金的权利。哪怕有,也是有限的机会,不可能给到很多人。另一方面,就算你有加薪升职的权利,建议也不能乱用,千万不能把它变成每个人都觉得理所当然的 “激励 “,那就不再是激励。一旦某个同学觉得自己做得不错,没有升职,反而心里有负面情绪。

所以激励一定要精准,能够撬动团队成员改进积极性的才是好的激励。我的个人见解:最终极的激励一定是从个人的本质内心来激发。如果你能够给团队成员机会做自己感兴趣的事情,同时给与支持;并在这个基础上,给他一个名副其实的物质激励:这就是一个非常高级的激励。

具体来说,除了加薪升职,观察和了解团队成员的其他需求。比如,如果有人想成为效能专家,那么作为团队管理者,可以给出相关学习课程和书籍的建议,或者刚好有提效的专项项目让 ta 去做。还有的测试同学想开发某个测试工具,在更详细地了解他的想法后,可以减少 ta 一部分现有测试工作,让 ta 有机会去实践测试工具的开发。

但是也要有自己的原则,做为团队管理者我们要给到能力范围内的支持和资源,也要求看到成果和团队成员实实在在的付出。不接受团队成员只会一味要人要资源,完全不能独立自主解决问题。

07
团队中的孙悟空、老油条、老黄牛和初生牛犊
先说一个我在很多年前 “情境领导” 的课程中学到的基本概念:很多传统的管理学理论,会把我们的员工按照潜力的高低和个人意愿的高低,组合分为四个象限。有高潜高意愿、高潜低意愿、低潜高意愿和低潜低意愿。对于不同象限中的员工,有不同的管理方式。

在这里就不展开说这个通用的管理理论,大家有兴趣可以自己学习。回到测试团队管理,我们测试团队中的角色可能来自不同的年龄段,有不同的背景。作为团队的 leader,首先要画出团队工作的价值观:让大家知道在团队中工作,什么是底线,什么是红线。要用具体的案例,给大家明确一些不厚道不职业的情况绝对不能出现在自己的团队中。

其次是要明确激励的导向。让无论团队中哪种角色的成员,都了解团队中激励的导向,知道团队所讨厌的行为是什么,形成明确的共识。

如果明确了团队价值观,形成了自己团队的管理文化,那些不适合我们团队的同学就自动离开,甚至不需要团队管理者去做额外的一些动作。

再具体说一下几种个性化的团队成员。

初生牛犊(新人):团队有义务为新人提供完备的学习指导,比如要为新人指定师兄,设定新人必修的课程。但同时我们也要求新人一定要能够自主学习,因为企业不是学校。我们可以给新人一个观察期,但如果你自己对学习没有兴趣,就想躺平,在企业里是不能接受的。所以给新人传输的理念就是:我们会有足够多的资源帮助你成长,但是你要自主学习。同时可以对新人的学习成果进行考核,不是说离开了学校就不能考试。

孙悟空:我们鼓励团队中出现正儿八经的孙悟空,但前提是你要能够一个人,或者能带头把事情搞定。而不是说我空有一个很牛逼的想法,或者是三分钟热度后面就把当初想做的事情搁置了。那说明你并不是真正的孙悟空,更多是徒有其表。

老黄牛:首先,我觉得测试团队要有一个必要的价值观,就是我们不鼓励低效的加班或者说低效的敬业。我经历过的一些传统公司,老板一说质量要提高,测试就把用例增加一倍,或者是把覆盖的机型增加一倍。那增加这些对于我们测试团队有什么作用呢?答案是没有,甚至会让别人觉得测试团队就是个人力密集型的岗位,对我们的口碑有负面影响。更好的方式是,梳理出来我们要在哪些场景做适配测试,背后的根本逻辑是什么,然后针对这些逻辑去找用例。如果你这个老黄牛就是每天反复执行被分配到的测试用例,没有总结和梳理;那我觉得这种工作给到外包团队,用更低的成本来完成反而更好,没有必要留这样一个老黄牛在自己的团队中。

总结来说,对强者给与一定的挑战、设立一定的目标,同时检验他们是否真的是强者。对于技术和业务能力一般的人,提供非常严格丰富且完善的培训内容,但不是手把手地教。对一直没有什么进步的同学,要适当地施加压力。未来要淘汰的话,首先是踩红线和价值观不符合的同学;如果时局比较紧的话,那些一直没有进步的同学也可能会被淘汰掉或者外包化。

08
关于团队的创新,如何在团队中引入变革
测试团队如何体系化地进行创新?
这个我在公众号有一篇文章 聊聊如何建设团队的创新氛围,大家可以具体看一下。
首先,一个测试团队做出创新,要从概念上面要打破自己固有的认知。很多人认为,测试同学做一做测试就好了嘛,把你的软件反复测就可以了,最多搞搞自动化。这样会有一个很大的误区,到底测试团队能不能创新,应不应该创新?
很多人非常保守,我甚至见过这样的 leader,说:“测试团队把精力都花在创新上面,那找 bug,这个那个功能测试,黑盒测试啊就没人管了。” 他认为创新反而是一个负面的情况。
如果要是以这种心态来带测试团队的话,那我可以肯定带出来的这个团队不可能优秀,最多就是敬业。
如果从优秀到卓越,他一定是创新驱动的。当然这个创新从系统上的打法而言,有几点:
第一,不是盲目的创新,也不只是 idea。idea 这事根本就不值一提。我每天早上起来可能有五个 idea,那我是不是就成为一个牛逼的创业者么?当然不是。因为我的 idea 从想到到后面真正付出行动的,可能只有十分之一。然后从行动到成功的可能又只有十分之一。所以首先要保证 idea 最终能够正儿八经地变成一个方案,可落地的,这才是创新的根基。
第二,就是管理者一定要在这个团队当中形成一个创新氛围,这是什么样的一个氛围呢?那就是鼓励大家去大胆提出自己的设想,你可以提意见,但不能因为有人提了一些创新想法而对他有什么负面看法。另外一点,创新就一定有人主动牺牲当前的一个舒适程度去争取的。不能因为今天说了一句话,明天说这个创新的功劳是我的这个,这是完全没有因果关系的。
我认为创新的本质是你除了有想法,还一定有一个系统化行动,而且一定要付出别人没有付出的代价。不可能真的添上掉馅饼,出来一个创新成果。我看到所有大公司优秀创新例子,背后都是一个百折不挠的行动,比如我可能有五种方法去实现,结果每一种都失败了。最后在绝望当中突然受什么启发,又找到了一个新的方法,最后效果还不错。这些都是创新的一个成功的基础。
第三,你的创新是否有一个里程碑,是否有足够多的数据来支撑。很多时候把创新对外宣导,说难听一点是邀功。实际上大家觉得会质疑,你这个创新到底靠不靠谱?你就需要拿出足够多数据对比,有这个东西跟没有这个东西的差别是什么。
第四,你要用故事来说服人。即,我这个创新落地的过程,到底经历过哪些困难,我怎么搞定的,大家就容易跟你产生一个共鸣。大家就会觉得创新有意思,我要向你学习。
第五,最后成果出来以后,你要学会如何普及到更多的团队,而不是创新完了就完了。大家在互相实践中,能够迸发出更高一级创新的成果。
那怎么把这个创新的这个成果固化下来?
比如,是否申请专利?我之前的团队申请过上百项测试的专利,一点都不比开发团队申请的少。另外还有各种成果如课程、流程、文档分享,这些都是可以积累的打法。
可以参考我的公众号文章,好好去思考和实践。聊聊组织中如何成功导入变革(上)https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483787&idx=1&sn=dd8a77a1574e6ffd253a256160f42f49&chksm=c24fb4e9f5383dffb488f33e8337e263093d91fa21d80373fabc3cc28cf2ea82497b019f69be&token=1565622091&lang=zh_CN#rd
聊聊组织中如何成功导入变革(下)https://mp.weixin.qq.com/s?__biz=MzkzMzI3NDYzNw==&mid=2247483790&idx=1&sn=abfc1f571a5556598dac699596928767&chksm=c24fb4ecf5383dfa5b8b70c28242235db99d94f3952b77b6a19864bfb77a766b369e9401176c&token=1565622091&lang=zh_CN#rd

共收到 4 条回复 时间 点赞

除了找 bug,测试团队是不是能给公司的业务带来更多贡献?比如帮助整个团队的品质得到进一步的提升:“品质 “要比” 缺陷 “的范围大很多。

这点很认可,要扩大上级对测试价值的认知,如果总是觉得测试只是手工活点点点,那后面会处处受限。

很深的领会,学习了。文中添上,楼主可能打字太快,没注意到。

不可能真的添上掉馅饼,出来一个创新成果。

好文!不过向上管理挺难的。特别是整个研发中心都是成本中心的情况下。

不知道你说的老徐是不是我关注的老徐?

Ouroboros 聊聊向上管理 中提及了此贴 05月26日 09:36
Ouroboros 聊聊向上管理 中提及了此贴 05月26日 09:36
需要 登录 后方可回复, 如果你还没有账号请点击这里 注册