测试团队管理——如何判断一个差的管理者

最新推荐文章于 2023-05-19 13:24:46 发布

一颗正在价投韭菜

最新推荐文章于 2023-05-19 13:24:46 发布

阅读量532

点赞数

分类专栏：人生思考文章标签：低成本犯错

本文链接：https://blog.csdn.net/weixin_42721986/article/details/128492938

版权

人生思考专栏收录该内容

91 篇文章 1 订阅

订阅专栏

引言

谈论一个好的管理者或许指标不一，那不妨来逆向思考一下「如何判断一个差的管理者」。

当然了，讨论之前先做一些约定，方便更好讨论问题：

差的管理者，专从团队管理角度来讨论，只讨论管理现象，不代表团队本身能力差或好。
差的管理者，或许各有各的「差法」，这里举一些常见操作手法，仅供参考。或许由于团队、业务背景不同，「差」的感知程度也不同。

1、双标问题严重

可能由于「亲疏关系不同」，「连带对成员不信任」等等原因，同一件事情，却看人下菜碟。

例子：

因为信任同学A，是眼里的apple，他/她给数据、做的事都是好的、优秀的、完全值得信赖的。
不信任同学B，他哪怕做到团队中的top1 （来自团队大盘的数据）也不一定是做的好。

2、团队人力安排冗余和浪费

例子：

一个100人的大测试团队，还有额外20多人的外包测试人员。实际上只有30多人、外加所有外包人员在实际负责做业务需求。剩下的60多人很少负责业务需求，那么他们在干什么呢？

事情1：为了一个统计自动化指标，5-6个人（一个小组大部分人）在负责,人力资源冗余及低效。每周会，一个人对四五十人，低效语音会。
事情2：为了追指标，催促几十人在手工填写指标、填写某某原因，如某需求没有卡点数据、为什么没有增量覆盖率，填下原因...

3、为了数据而数据，不关心真正业务价值

统计各种数据：

1）增量覆盖率：

多少需求接入率，增量覆盖率，需要人工配置，统计。哪怕，改动一行代码，CR代码一分钟就能上线的需求、页面点点半分钟就能上线的需求，为了统计这个指标画的司机比整个集成测试时间都长；甚至很多情况下都是为了这个统计数据，额外花时间来做。

那么此时的增量覆盖率，除了「统计数据」的功效外，不仅仅不赋能业务，反而拖累业务需求进度。

个人认为，这个指标只能作为参考，QA根据实际需要选择性使用进行查漏补缺。如果QA还需要依赖这个指标来做需求测试，本身可能就是比较危险的事情。如果一名QA 刚接受业务、大型重构、大型业务需求，可能会侧重参考这个指标外。其他情况下，要么是不会白盒测试，要么不懂业务也不懂实现，才会需要使用这个指标？

2）研发测试工时比。

这个比例是多少合适。看团队A的操作：

Q3要求比例是3:1
Q4又改动，B C 端分开统计。B端业务需求比例是4:1，C端业务需求比例是3:1，不达标就要分析原因和改进措施。

这样区分B C 端，而且B端比例阈值4 ，C端比例阈值是3，本质上同样研发时间，测试时间C端更多。这样定的依据难道是B端业务线更简单、发布要求可以低些，质量水位比C端低些（B端允许比C端多出些线上问题）

个人观点：这个比例只是个最终的参考数据，光定比例没有实际意义。本质上，QA只对质量负责，不对进度负责。 QA本质上是保障每次的迭代质量，至于研发测试工时比，是个最终参考数据，整个研发、测试排期，工时只要几方认可，可接受即可。

3）项目迭代流程一刀切

就是无论项目需求大小，一律走相同的迭代流程。

例子：

一个小需求改动，本来一分钟CR代码就可以上线，甚至可以走免测的，
为了落地迭代流程，不得不走一整套完整提测（表单填写），甚至流程推广前已经上线的需求，额外再次走下这个提测流程。
走一个平台的提测，Q3 是一种提测方式，强行让接入，好不容易刚刚适应，Q4 是又走另外一种方式，对业务迭代的实际价值，却效率从来不提。

个人理解：实际上，需求本身改动大小不同，风险不同，走不同的迭代，轻量级迭代方式，一个人仅仅是小感冒，非要按大手术那一套来准备，真的有必要吗？可以按照不同需求级别、不同需求走不同迭代流程。

无论什么指标，需要遵守统计标准：

完全自动统计，不需要业务团队一线人员手动填写；
只能作为结果指标，而非过程指标；指标是来记录行为的，赶过来良性指导团队。而非指标是最终目的，团队必须改变来在此指标下做事。

4、与其他角色合作方式不合理

首先是合作规范、各自原则的约定，其次是落地。一些流程规范，是需要推动其他角色配合去做些事情的。

比如，需要推动新的提测流程，需要研发认可并落地，实际上需要push研发，而不是只会强行push 自己团队的人，这实际上是push错了对象。

5、一线管理者不懂业务、也不懂技术

除非其团队直接成员也是管理者(俗称大老板)，此时你不必知道详细，做整体规划。反之则需要，不然一定不会是一个好的管理者。

1）技术上不能提出什么好的需要优化建议、业务上也不能思考更深更远

管理本质上来说，是在业务、技术实现痛点难点基础上，合理分配资源，精力和时间。不然就会反反复复一线同学解释：

为什么重点投入业务A ，不投入业务B。
需求1 免测根本零风险，需求2 存在大风险。
自动化为什么不适用业务A, 适合业务B。

2）关注重点完全跑偏

如根据需求绝对数量来评估人力是否紧张

3）感知不到团队解决痛点难点背景和实际价值

如，按团队约定的自测规范来迭代需求，最终需求高效、高质量上线，明明是一件值得称赞的事，但由于自测需求没有那些统计指标数据，反而又在追问看起来QA人力不紧张为什么自测。

4） leader只是在做粘贴复制的事情（看有多少人吐槽就知道了）

个人理解：管理者除了向上管理之外（关乎饭碗问题自不必多说）向下管理难道只用（管理岗位本身赋予的强制性权力）就够了吗，你能给团队成员带来什么良性影响？换句话说，除了拿leader 这个身份强行push给团队一些事情外，还有别的事情吗？团队的战斗力取决于士兵也在于将军。能否彼此信任，彼此认可，敢于一起上战场？不然其实关注点完全不对就是让团队成员配合做无聊的事，业务价值输出技术输出反而却无视。

个人理解：最重要的事情一定是所有人关注的重点，只不过leader 视野更高一些。如成员需求高质量快速迭代完成产生预期收益。 leader 关注这一点，关注到整体大盘数据，成员遇到困难，我能提供什么优化建议，支持，从中协助做什么，影响力方面，技术产出方面，业务产出方面。给团队成员更多参考：别的团队横向对比指标如何，哪些是共同的，哪些是差异化的，为什么差异化？痛点。