我们在外包资源池化管理走过的弯路

作者:easongao

团队:腾讯移动品质中心TMQ

一、导读

品质中心近半年提出了外包人员效率优化的口号。各个测试团队积极响应,想出各种各样的办法来尝试节省人力。其中“外包资源池管理”是各个团队都没有放过的一种尝试手段。

其最初的理念是把各个项目中一些简单的任务识别出来,交给一波初级的外包去做。这样能解决部分外包工作不饱和问题以及降低外包的培养成本。

而在不同测试团队的具体实施中,又演化出不同的实施方案。本文记录手机QQ浏览器测试团队在“外包资源池管理”方案上的几次尝试。有沉痛的教训,也有深度的思考。

二、资源池管理的预期收益

1、外包人力的充分利用

当前外包利用不充分的情况主要有2种形式。一是任务潮汐现象导致在任务量少的时候外包工作不饱和。而因为管理或者能力上的割裂不能很好地把这些闲置的人力给利用起来。手机QQ浏览器测试团队也存在这个问题。希望能通过资源池的管理方式解决。二是由于缺少统计和管理导致的人员闲置与低效。这个问题手机QQ浏览器测试团队不多见。在这里不展开。

2、外包培养和管理的成本下降

目前外包的培养和管理职责都是落在测试经理头上的。如果外包资源池能够分担甚至包管了这部分职责,测试经理就可以把更多的精力放在产品测试本身。对项目质量以及测试经理的个人成长都有利。

三、手机QQ浏览器测试外包团队特点

1、项目割裂

手机QQ浏览器分为iOS浏览器、Android浏览器、TBS浏览服务3个大产品。具体分工上,又分为iOS测试、后台(小说、视频、资讯、广告等)测试、Android内核测试、Android UI测试、Android性能测试、TBS测试、视频文件测试7个小组。地域上也分为深圳、成都、合肥3个地方。

项目的割裂代表着业务和技能的割裂。比如说,让一个测后台的同学去理解理解TBS的下载安装流程会很费劲;而让熟悉android手机抓网络包的同学去抓iOS手机网络包也要学习半天。这种割裂会让一个外包同学掌握多个测试小组的需求和技能变得十分困难。

2、任务难度大

任务难度大的问题在Android浏览器的几个测试组里体现明显。我们按照任务需要的技能要求将任务分成高中低三档。据粗略统计,QB主线高难度任务占比为44%;TBS高难度用例占比为33%。这些高难度的用例通常以下特征:

1)涉及前端、终端、后台多方面配合;

2)无法通过终端界面验证结果;

3)测试中会遇到很多意外情况需要灵活处理;

4)需要用到一些生僻、复杂的测试工具,如inspector、fiddler等。

以广告过滤为例,需要先确认拉取到wup后台的开关,了解广告过滤功能的开关状态,然后向业务后台拉取访问站点的过滤规则,接着终端要对该规则进行处理。过程中每个环节的结果都无从通过终端界面验证结果,而要通过查看日志、配置文件、上报等方法。

3、人力紧张

各个测试组都没有长时间的闲置人力。特别是2017年上半年,iOS、后台、TBS都新增了不少业务。这半年的外包工作饱和度明显比之前更高。这样就不可能有闲置人力可以参与到资源池建设中。

从以上3点分析,我们一度悲观的认为,外包资源池管理不适合我们团队。

但是困难不是退缩的理由。我们以明知山有虎,偏向虎山行的毅力开始了我们的外包资源池方案探索。

四、他山之石

关于外包资源池,MIG内部有应用宝走在前面。公司范围内,IEG有不少的经验。所以在我们开始设计我们的资源池方案之前,我们先了解了其他团队的做法(一些关键词):

应用宝:代码覆盖率,SDK,iTest,强调外包公司的作用(包括资源池运作方案也是外包公司在出),按类型划分任务,设立统一外包接口人。

IEG:ieg有一个itest平台用于外包任务管理。该平台对我们设计开发“外包任务和日报系统”有参考价值。

五、方案1:临近小组资源池方案

方案描述:临近资源池方案是指测试内容接近的2个项目之间组成临近资源池。

方案提出思路:这个是在人力紧张的情况自然想到的一种方案。两个项目的成员互相学习对方项目的技能,最终达到人力资源共用的效果。该方案分几步走:

1)整理技能标签并对任务和外包贴标签;

2)小组内实现人力资源共用;

3)临近小组实现人力资源共用;

4)整个浏览器测试组实现人力资源共用。

在想到这个方案的时候,我以为我看到了成功的希望。

方案实施时间:2月5日- 3月31日。

失败原因:前面2步都顺利完成。进行到“临近小组实现人力资源共用”的时候发现进展慢了下来。因为临近小组技能的互相学习是需要任务驱动的(通过做任务才能真正掌握技能),但适合放入资源池的任务太少(复杂任务不放入资源池)。临近小组实现人力资源共用

