印度外包：承包商费率的节省与协同成本
评估在印度使用承包商的收益，通常只用一行公式：这里的费率对比那里的费率，再乘以工作量。这行公式没有错,但并不完整——它遗漏了等式的另一半,而这一半正好在您自己这边。
这另一半就是需求负责人(requirements owner):负责表述任务、回答问题、验收结果并裁定争议情形的人。他的时间不会出现在承包商的费率里,却实实在在计入工作的总成本,并且正是它决定了费率差异能否真正兑现。
承包商费率带来的节省,只有在您拥有一位与承包商保持同步节奏工作的需求负责人时才能兑现。分布式软件开发的实测数据显示,需要跨地点协同的任务所耗费的时间是同地点任务的数倍。这种延迟不是承包商本身的特性,而是协作结构的特性——它是可以提前测算出来的。
协同成本由哪些部分构成
将协同成本(coordination cost)拆解为若干组成部分,每一部分消耗的都是您自己的时间,而不是承包商的费率。
任务表述。同一个需求,向隔壁办公室的同事解释五分钟就够了,但对外部团队却必须以书面、无歧义的方式描述清楚。这不是繁文缛节,而是向对方传递其原本不具备的背景信息的唯一途径。
等待答复。时区差异会把一次澄清性提问变成半天的损耗,把两次连续澄清变成整整一天的损耗。任务描述中的每一处模糊之处,都会让这种效应不断累加。
验收与返工循环。每一轮修改都要付出一个等待周期的代价。一项任务经历三轮修改,就意味着三个日历日,而与修改本身实际耗费的工作量无关。
裁定争议情形。任务描述未覆盖到的情况,需要您做出决定。如果您不在场,承包商就会自行决定,而这个决定在他们看来是合理的。
| 构成部分 | 由谁承担 | 靠什么来压缩 |
|---|---|---|
| 任务表述 | 您方的需求负责人 | 任务描述模板与明确的排除事项清单 |
| 等待答复 | 双方,以日历时间计 | 工作时间重叠(working-hours overlap)与答复时限规则 |
| 返工循环 | 项目的日历时间 | 提前锁定的验收标准(acceptance criteria) |
| 争议情形 | 成果质量 | 客户方不在场时的裁定规则 |
第三列正是需要在合作开始之前完成的工作。四项内容都不需要预算,但每一项都需要需求负责人投入时间。
跨地点协同的实测成本有多高
延迟的规模已经在一项研究中被测量过,而这项研究恰好包含了印度的场地。
由单一场地独立完成的变更请求平均耗时约5天;需要跨场地协同的变更请求则耗时12.7天——是前者的2.5倍以上。本地任务与跨场地任务之间的延迟时长差异具有统计显著性。
这里直接说明这项研究的局限:数据来自一家科技公司,采集于上世纪九十年代末,研究对象是企业内部的分布式开发,而非客户与承包商之间的外包关系。此后通信手段已发生根本性变化。真正稳定不变的,不是倍数本身的数值,而是延迟的结构性成因:延迟并非产生于沟通渠道,而是产生于对"什么算作已完成"的确认过程。我在关于分布式团队就绪度的文章中分析过同样的规律。
印度外包市场的规模
据预测,印度技术行业的工程与研发服务出口额将达到560亿美元,而六年前这一数字为330亿美元;该国占全球技术出口的27%。全球能力中心(global capability centre)雇用了超过190万名专业人员,创造了超过600亿美元的价值。
这一局限是实质性的:该数据并未说明"研发服务"这一类别具体包含哪些内容,也未说明能力中心的统计口径如何确定。这里仅将其作为数量级参考使用。对协作模式选择而言,更具实际意义的结论是另外一点:全球能力中心占比的持续上升,说明成熟的客户方正越来越多地在当地组建自有团队,而不是选择外包(outsourcing)——而这样做的原因,恰恰是协同成本。
值得了解的监管框架
《2019年工资法典》(Code on Wages, 2019)于2019年7月23日提交至议会下院,7月30日经下院通过,8月2日经上院通过。该来源并未反映其正式生效的最新状态。
这里仅限于陈述该法案已通过议会这一事实,并明确说明其适用状态尚未通过官方信息源核实。对客户方而言,由此产生的实际结论只有一条:合作关系模式——外包(outsourcing model)、劳务派遣还是自建中心——在劳动监管方面的后果各不相同,这一选择应与当地法律顾问共同做出,而不是取决于时薪高低。
费率节省何时才是真实的
第一个条件成本最高,也最常被省略。在任务持续不断的情况下,己方的需求负责人所投入的时间不应少于其工作时间的四分之一;如果没有事先安排出这部分时间,它照样会被消耗掉——只不过是以被打断的方式消耗,并且任务描述的质量也会随之下降。
第四个条件常常招来反对意见:"让他们来问就好了。"但实践显示的情况恰恰相反——客户方不在场时,决定照样会被做出,只是没有客户方参与而已。一条明确的规则(例如"若24小时内未收到答复,则选择最简单的方案,并将该决定以书面形式记录下来")带来的是可预期性,而不是随机性。
与承包商开始合作前的四个条件
为需求负责人安排时间
这不是一个兼职角色。在任务持续不断的情况下,这会占用工作时间中相当可观的一部分。
在启动前锁定验收标准
每种任务类型设定三到四条标准。每一条未明确的标准,都意味着多一轮返工循环(rework cycle)。
就工作时间重叠与答复时限达成一致
两到三小时的重叠时段加上一条答复规则,可以消除日历时间延迟中的绝大部分。
明确在您未答复时该如何处理
无论如何,决定都会被做出。规则的作用是让这个决定变得可预期。
如果收益测算中没有一行对应您方员工时间的成本,那么这份测算描述的就不是项目的经济账,而只是两份报价单之间的差额。
常见问题
把开发工作外包给印度的承包商划算吗?
只有当己方满足四个条件时才划算:为需求负责人安排专门时间、在启动前锁定验收标准、工作时间重叠并配合答复规则、以及在己方不在场时的裁定规则。若不具备这些条件,费率差异就会被日历时间吞噬:分布式开发的实测数据显示,涉及跨地点协同的任务所耗时间是同地点任务的数倍。
如何降低协同成本?
需要压缩的不是沟通本身,而是不确定性。一份带有强制性排除事项清单的任务描述模板、三到四条验收标准,以及一条约定时限内的答复规则,能够消除大部分澄清循环。增加会议次数只会适得其反:它是在用最昂贵的方式弥补书面标准的缺失。
是选择外包,还是在当地自建中心?
这取决于任务量的大小以及任务流的持续性。在负载波动、任务类型有限的情况下,外包模式(outsourcing model)是合理的选择;而当任务流持续稳定时,协同成本就会变得与费率差异相当,成熟的客户方也会转而选择自建中心——印度此类中心数量的增长正体现了这一点。这项决定应与当地法律顾问共同做出:两种模式在劳动监管方面的后果并不相同。
二十年前的测量数据还适用吗?
倍数本身——不适用。延迟的结构性成因——仍然适用。这项研究是在现代通信工具出现之前完成的,研究对象是企业内部的分布式开发,而非客户与承包商之间的合作关系。但延迟的根源并不在通信渠道——通信渠道此后已发生根本性变化——而在于对"什么算作已完成"的确认过程,而这一延迟根源无法通过工具来消除。
作者的履历中包含与承包商及分布式团队合作的经验,其中包括一种购买承包商员工工作时间的合作伙伴模式,以及与中国承包商合作的经历。现有资料中并未记载与某家印度承包商合作的具体项目,因此本文以官方及研究性信息源为基础撰写,不包含任何内部数字指标。文中列出的四个条件以及对协同成本的拆解,是作者基于与外部服务提供方合作的实践所做的归纳总结,而非对某个具体案例的描述。本文不构成法律意见。
- Herbsleb J. D., Mockus A., Finholt T. A., Grinter R. E. An Empirical Study of Global Software Development: Distance and Speed. ICSE, 2001. mockus.org
- NASSCOM. 印度技术行业概览. nasscom.in
- PRS Legislative Research. The Code on Wages, 2019:法案跟踪页面. prsindia.org