聊聊“PPT文化”违反敏捷么

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

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

鼎叔返场再次参与小道消息播客，和主持人老徐和兔子继续畅谈。

本文是返场直播的后半部分，重点分享如何看待PPT文化，以及技术分享如何把握度，标准化流程的利弊，应届毕业生如何走出迷茫等听众关心的问题。

返场前半部分内容请看这里 聊聊项目测试时间不足怎么办

本文是根据直播分享，精简和提炼出的文字版本。点击文末阅读原文，收听完整音频分享。

01

如何看待PPT文化？

PPT作为一个让人提炼核心观点并清晰生动地呈现给听众的载体，它的存在是有它的价值，PPT本身是没错的。我个人鼓励大家在该分享的时候就好好复盘自己的观点。

但是，如果我们为了给老板呈现自己的苦劳，大量地画PPT，花了大把时间调整让PPT上的数据显得好看，却完全没有起到帮助老板做决策的作用——这就让有价值的事情走向了反面。

围绕PPT文化如何进行改进呢？

第一点：准备PPT时，从是给员工“汇报”的角度来做。如果从这个角度准备PPT、报告或文档，既让下属容易理解，也让老板更清楚你想表达什么。比单纯为了给老板看，刻意做一些数据更有价值。

第二点：不要为了汇报本身准备新的PPT或者其它文档。如果给老板汇报，个人觉得更重要的是demo，给老板看一个可以实际跑通的东西。或者把你工作中产出的产品给老板看，但不要为了给老板看专门画一个产品。

我们也要注意，不要从一个极端跑到另外一个极端：不能因为有PPT文化的存在就完全抵制做文档输出。如果我们的PPT里记录了我们的思考和知识沉淀，有可以帮助老板做决定的有用信息，这样的PPT就是有价值、应该被提倡的。

02

”全员“技术分享，做还是不做？

凡事如果做到极端让大家反感的程度肯定是不好的，就我自己的经验，大多数部门和公司在技术分享上不是做的过分而是做的不够。技术分享能带来哪些收益，又有哪些类型呢？下面是个人的一些看法。

技术分享不只承载了交流技术知识的作用，也有助于团队氛围建设，具有团建的属性。举个例子：咱们团队中的人可能来自于多个不同的公司，有过不同的业务经验。如果团队成员能在团队中分享自己做过的典型项目经验，既能让大家更了解ta的背景和资历，增进彼此好感，也能学习ta解决问题的思路，还能获得相关项目的经验。

另一方面，技术分享不一定是分享跟工作相关的内容。也可以是某个专著的读书会，分享如何提高抗压能力，如何提高综合素质等。我们觉得有趣的东西都可以拿出来分享，营造更加活跃的团队氛围。

关于分享的时间和频次，个人建议不要太频繁。比如1~2周一次，形成规律。如果是工作相关的分享，比如新人入职的流程、工作须知、工具普及等必须参加的分享，可以放在工作时间进行。倘若是提升型个性化的分享，可以放在正常工作时间以外，并且不强制参加。不做强制，可以让分享的人知道哪些人真的对自己的话题感兴趣，让大家自己探寻“热门”话题，也避免和日常工作时间冲突。

分享的成效也跟组织者或者团队leader有很大关系。比如做一个系列分享，如果每个分享间隔太长，或者分享的人抱着随便做做的态度，能够积累的知识资产就很单薄，分享的效果也会大打折扣。组织者如果把握好系列分享的频次、范围和质量，就可以形成体系化的知识库；这些分享都进行录屏保存为视频，大家可以反复学习，有新人加入可以直接看视频——是一件低投入高回报的事情。

大家为何会对技术分享望而却步？

我待过的大型的公司都会有这样一个要求：高级别的员工晋升要有自己的举证，其中一个重要组成就是有自己的课程，能够把自己的经验传播给更大的团队，不能只是写个总结就来做晋升。反过来说，级别低一些的同学，想将来晋升高级别的话，是不是现在就开始做一些积累？所以讲课和分享虽然不能作为绩效的扣分项，但至少可以成为加分项，来营造鼓励员工讲课的文化。

另一方面来说，作为高级别的员工，你如果不讲课不分享，怎么体现你的技术方案强？如何让其他人理解你的思想，并且帮助其他人成长呢？不能的话，专家的价值在哪？所以，我个人认为要求高级别的晋升要做课程分享是很合理的，具体分享的范围可以商榷。