目标迟迟未能达成。于是我们开始考虑新方案。

收获和教训:临近资源池的准备阶段,我们整理了外包技能集。这是一个囊个了外包测试需要用到的几乎所有技能的培训文档。为后面的工作打下了很好的基础。

六、方案2:准入准出资源池方案

方案提出思路:既然任务少,我就拉任务,我把整个浏览器测试组想放进资源池的任务都拉进来;人少我就拉人,我把整个浏览器测试组能挤出来的人力都挤出来。只要我控制好任务和人,并且用技能标签来做好任务和人之前的连接。资源池自然能运转起来!

方案描述:该方案有3个要点:任务审核、人员培训和技能标签关联。

1、任务审核:要通过任务审核的任务类型才能放到资源池来。主要是确保任务足够简单以及给任务贴上技能标签。

2、人员培训:要通过人员培训的外包才能进入资源池。主要是为了保证外包具备基本的通用技能 同时标记外包所掌握的技能标签。

3、技能标签关联:通过技能标签让任务找到对应的人去执行。下图展示了任务1和外包A是如何通过技能标签匹配上的。

在想到这个方案的时候,我以为看到了成功的希望。

方案实施时间:4月1日- 4月30日。

失败原因:这个方案理论上是可行的,但实际操作性不高。一来做任务审核、维护外包技能标签比较繁琐;二来在没有系统支持的情况下通过技能标签去配对任务和执行者不方便;最后是外包需要掌握的任务太多,第一次做任务效率低。测试经理也不放心。

收获和教训:过于复杂的流程规范注定无法落地生根,简单才是美。

七、方案3:项目带头人资源池方案

方案提出思路:既然任务太多,那我就只让真正的简单任务进来。第一次做任务效率低,我就找熟悉的人带着干!让资源池先把最简单的这部分任务接管起来。

方案描述:每个项目设立一个项目带头人。项目带头人对提到资源池的任务的质量和效率负责。为了达到质量目标,项目带头人需要检查普通成员的测试结果;为了达到效率。

在想到这个方案的时候,我以为我又看到了成功的希望。

方案实施时间:5月1日- 5月20日。

失败原因:本方案解决是“真正的简单任务”放入资源池的问题。而前面分析过,咱们浏览器测试组的其中一个特点是“任务难度大”。这个特点注定了我们组“真正的简单任务”会很少。通过统计,深圳浏览器测试组“真正的简单任务”只有4-5个人力,占总任务量的20%左右。即使我们能将这部分任务的效率提高一倍,也就只能节省10%的人力,预期收益太少。因此本方案实施了半个月就被叫停。

收获和教训:投入产出比是我们做任何事情都需要考虑的问题。不能为了资源池而资源池。

八、反思

手机浏览器组的外包资源池方案3次试错,总结出来最深刻的一条是教训是:思想不能被禁锢。如果先入为主地认为外包资源池就应该是简单任务、任务标准化,不能实际情况调整策略,只会一条路走到黑。

而事实上,对于不同的情况,需要选择不同的方案。很多关键活动到底要不要做,做到什么程度都需要根据实际情况选择。下面是我对于一些关键问题的思考:

九、方案4:参考应用宝资源池方案

方案提出思路:在经历了3次试错之后,我们找兄弟团队应用宝学习了经验。决定采用Android资源池方案。对任务和人都进行梯队划分,所有任务都进资源池,最大限度地发挥接口人的作用。

方案描述:这个方案有2个要点。一是全部人、全部任务进资源池,这样才能最大限度地调度资源;二是充分利用外包接口人角色,把任务分发、人员培养的职责都放权给他,让他把资源池的事务统统管理起来。正式接口人只负责提考核指标和协调资源。

方案实施时间:5月1日- 至今

参考应用宝的方案目前进展比较顺利。一路走来,我们越来越认识到判断一个方案好坏的标准只有一个:管用!不管黑猫白猫,抓到老鼠就是好猫。所以通过实践,证明适合我们手机浏览器组的才是最好的。

那怎么才算“管用”呢?

1、能管事

任务能准确理解,尽快分配给合适的人做。过程有反馈、少打扰,结果同步及时、信息完整。

当前资源池方案有4个关键活动能保证这一点。

(1)测试流程规范 - 保证流程统一

如下图所示蓝色是测试经理操作,红色是外包接口人操作,咖啡色是测试负责人操作。通过tapd需求模块和外包任务模块有机组合,保证任务的有效流转。

(2)任务视图 - 保证时间安排得当

如下图,接口人在安排任务的时候可以看到每个人当天已经安排了多少任务、任务优先级、任务进展和总预估工时。方便合理安排人力。

(3)任务梯队分级和任务责任人表格 - 保证任务分给合适的人

任务梯队1(白底):简单任务,所有人都会做;

任务梯队2(红底):中等难度,有3-4人会做;

