聊聊leader的向上管理和向下管理

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

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

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

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

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

这里可收听完整音频节目：跟鼎叔聊聊测试团队管理（第一话)_测试圈大咖说_免费在线阅读收听下载 - 喜马拉雅手机版

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的专家所带的团队），我们会期望这种团队能够找到突破行业普遍困难的抓手和技巧，能够有一套让优秀团队再向前进步的方案。并且这些方案是通用的，可以在不同部门甚至整个行业都可以复用和受益。

来源 / canva

06

如何有效地激励团队成员？

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

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

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

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

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

07

团队中的孙悟空、老油条、老黄牛和初生牛犊

先说一个我在很多年前“情境领导”的课程中学到的基本概念：很多传统的管理学理论，会把我们的员工按照潜力的高低和个人意愿的高低，组合分为四个象限。有高潜高意愿、高潜低意愿、低潜高意愿和低潜低意愿。对于不同象限中的员工，有不同的管理方式。

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

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

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

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

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

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

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

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

08

关于团队的创新，如何在团队中引入变革

测试团队如何体系化地进行创新？

这个我在公众号有一篇文章 聊聊如何建设团队的创新氛围，大家可以具体看一下。

首先，一个测试团队做出创新，要从概念上面要打破自己固有的认知。很多人认为，测试同学做一做测试就好了嘛，把你的软件反复测就可以了，最多搞搞自动化。这样会有一个很大的误区，到底测试团队能不能创新，应不应该创新？

很多人非常保守，我甚至见过这样的leader，说：“测试团队把精力都花在创新上面，那找bug，这个那个功能测试，黑盒测试啊就没人管了。” 他认为创新反而是一个负面的情况。

如果要是以这种心态来带测试团队的话，那我可以肯定带出来的这个团队不可能优秀，最多就是敬业。

如果从优秀到卓越，他一定是创新驱动的。当然这个创新从系统上的打法而言，有几点：

第一，不是盲目的创新，也不只是idea。idea这事根本就不值一提。我每天早上起来可能有五个idea，那我是不是就成为一个牛逼的创业者么？当然不是。因为我的idea从想到到后面真正付出行动的，可能只有十分之一。然后从行动到成功的可能又只有十分之一。所以首先要保证idea最终能够正儿八经地变成一个方案，可落地的，这才是创新的根基。

第二，就是管理者一定要在这个团队当中形成一个创新氛围，这是什么样的一个氛围呢？那就是鼓励大家去大胆提出自己的设想，你可以提意见，但不能因为有人提了一些创新想法而对他有什么负面看法。另外一点，创新就一定有人主动牺牲当前的一个舒适程度去争取的。不能因为今天说了一句话，明天说这个创新的功劳是我的这个，这是完全没有因果关系的。

我认为创新的本质是你除了有想法，还一定有一个系统化行动，而且一定要付出别人没有付出的代价。不可能真的添上掉馅饼，出来一个创新成果。我看到所有大公司优秀创新例子，背后都是一个百折不挠的行动，比如我可能有五种方法去实现，结果每一种都失败了。最后在绝望当中突然受什么启发，又找到了一个新的方法，最后效果还不错。这些都是创新的一个成功的基础。

第三，你的创新是否有一个里程碑，是否有足够多的数据来支撑。很多时候把创新对外宣导，说难听一点是邀功。实际上大家觉得会质疑，你这个创新到底靠不靠谱？你就需要拿出足够多数据对比，有这个东西跟没有这个东西的差别是什么。

第四，你要用故事来说服人。即，我这个创新落地的过程，到底经历过哪些困难，我怎么搞定的，大家就容易跟你产生一个共鸣。大家就会觉得创新有意思，我要向你学习。

第五，最后成果出来以后，你要学会如何普及到更多的团队，而不是创新完了就完了。大家在互相实践中，能够迸发出更高一级创新的成果。

那怎么把这个创新的这个成果固化下来？

比如，是否申请专利？我之前的团队申请过上百项测试的专利，一点都不比开发团队申请的少。另外还有各种成果如课程、流程、文档分享，这些都是可以积累的打法。

可以参考我的公众号文章，好好去思考和实践。聊聊组织中如何成功导入变革（上）

聊聊组织中如何成功导入变革（下）