如果说一个部门里缺少分享的文化，大家讨厌分享，最有可能是什么原因？

第一个就是，大家对被分享的内容不感兴趣；

第二个是没有对应的激励，没有营造好的氛围；

第三个是，分享的内容质量很低，或者是没有抓住大家的痛点。

如果不存在以上任何情况，相信大家会有兴趣参与分享。

听友连麦提问一

团队成员分布在三个不同城市，如果做好“异地”团队成员的管理和文化建设，保持整个大团队的凝聚力？

答案藏在在完整音频中的00:24:50~00:28:00

03

推行标准化流程的注意事项和利弊

做标准化的核心在于想清楚做这件事的根本出发点，确定要做的话，标准要越简单越好。

把标准想得很细、很复杂，大家执行的时候会很痛苦。因为我们在设定标准的时候，也在束缚别人的创造力。标准的存在要有充分的缘由，一定不能因为某个专家的建议、某个领导的个人意志，就把某些事情标准化。

反向来看，标准化的每一个准则是否一定需要。如果不是，就不能把它当作标准，最多作为一个样例。标准化应该明确：哪些事项是必须禁止的，哪些事情是要按照特定要求做的，哪些是仅供大家参考的模板和推荐做法。

做标准化之前要多听主要用户的意见，不能只顾着跟老板汇报。如果主要用户不支持，制定的标准不是用户想要的，肯定还是会以失败告终，跟老板汇报也没有用。当然，老板也是意见方之一，要尽早跟老板聊，了解老板为什么要做标准化这件事。比如说，老板是觉得需求进展太慢了，那标准化就围绕需求慢来制定；或者老板觉得开发周期太长，我们就围绕缩短开发周期定标准；或者老板关心的是漏测，是觉得线上事故太多，那我们就围绕降低线上事故改进标准。总之一定是围绕目的制定标准。

标准也要“因地制宜”。最怕的一种情况就是，制定标准的人不是研发团队的一员。空降了一个团队一个专家，根本没有参加过咱们公司产品研发和测试的流程，定了一堆看起来好像很有道理、很有水平的标准。但问题是大家的水平达不到，大家根本不理解为什么要这么做却被迫去执行。所以，我们制定的标准一定是源自团队的实践，团队成员能够理解、认可和采纳。

04

初入测试行业的校招毕业生的迷茫

正常而言，一个毕业生入职以后一定会有自己的导师，或者是小leader，或者是师兄带他们。会被告知技术提升和转正要求，以及完备的工作流程。

做为校招新人，如果不是处于这样一个环境，以下是根据我的个人经验给出的通用性建议。

首先要弄清楚转正要求，保证自己能在职场上顺利地生存下去。如果没有人直接告诉你，就要自己去问，可以找自己的导师或者leader，或者hr。

第二要弄清楚工作流。不同的公司，工作流有复杂也有简单的，一定至少有一套基本的工作流。弄清工作流有助于确保自己顺利上手工作。

第三要了解在工作中需要掌握的工具，比如研发管理工具，测试工具，需不需要掌握一些脚本的编写。

在了解以上三点后，就是围绕目标进行实践和输出成果。比如，假设我的目标是在三个月或者六个月后，成为一个能够独立干活的工程师，那为了达到这个目标我应该做什么项目？在这个项目里面我要承担的角色是什么？然后要输出怎样的成果，证明自己可以独当一面。在这个过程当中，如果遇到问题，自己查资料也没有找到答案，可以跟身边senior的同学求助，或者是问一下同行或者导师，尽快地去解决困难。

在完成这一点的基础上，可以再进一步得思考如何成为更加成熟的工程师，要多学哪些知识和课程，在什么工具上面投入更多的精力。

End

修炼管理能力是一个很长期的过程，在这个过程中，做事情不要局限于眼前的价值，而要把眼光放长远。比如之前说到的技术分享，要从长远来看这件事情做好以后对于团队效率的提升。

任何事情都有两面性，出现不好的情况往往是因为某一个因素失控了，但是其它因素都是正向的，都是值得我们提炼的。所以凡事要多从两面做思考，然后把好的一面做大做强；不好的那一面可以用吐槽的方式去提醒大家，不要踩坑。

点击这里鼎叔返场，深入聊聊测试团队管理（下篇）_测试圈大咖说_免费在线阅读收听下载 - 喜马拉雅  收听完整音频节目