任务梯队3(蓝底):高难度任务,每个项目保证2人以上掌握该项目的复杂任务。

任务梯队是为了形成任务难度分级的概念。而实际分发任务时,任务负责人表格则更实用。

下表中对每种类型任务的责任人和协助人进行了记录说明。

(4)测试方法总结

任务负责人需要保证自己负责的任务都有测试方法总结。协助人负责验收,保证如果负责人离职时,协助人能够快速顶上。

2、能管人

外包都得到合适的工作量分配,并有合理的能力评估和培养制度。

当前资源池有3项关键活动能保证这一点:

(1)饱和度均衡要求

通过“外包任务”模块的统计分析功能,可以了解到每个人的工作饱和度。及时分析原因保证人人有事干!不至于有些人特别忙,有些人特别闲。

(2)人员梯队技能图谱和梯队建设

技能图谱用于记录每个外包都掌握了哪些技能,没掌握哪些。同时有响应的课程用于培训学习。

梯队建设:

将人员分为三个梯队,对应三个梯队的任务(上文中有提到)。给外包接口人指定人员梯队提升计划,使得外包人员有计划低提升。

(3)新人培养制度

新人培养制度是为了让新招进来的同学迅速能达到第一梯队的能力要求。这里需要制定一些培训教程和淘汰规则。目前还在制定中。

3、数据透明

对外包的工作量、工作效率、工作质量有真实、便捷的评估。

这里有几项关键活动:

(1)使用“外包任务”模块统计分析功能统计外包的工作量、工作效率

(2)通过测试经理投诉管理质量

之前也有尝试过给每个任务评一个质量分,但那样运作成本太高。而通过测试经理的投诉管理则能够达到投入成本和质量监控效果的平衡。

投诉已经会从测试经理以邮件方式提出。正式接口人督促外包公司跟进解决。具体改进其实还是会落后外包接口人和任务负责人头上。

关注微信公众号腾讯移动品质中心TMQ,获取更多测试干货!

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java架构师学习

如何从一个优秀的Java程序员变成一个高薪架构师

做了4年的java程序员,一直考虑以后的发展方向。感觉不适合走管理路线的人,所以考虑继续在技术方面深入下去。 相信好多程序员都有相同的感觉,做了好多年代码民工,...

2745
来自专栏黑白安全

研究称数百万 Android 设备出货时便存在固件漏洞

据《连线》网站报道,研究人员发现,数以百万计的 Android 设备出货之时便存在固件漏洞,容易受到攻击,用户可以说防不胜防。智能手机因安全问题而崩溃往往是自己...

663
来自专栏SDNLAB

数据中心网络虚拟化技术 概要

随着云计算和大数据等新兴应用的快速发展,“数据中心即计算机”(data center as a computer)的技术发展趋势逐渐明朗。数据中心作为一台计算机...

39512
来自专栏韩伟的专栏

论可复用的游戏服务器端开发框架(一)

本文试图以游戏服务器端开发的角度,探讨在需求高度变化的环境下,可重用模块构建的可能性和基本方案。 可复用框架的必要性与可行性 在现代游戏产品的开发中,游戏服务...

3735
来自专栏鹅厂网事

互联网时代需要怎样的网管

"鹅厂网事"由深圳市腾讯计算机系统有限公司技术工程事业群网络平台部运营,我们希望与业界各位志同道合的伙伴交流切磋最新的网络、服务器行业动态信息,同时分享腾讯在网...

1845
来自专栏芋道源码1024

女博士工程师:聊聊硅谷互联网公司的开发流程

之前很多文章或多或少已经说了一些点,现在很多国内公司也参考了一些流程,最近从始至终参与并负责了两个比较大的项目。这篇文章就系统的说一下开发始终吧。总的说来,我们...

674
来自专栏CSDN技术头条

【BDTC 2015】大数据基础设施分论坛:解读大数据系统、平台与基准测试标准

2015年12月10-12日,由中国计算机学会(CCF)主办,CCF大数据专家委员会承办,中国科学院计算技术研究所、北京中科天玑科技有限公司与CSDN共同协办,...

1948
来自专栏从流域到海域

物联网如何让分布式计算再次变得酷炫

原文地址:https://internetofthingsagenda.techtarget.com/blog/IoT-Agenda/How-IoT-is-ma...

2713
来自专栏我是攻城师

谈谈我对Mac笔记本的使用感受

最早我的第一个笔记本电脑是华硕的A43S系列的笔记本,因为当时立志要做一名程序员,所以就买了个配置相对较高的,内存8G,硬盘750G,CPU是i7的,当时大概是...

813
来自专栏WeTest质量开放平台团队的专栏

云端手游测试,从未如此流畅!

? ? WeTest远程调试2.0 — 云真机今天正式上线,WeTest云真机是腾讯内部最新的游戏测试技术,远程调试性能大大提升,为广大开发者解决了3大难题:...

562

扫码关注云+社区