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

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

随着外包团队规模的扩大，以及安全和效率管控的需求，越来越多的外包项目采用 ODC 场地办公模式（Offshore Development Center），国内的外包行业把甲方公司以外建设的技术中心统称为 ODC，而跨国企业通常把 ODC 定义为跨国的离岸技术中心。本文引用国内的 ODC 概念，泛指远程技术中心。

在上节介绍的外包高效管理经验之上，我们进一步阐述如何让 ODC 远程管理更加完善。

伴随这些年的疫情影响，在家远程办公也成为外包合作的常见形态，员工越来越多地通过分布式在线协作完成工作，而不是在公司场地集中办公，所以远程办公管理的提效也成为非常重要的议题。

本文的相关经验也适合多地联合研发团队的敏捷管理。

敏捷研发的本质是尽可能 “团队在一起”，而 ODC 这类远程团队难以实现这一点，我们的管理逻辑一定是：交付目标清晰可量化，沟通信息充分且成本足够低。

1）参考上节内容，确保 ODC 的建设和入驻，符合公司系列安全规范要求。办公环境、测试环境和测试设备满足要求，不会阻碍工作效率。

2）完成 ODC 承接任务类型的优化。从适合当前 ODC 团队能力的测试种类中，选择适合远程交付（验收标准容易判断）的内容。具体来说下面这些特征的工作适合远程独立完成。

工具成熟，使用方法稳定，掌握难度比较小的自动化/手工测试。
任务成果容易度量，工作容易拆解到个人完成交付。但如果外包组长评估工作复杂度的能力够强，可以不要求任务容易拆解，通过团队总产出来判断效益即可。
产品逻辑梳理比较明确，参考文档完整清晰。日常不依赖甲方人员频繁讲解需求规格。
对于要上报的故障有清晰统一的描述指南或规范，不容易发生个人理解偏差。

3）建立远程管理的双向沟通机制。

甲方外包负责人（包括接口人）定期去 ODC 现场办公和走访，参与例会，观察远程团队工作状态是否积极健康。可以安排负责人和员工代表面对面沟通会，对发现的问题讨论整改，搜集远程团队的满意度诉求，现场答疑或提供后继支持。

外包方项目经理和组长，定期去甲方团队参与关键例会，熟悉甲方工作流程和关键业务信息，回 ODC 进行传递。

双方关键角色或代表，可参与对方团队的团建活动，加深团队互信。

4）建立简单高效的培训机制。

ODC 的培训模式应该是逐步实现自我培训。甲方提供初期培训（现场或远程都可以），课程刷新和专家答疑。ODC 选择合适的骨干人员，通过培训和实战认证后，成为内部讲师，负责内部新人的相关培训和辅导。

甲方也可以安排专业骨干，在 ODC 进行一个或数个迭代的现场办公，受训新人跟随他一起承担工作，观察他的实际操作，解决问题的思路。迭代完成后，受训者要写总结心得，或者完成测验。这种现场实战培训效果更加明显。

对于 ODC 新人众多的情况，还可以安排脱产集训，精选出基础课程系列，集中封闭授课和考试，成效也非常明显。

尽可能避免外包新人加入团队一脸茫然。用最短的时间就能开始工作，也就同时提高了稳定性。

5）信息充分互通。

ODC 测试产出数据有时不太理想，分析根本原因不一定是员工的水平或态度问题，而是缺乏需求研发的上下文信息。干巴巴的有限文档无法还原足够的信息，远程询问信息又不太方便，对内部人员也会有一定的打扰。

敏捷的本质就是频繁沟通和团队探讨，虽然我们尽可能把直观且独立的任务发到 ODC，但是相关需求背景信息仍然是多多益善的。甲方负责人有义务保障信息互通的高效性：

任务发布给 ODC 前，是否所有需求文档都在线更新了？对于大型需求或产品版本，是否组织了需求答疑？
是否存在影响测试验收的信息没有同步 ODC 人员的情况？内部团队要将已知的用例失效场景、内部遗留缺陷、用户答疑等关键信息及时上传到任务须知里。
提高文档的可视化。归档能帮助人员理解架构的视图、业务逻辑时序图、缺陷操作视频或截图等。
如果工作交付依赖甲方人员的协作，那么双方管理者要尽快建立双方员工的直接沟通机制。

