本期嘉宾鼎叔 @dylan.zhang ：互联网/通讯行业大厂技术总监，高级架构师，测试专家，敏捷教练。公众号「敏捷测试转型」作者，在 TesterHome 论坛著有同名专栏《敏捷测试转型》。
01 测试团队不属于测试部门，怎么办，怎么管？
一个公司的组织架构，跟公司的发展阶段以及人才模型是强相关的。如果测试团队真有很牛的一把手，其实老板是更希望把测试团队挂在一起，成立单独的测试部门进行管理。很多时候为什么分散呢？说白了就是缺少一个很牛的人，把大家组织在一起。现在的 leader 可能还不具备管理大部门的能力，不得已才把测试团队拆分到其他部门中（比如开发、产品等）。在这种情况下，现有的测试小团队管理者不要想太多，先把分内之事做好，把要服务的对象服务好。当你的口碑足够好，证明了自己的实力，更高一级的管理者是会倾向于把分散的测试团队都归由你管理的。
或者说你是空降的管理者，但是有很深的资历，有成功的经验，能够拿出一个好的方案跟更高级的管理者聊：把测试团队组建在一起，成为一个更有强有力、更专业的团队，让大家互相之间能够共同学习修炼，打破部门墙提升专业效率。我相信高级管理者很有可能会同意，把零散团队整合成一个大部门。
再回到这个问题本身，如果测试团队被划归到比如开发部门下，具体又有哪几种情况？
一种情况是测试同学是双线汇报：既要向开发 leader 汇报，也要向测试 leader 汇报，测试 leader 仍有一定的考核权。这种情况我个人觉得也可以接受。因为我做为一个测试 leader，就算是单线向我汇报，我在做考评时还是会询问有工作交集的开发的意见，帮助我调整对测试同学口碑的认知。问题的关键在于，要跟开发 leader 对齐考核测试人员的维度和标准。
比如开发 leader 本身可能不太懂测试工具的价值，或者对测试工具的价值持怀疑态度，他们可能觉得测试把时间浪费在搞测试工具上却没有去发现更多 bug。从开发的角度来说，这种想法也没错。开发 leader 会关心什么？他们会关心真正的人效提升。如果我们更多的从能效的角度跟开发沟通，告诉他们某个测试工具，或者测试专项能帮助开发用更短的时间提测，用更短的时间找到更多的问题，就能更好地让开发 leader 肯定测试的价值。
个别情况向下，开发的质量观有问题，测试发现了问题，却不让上报。这种情况下，我觉得测试 leader 是可以为测试同学发声的。如果测试人员所坚持的原则也是公司层面认可的，可以在适当的场合向上反馈，把这个信息也传递给开发 leader，让 ta 调整对于测试的看法。
再一种情况是不是测试的锅，但是测试被迫要背。要应对这种情况，首先测试同学一定是发现了问题就先暴露出来，哪怕暴露的问题会导致发布延迟，也可以走一个让相关负责人都知晓的流程；如果业务方为了市场占有率，哪怕有风险也要发布，可以签字确认，大家共同承担风险。避免出了事故后，反过来责怪测试为什么当时没有发现问题。
还有一种情况是，测试 leader 完全没有考核权，只有开发 leader 或者项目 leader 有考核权。在这种情况下，测试 leader 也不必沮丧或者悲观。在高度敏捷的研发团队中，本身就存在一种可能性，就是只有 feature owner 拉着大家做考核。什么叫做 feature owner 呢？ta 是负责整个团队的一把手，这个团队里有开发，有测试，也有设计。大家都是为了某个 feature 服务，那最后考核也是 feature owner 带着大家一起来打考核。一个非常成熟的敏捷团队可能就是这种情况，这也是未来的一个发展方向。
在这种情况下，不必担心测试同学受到不公正的待遇。因为既然这个 feature team 需要测试，就意味着这测试是他们的一个关键角色。Feature owner 绝对不会因为你是测试而贬低你，为了团队的稳定性和 feature 的成功上线，feature owner 可能比测试 leader 还重视测试。
那么，测试 leader 自己有没有被架空的危险？自己的测试团队成员都被分到不同的 feature team，自己手上可能就没有为自己干活的兵。要稳住自己的位置，个人建议，测试 leader 可以尝试转型：从测试 leader 转型为一个测试架构师，横向拉通一个测试社团。虽然这个社团不是强考核的，但是你可以做为这个社团的专家带领大家进行自动化建设、测试培训等。横向的技术建设是 feature team 没法做的，如果你做成了一两个老板认可的横向建设，你的位置也会非常稳。
测试 leader 也可以转型教练，在不同的 feature team 培养测试工程师；或者帮助各个 feature team 的测试同学做晋升，做技术方案评审，以及帮 feature team 做考核参考。
所以，哪怕在高度敏捷的环境下，测试 leader 可以做的事情也是非常多的，只是测试 leader 要更多的跟更上层的，比如项目级 leader 或者技术高管打交道。
02 如何看待 PPT 文化？
PPT 做为一个让人提炼核心观点并清晰生动地呈现给听众的载体，它的存在是有它的价值，PPT 本身是没错的。而且我个人鼓励大家在该分享的时候就好好复盘自己的观点进行分享。
但是，如果我们为了给老板呈现自己的苦劳，大量地画 PPT，花了大把时间调整让 PPT 上的数据显得好看，却完全没有起到帮助老板做决策的作用——这就让有价值的事情走向了反面。
围绕 PPT 文化如何进行改进呢？
第一点：准备 PPT 时，从是给员工 “汇报” 的角度来做。
如果从这个角度准备 PPT、报告或文档，既让下属容易理解，也让老板更清楚你想表达什么。比单纯为了给老板看，刻意做一些数据更有价值。
第二点：不要为了汇报本身准备新的 PPT 或者其它文档。
如果给老板汇报，个人觉得更重要的是 demo，给老板看一个可以实际跑通的东西。或者把你工作中产出的产品给老板看，但不要为了给老板看专门画一个产品。
第三点：为了参加评审专门准备的 PPT，不如展示实际的工作成果更加真实。
我们也要注意，不要从一个极端跑到另外一个极端：不能因为有 PPT 文化的存在就完全抵制做文档输出。如果我们的 PPT 里记录了我们的思考和知识沉淀，有可以帮助老板做决定的有用信息，这样的 PPT 就是有价值、应该被提倡的。
03 ” 全员 “技术分享，做还是不做？
凡事如果做到极端让大家反感的程度肯定是不好的，但是就我自己的经验，大多数部门和公司在技术分享上不是做的过分而是做的不够。技术分享能带来哪些收益，又有哪些类型呢？下面是我个人的一些看法。
技术分享不只承载了交流技术知识的作用，也有助于团队氛围建设，具有团建的属性。举个例子：咱们团队中的人可能来自于多个不同的公司，有过不同的业务经验。如果团队成员能在团队中分享自己做过的典型项目经验，既能让大家更了解 ta 的背景和资历，也能学习 ta 解决问题的思路，还能获得相关项目的经验。
另一方面，技术分享不一定是分享跟工作相关的内容。也可以是某个专著的读书会，分享如何提高抗压能力，如何提高综合素质等。我们觉得有趣的东西都可以拿出来分享，营造更加活跃的团队氛围。
关于分享的时间和频次，个人建议不要太频繁。比如 1~2 周一次，形成规律。如果是工作相关的分享，比如新人入职的流程、工作须知、工具普及等必须参加的分享，可以放在工作时间进行。倘若是提升型个性化的分享，可以放在正常工作时间以外，并且不强制参加。不做强制，可以让分享的人知道哪些人真的对自己的话题感兴趣，让大家自己探寻 “热门” 话题。
分享的成效也跟组织者或者团队 leader 有很大关系。比如做一个系列分享，如果每个分享间隔太长，或者分享的人抱着随便做做的态度，能够积累的知识资产就很单薄，分享的效果也会大打折扣。组织者如果把握好系列分享的频次、范围和质量，就可以形成体系化的知识库；这些分享都进行录屏保存为视频，大家可以反复学习，有新人加入可以直接看视频——是一件低投入高回报的事情。
04 推行标准化流程的注意事项和利弊
做标准化的核心在于想清楚做这件事的根本出发点，确定要做的话，标准要越简单越好。
把标准想的很细、很复杂，大家执行的时候会很痛苦。因为我们在设定标准的时候，也在束缚别人的创造力。标准的存在要有充分的缘由，一定不能因为某个专家的建议、某个领导的个人意志，或者是大家的集思广益，就把某些事情标准化。
我们应该反向来看，标准化的每一个准则是否一定需要。如果不是，就不能把它当做标准，最多做为一个样例。标准化应该明确：哪些事项是必须禁止的，哪些事情是要按照特定要求做的，哪些是仅供大家参考的模板和推荐做法。
做标准化之前要多听主要用户的意见，不能只顾着跟老板汇报。如果主要用户不支持，制定的标准不是用户想要的，肯定还是会以失败告终，跟老板汇报也没有用。当然，老板也是意见方之一，要尽早跟老板聊，了解老板为什么要做标准化这件事。比如说，老板是觉得需求进展太慢了，那标准化就围绕需求慢来制定；或者老板觉得开发周期太长，我们就围绕缩短开发周期定标准；或者老板关心的是漏侧，是觉得线上事故太多，那我们就围绕降低线上事故改进标准。总之一定是围绕个目的制定标准。
标准也要 “因地制宜”。最怕的一种情况就是，制定标准的人不是研发团队的一员。空降了一个团队一个专家，根本没有参加过咱们公司产品研发和测试的流程，定了一堆看起来好像很有道理、很有水平的标准。但问题是大家的水平达不到，大家根本不理解为什么要这么做却被迫去执行。所以，我们制定的标准一定是源自团队的实践，团队成员能够理解、认可和采纳。
05 初入测试行业的校招毕业生的迷茫
正常而言，一个毕业生入职以后一定会有自己的导师，或者是小 leader，或者是师兄带他们。会被告知技术提升和转正要求，以及完备的工作流程。
做为校招新人，如果不是处于这样一个环境，以下是根据我的个人经验给出的通用性建议。
首先要弄清楚转正要求，保证自己能在职场上顺利的生存下去。如果没有人直接告诉你，就要自己去问，可以找自己的导师或者 leader，或者 hr。
第二要弄清楚工作流。不同的公司，工作流有复杂也有简单的，一定至少有一套基本的工作流。弄清工作流有助于确保自己顺利上手工作。
第三要了解在工作中需要掌握的工具，比如研发管理工具，测试工具，需不需要掌握一些脚本的编写。
在了解以上三点后，就是围绕目标进行实践和输出成果。比如，假设我的目标是在三个月或者六个月后，成为一个能够独立干活的工程师，那为了达到这个目标我应该做什么项目？在这个项目里面我要承担的角色是什么？然后要输出怎样的成果，证明自己可以独当一面。在这个过程当中，如果遇到问题，自己查资料也没有找到答案，可以跟身边 senior 的同学求助，或者是问一下同行或者导师，尽快的去解决困难。
在完成这一点的基础上，可以再进一步的思考如何成为更加成熟的工程师，要多学哪些知识和课程，在什么工具上面投入更多的精力。
The End
修炼管理能力是一个很长期的过程，在这个过程中，做事情不要局限于眼前的价值，而要把眼光放长远。比如之前说到的技术分享，要从长远来看这件事情做好以后对于团队效率的提升。
任何事情都有两面性，出现不好的情况往往是因为某一个因素失控了，但是其它因素都是正向的，都是值得我们提炼的。所以凡事要多从两面做思考，然后把好的一面做大做强；不好的那一面可以用吐槽的方式去提醒大家，不要踩坑。
测试管理系列文章
- 跟鼎叔聊聊测试团队管理（第一话）：https://testerhome.com/topics/32938
- 跟鼎叔聊聊测试团队管理（第二话）：https://testerhome.com/topics/33000
- 鼎叔返场 - 测试时间被迫压缩，怎么破：https://testerhome.com/topics/33213
- 鼎叔返场 - 测试团队管理者如何做好自我发展：https://testerhome.com/topics/33224
- 鼎叔返场：如何给出更让人信服的低绩效：https://testerhome.com/topics/33247
戳此链接可收听完整音频分享，我们下期再会 >>>