测试团队管理——如何判断一个差的管理者_工时缺陷比 开发测试

目录

引言

1、双标问题严重

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

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

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

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

---

引言

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

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

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

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 关注这一点，关注到整体大盘数据，成员遇到困难，我能提供什么优化建议，支持，从中协助做什么，影响力方面，技术产出方面，业务产出方面。给团队成员更多参考： 别的团队横向对比指标如何，哪些是共同的，哪些是差异化的，为什么差异化？痛点。