下面用一个真实案例来说明我们如何思考和提升 ODC 测试管理效能。

某外包团队（100 多个人员）负责集团所有互联网软件的手机内置适配测试项目，总计约 20 多个 APP 产品，划归到我这边进行管理。现状是，这个团队人力零散分布在手机系统测试部门的多个城市的 8 个外包 ODC 中，跟随手机上市计划进行互联网产品的适配测试。所有人员都纳入人力资源池，按手机项目排期和对应用例集安排工作，人员没有特定能力标签，有什么待测产品分过来就测什么。

当前的外包使用模式效能一定比较低下，原因显而易见：

没有专职接口人对于这么多人员的分工和产出效果进行整体把控。
团队分散多地，无法沉淀测试知识和业务知识，没有团队归属感，技能树无法建立。
手机系统测试的节奏、质量标准、会议频率，和互联网测试的模式差距甚远。互联网软件发布更快速，可以自动更新，质量要求不需要像底层软件那么高，也不需要遵循那么繁重的评审流程。大量人力耗费在跨系统的会议和讨论上。
一个互联网产品通常先完成主线研发和测试，上线应用商店，再内置到手机中发布。而该外包团队脱离了互联网产品研发团队的日常工作，除了被测产品的用例，没有获得多少业务信息和测试背景知识，更没参与过需求评审会。因此团队对功能的理解度低，和开发沟通处理的效率也很低。
这种工作模式下，还会带来更多问题：人员成长慢，流失率高，分派任务简单粗暴（按用例数量而不是复杂度），机器到位慢带来无谓等待，等等。

通过对症下药和不断优化管理模式，我们组建了全新的 ODC 团队来完成原有的工作，并将团队人力分批缩小到原来的三分之一，但各项效能指标还提升了。核心措施有下面这些：

1) 建设一个集中地点的全新 ODC 专门负责互联网内置适配测试，放入现有地点的成员。缺口人力按编制从其他 ODC 置换过来。因为原本就是单纯的人力池，置换比较容易。

集中在一起管理，为后继的组织效能提升迈开第一步。

2) 按互联网业务的真实研发架构重新分组，每个互联网研发部门（对应负责几个联动密切的互联网产品）对应一个内置适配测试小组，小组长和成员就尽量固定下来。

相应互联网产品的内部测试接口人（适配 TE）也就固定下来了，他有责任传递内置测试需要知道的所有关键产品信息，以及负责更新适配用例。组长和适配 TE 在项目中不断完善成员的能力标签并安排相应培训，让未来的任务分工能更有弹性。

3）ODC 运作效率要想达到显著提升，两个专职的内部关键人员不可或缺，一个是互联网内置测试的 PM，一个是内部适配 TE 的负责人。

前者负责挡住系统侧的过度测试要求和不必要的流程，简化互联网测试各阶段完成标准，由互联网团队承担内置事故的后果，明确了开发修复缺陷的时效纪律，以及上市后的观测指标。

后者负责 ODC 运作效率的观察、考核和改进，并引入成熟的进阶任务类型。比如：挤出日常人力分工的估算水分；控制不必要的加班；缩短过长的培训周期；引入主线测试任务、探索测试/众包测试任务，来填充任务等待期的工作安排。

4）打通互联网产品主线研发测试和 ODC 内置测试的信息渠道，要把因为信息没有同步造成 ODC 无效测试的事件减少到最低。甚至通过尽早帮助主线研发做非内置的机型测试获得对产品需求的理解，等到内置测试时就轻车熟路了。

5）团队在负责人的带领下定期更新和精简内置适配用例集，通过驱动主线开发人员做耦合分析，识别哪些场景 APP 会调用 OS 控件或系统第三方的组件功能，这些场景用例会作为适配重点，而产品本身逻辑功能只测试最小集，主体质量由主线研发团队保障。
结果就是内置适配用例总数在 APP 不断更新的情况下还持续下降了。

最终，ODC 运作的人均效能在一年半的时间内提升 2 倍，团队人数大幅下降的同时交付了更多的任务成果，加班情况也比其他外包团队少很多。