惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

NISL@THU
NISL@THU
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
D
Darknet – Hacking Tools, Hacker News & Cyber Security
阮一峰的网络日志
阮一峰的网络日志
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
WordPress大学
WordPress大学
IT之家
IT之家
Cyberwarzone
Cyberwarzone
博客园_首页
博客园 - 聂微东
V
Visual Studio Blog
Cisco Talos Blog
Cisco Talos Blog
V
Vulnerabilities – Threatpost
Google DeepMind News
Google DeepMind News
Schneier on Security
Schneier on Security
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
The Hacker News
The Hacker News
雷峰网
雷峰网
Last Week in AI
Last Week in AI
Spread Privacy
Spread Privacy
L
Lohrmann on Cybersecurity
O
OpenAI News
人人都是产品经理
人人都是产品经理
AWS News Blog
AWS News Blog
小众软件
小众软件
T
Tailwind CSS Blog
The Cloudflare Blog
L
LINUX DO - 最新话题
有赞技术团队
有赞技术团队
Know Your Adversary
Know Your Adversary
The GitHub Blog
The GitHub Blog
L
LINUX DO - 热门话题
Y
Y Combinator Blog
Stack Overflow Blog
Stack Overflow Blog
B
Blog
MyScale Blog
MyScale Blog
S
SegmentFault 最新的问题
S
Schneier on Security
The Last Watchdog
The Last Watchdog
Application and Cybersecurity Blog
Application and Cybersecurity Blog
Security Archives - TechRepublic
Security Archives - TechRepublic
大猫的无限游戏
大猫的无限游戏
罗磊的独立博客
Blog — PlanetScale
Blog — PlanetScale
博客园 - Franky
I
InfoQ
P
Proofpoint News Feed
量子位
S
Security @ Cisco Blogs

阮一峰的网络日志

科技爱好者周刊(第 396 期):互联网通信的替代方案 科技爱好者周刊(第 396 期):互联网通信的替代方案 - 阮一峰的网络日志 科技爱好者周刊(第 395 期):软件开发的第三种方式 科技爱好者周刊(第 395 期):软件开发的第三种方式 - 阮一峰的网络日志 科技爱好者周刊(第 393 期):脑腐状态 科技爱好者周刊(第 392 期):axios 投毒与好莱坞式骗术 科技爱好者周刊(第 391 期):AI 的贫富分化 科技爱好者周刊(第 390 期):没有语料,大模型就是智障 套壳中国大模型撑起500亿美元估值?扒一扒 Cursor 的"套壳"疑云 科技爱好者周刊(第 389 期):未来如何招聘程序员 科技爱好者周刊(第 388 期):测试是新的护城河 零安装的"云养虾":ArkClaw 使用指南 科技爱好者周刊(第 387 期):你是领先的 科技爱好者周刊(第 386 期):当外卖员接入 AI 字节全家桶 Seed 2.0 + TRAE 玩转 Skill 科技爱好者周刊(第 385 期):马斯克害怕中国车企吗? 智谱旗舰 GLM-5 实测:对比 Opus 4.6 和 GPT-5.3-Codex 科技爱好者周刊(第 384 期):为什么软件股下跌 科技爱好者周刊(第 383 期):你是第几级 AI 编程 Kimi 的一体化,Manus 的分层 科技爱好者周刊(第 382 期):独立软件的黄昏 AI native Workspace 也许是智能体的下一阶段 科技爱好者周刊(第 381 期):中国 AI 大模型领导者在想什么 科技爱好者周刊(第 380 期):为什么人们拥抱"不对称收益" 科技爱好者周刊(第 379 期):《硅谷钢铁侠》摘录 我如何用 AI 处理历史遗留代码:MiniMax M2.1 升级体验 科技爱好者周刊(第 378 期):预测是新的互联网热点 科技爱好者周刊(第 377 期):14万美元的贫困线 科技爱好者周刊(第 376 期):太空数据中心的争议 科技爱好者周刊(第 375 期):一扇门的 Bug 终于有人做了 Subagent,TRAE 国内版 SOLO 模式来了 科技爱好者周刊(第 374 期):6GHz 的问题 VS Code 使用国产大模型 MiniMax M2 教程 科技爱好者周刊(第 373 期):数据模型是新产品的核心 国产大模型接入 Claude Code 教程:以 Doubao-Seed-Code 为例 科技爱好者周刊(第 372 期):软件界面如何设计 大模型比拼:MiniMax M2 vs GLM 4.6 vs Claude Sonnet 4.5 科技爱好者周刊(第 371 期):一个乐观主义者的专访 科技爱好者周刊(第 370 期):正确的代码高亮 错误处理:异常好于状态码 科技爱好者周刊(第 369 期):Tim 与罗永浩的对谈 科技爱好者周刊(第 368 期):不要这样管理软件团队 一天之内,智谱和 Anthropic 都发了最强编程模型 科技爱好者周刊(第 367 期):Nano Banana 的几个妙用 科技爱好者周刊(第 366 期):旧金山疯狂的 AI 广告 科技爱好者周刊(第 365 期):流量变现正在崩塌 科技爱好者周刊(第 364 期):最难还原的魔方 科技爱好者周刊(第 363 期):最好懂的神经网络解释 科技爱好者周刊(第 362 期):GitHub 工程师谈系统设计 科技爱好者周刊(第 361 期):暗网 Tor 安全吗? 科技爱好者周刊(第 360 期):Dan Wang 的新书 科技爱好者周刊(第 359 期):Palantir 值得关注 科技爱好者周刊(第 358 期):如何拯救一家濒临倒闭的创业公司 扣子空间网页设计,是在挑战 V0 吗? 《唐纵日记》摘录 科技爱好者周刊(第 357 期):稳定币的博弈 科技爱好者周刊(第 356 期):公司强推 AI 编程,我该怎么办 科技爱好者周刊(第 355 期):两本《芯片战争》 科技爱好者周刊(第 354 期):8000mAh 手机电池,说明了什么? 科技爱好者周刊(第 353 期):苹果的"液态玻璃"是为了 AR 科技爱好者周刊(第 352 期):Bug 追踪系统的正确样子 科技爱好者周刊(第 351 期):GitHub Issues(几乎)是最好的笔记应用 科技爱好者周刊(第 350 期):Java 三十周年 科技爱好者周刊(第 349 期):神经网络算法的发明者 科技爱好者周刊(第 348 期):李飞飞,从移民到 AI 明星 科技爱好者周刊(第 347 期):冷启动的破解之道 科技爱好者周刊(第 346 期):未来就是永恒感的丧失 科技爱好者周刊(第 345 期):HDMI 2.2 影音可能到头了 科技爱好者周刊(第 344 期):制造业正在"零工化" 科技爱好者周刊(第 343 期):如何阻止 AI 爬虫 科技爱好者周刊(第 342 期):面试的 AI 作弊----用数字人去面试 科技爱好者周刊(第 341 期):低代码编程,恐怕不会成功 科技爱好者周刊(第 340 期):技术炒作三十年 科技爱好者周刊(第 339 期):代币是什么 科技爱好者周刊(第 338 期):重新思考 6G 科技爱好者周刊(第 337 期):互联网创业几乎没了 科技爱好者周刊(第 336 期):面对 AI,互联网正在衰落 科技爱好者周刊(第 335 期):年底的未来已来 科技爱好者周刊(第 334 期):年终笔记四则 科技爱好者周刊(第 333 期):一切都要支付两次 科技爱好者周刊(第 332 期):西蒙·威利森的年终总结,梁文锋的访谈 科技爱好者周刊(第 331 期):你可能是一个 NPC 科技爱好者周刊(第 330 期):李开复梳理人工智能 科技爱好者周刊(第 329 期):示意图利器 D2 科技爱好者周刊(第 328 期):AI 模型不是一门好生意 科技爱好者周刊(第 327 期):没有链接的互联网 科技爱好者周刊(第 326 期):世界没有那么多财富 科技爱好者周刊(第 325 期):VS Code 编辑器的下一站是 Zed? 科技爱好者周刊(第 324 期):人类已知的最大质数 科技爱好者周刊(第 323 期):技术公司的口号比拼 科技爱好者周刊(第 322 期):内容行业的内幕 科技爱好者周刊(第 321 期):傅盛回忆录 科技爱好者周刊(第 320 期):乒乓仓 科技爱好者周刊(第 319 期):如何拍出爆款视频 科技爱好者周刊(第 318 期):创业咖啡馆的记忆 科技爱好者周刊(第 317 期):驴子、老虎和狮子的寓言 科技爱好者周刊(第 316 期):你一生的故事 科技爱好者周刊(第 315 期):一份谷歌离职报告 科技爱好者周刊(第 314 期):《黑神话:悟空》可以产业化吗? 科技爱好者周刊(第 313 期):如果新加坡没有空调
我的外包经验:印度、中国和菲律宾(译文)
阮一峰 · 2020-02-27 · via 阮一峰的网络日志

外包在软件业很常见,各种规模的公司都在用,每年要吸纳大量就业。

但是,外包的曝光量很少,大家似乎都不太关心,很少有人谈论。这导致许多人不了解外包到底是怎么回事。

本周,我读到 Troy Hunt 在2016年的一篇旧文,介绍他的外包经验。我觉得,读起来很新鲜,有启发。下面就是节选的译文,插图是我配的。

我的外包经验:印度、中国和菲律宾

作者:Troy Hunt

原文网址:troyhunt.com

1、

我有很多与亚洲外包供应商合作的经历。这篇文章我想来谈谈,多年来将软件项目外包到印度,中国和菲律宾的经验。

我以前的工作是辉瑞公司的软件架构师,一共干了14年,曾经负责过亚太地区的软件架构。

2、

辉瑞公司的软件开发策略很简单,就是将所有事情外包。

这是行业的标准做法,我因此跟亚太地区数十个软件供应商合作过,参与了各种各样的项目,范围很广,从简单的产品宣传网站到大型临床研究系统,从移动应用 App 到 POS 机的终端程序。

我对印度、中国和菲律宾的软件外包行业,接触得比较多,感触尤其深,我想讨论对它们的观察。

3、

辉瑞公司为什么要外包?

原因很简单,因为程序员很贵。你必须花很多钱,雇佣很多人来构建软件产品,无论他们是否在工作,你都需要支付薪水。而且你雇来的程序员不一定懂每个项目所需的特定技能,这意味着你还要雇佣更多的人。

外包就相当于"云程序员",你可以只在需要的时候去用它,只为所消费的东西付费,因此减轻了自己公司的负担。

4、

外包一般都选择亚洲,因为其他地方的工资太高。澳大利亚很贵,美国很贵,英国很贵,上图是世界银行的人均收入数据,这三个地区与印度、中国、菲律宾。

以我的经验,前三个国家的外包公司小时工资,比后三个国家贵4到5倍。

5、

先来看印度。这个国家已经成为离岸外包的代名词,在许多 IT 经理的心中,外包就等于印度。原因有很多。

  • 印度当过英国的殖民地,印度人的英语水平很好。
  • 印度拥有超过13亿人口,这意味着它有源源不断的工程师。
  • 印度的外包行业很成熟,外包巨头 Tech Mahindra、Infosys、Wipro 有规范的外包流程,在这个领域进行了大量投资。

6、

印度许多程序员都是通过单项技术的强化培训而大量生产的,往往只懂培训教的非常特定的技术栈。我常常发现,他们只懂软件组件的一个独立部分,而这就是他们要做的全部事情。

这对项目带来的后果就是,最终会导致很多人参与其中。我查看工作量估算,向外包负责人提问:"为什么需要这么多人?"。里面会有初级程序员、高级程序员,专门从事 API 开发的人员,负责网站的人员,负责数据库的人员等等。有些项目由于庞大的规模,需要这样做,但即使是很小的项目,也是这个样子。

7、

印度的另一个问题是流失率,程序员总是在离开。传统的公司忠诚度在印度并不盛行,大多数人在一家外包公司不会超过一两年。程序员总是去其他地方寻求更好的机会,这无可厚非,但是这种流失率意味着项目会产生更多的摩擦。这些并不会出现在你的外包合同中。

我还发现,印度程序员对需求文档要求很高,他们始终要求真正详细的文档。其他地方的程序员也要求需求文档,但在印度这个要求更强烈,细节对印度人来说很重要。很多时候,我们假设软件应该包括的功能,事后发现这些功能被认为是"超出范围"。这可能在全世界任何地方的任何项目中发生,但在印度极为盛行。

最合适外包到印度的项目,我认为最好是一个独立的工作单元,范围有着明确的界定,文档齐全,并且完全遵循印度公司现有的模式。你要知道,那里的程序员接受的是非常具体的事情的训练,并以工厂流水线的心态在开发,你按照他们的模式,那就会走上"快乐之路"。

8、

接着来谈谈中国。

中国正在快速城市化,越来越多的人口接受高等教育。他们是一个非常精通技术的国家,在这方面不断壮大,从新兴的硬件提供商变成现在占主导地位的厂商,比如华为和联想,也有像阿里巴巴这样的非常强的服务类公司。这些公司如今已经进入了世界舞台。如果您热衷于技术而不关心中国的动态,那么可能会错过未来几十年世界上最重要的技术创新和增长来源。

9、

对于外国人来说,中国人并不容易合作,主要原因是外语水平。中国的内部市场很大,几乎所有项目都有自己的中文服务,因此中国人接触英语的机会很有限,如果要跟他们清晰的沟通可能是一件很棘手的事情。

这意味着,你几乎总是与实际从事开发的程序员,至少隔了一层。通常会有一个具有一定英语技能的客户经理,你与他联系,他再把你的意思翻译给技术人员。这样的后果就是,当你真正需要进行详细讨论时,没法跟程序员直接沟通。中国程序员会在内部自己商量,你不知道他们在想些什么,并且很多东西在翻译过程中丢失了。

这对代码质量有深刻影响。从功能上讲,代码本身可能还不错,但这是很少或几乎没有英语技能的人编写的代码。高质量软件的要求之一,就是代码本身就是自我记录的文档,这一点很难实现。他们的代码可能无法清晰地描述软件的功能,不仅对作者也对将来维护的人,都很难阅读。

要是你愿意一直跟同一个软件供应商合作,那可能不会成为问题,但如果你收回代码或交给其他人维护,就会遇到严重问题。我的切身体会是,很难评审中国程序员编写的代码。另外,语言障碍对用户界面也有影响,那些编写代码的人由于不太了解英语,编写的​​标签和标题可能会使英语用户不适应,这意味着要进行许多意想不到的(且预算未定)的修订。

10、

我有一个习惯,一直要求供应商提供工作分解表。如果我要外包一个具有20个功能的应用程序,那么我想知道每个功能要花多少钱。然后,我可以评估,讨论一下每个功能的重要性,是否要通过放弃价值较低的功能来降低成本。

但是在中国,供应商无法提供这种表格,因为他们不是以这种方式核算成本。他们给我的细分,只是有多少个大三和​​大四的学生、项目经理、测试人员参与,他们每个人的花费是多少。在我看来,这根本没用,但我也没办法。

中国的另一个现象,就是工时非常高,他们会投入大量的时间。我很清楚地记得一个案例,中国供应商的报价与澳大利亚的本地供应商相同,而工时却大了一个数量级。

11、

中国现在变得越来越昂贵,根据我得到的消息,北京程序员的薪水是两位数的涨幅,有报告称,他们的年薪约为25,000美元,而孟买的年薪约为7,000美元。这是一个非常重要的差异。

中国的优势之一(尤其跟印度相比)就是对需求文档的要求不高。中国有一种真正的"可以做"的态度,不管你提什么要求,他们都愿意拿起任何东西去尝试。不过,虽然他们对任何事情都会说"是",但是实际上的意思很可能是"否"或别的,这里会存在风险。但是总的来说,我发现他们的适应性非常强,这是一大优势。

我更倾向于外包给中国,因为那里更加灵活,限制也更少。不过由于语言障碍,与新的供应商合作期间,涉及的摩擦也更大。

12、

再来谈谈菲律宾。

我在马尼拉度过了很多时间,可以很自信地说,菲律宾人是你在任何地方所能遇到的最友好的一群人。由于菲律宾当过美国的殖民地,所以当地人的英语水平很出色,英语是菲律宾排名第二的官方语言。你在马尼拉的任何地方,都能毫无问题地被理解,并与当地人进行交流。

近年来,我注意到的一件事是,呼叫中心转移到菲律宾的趋势很明显。以前你打客服电话,是印度人接听,现在每次我打给电信公司,都会与菲律宾人交谈。我认为,这是他们强大的英语能力,友善的性格和新兴的科技行业共同作用的结果。另外,菲律宾的薪水比中国低得多,更接近印度。

13、

菲律宾是一个贫困的国家,到处都可以看到这一点,特别是在前往机场的路上穿过摇摇欲坠的房屋时。

这对技术领域也产生了影响,我在外包中看到的最明显的一点,就是菲律宾程序员对 PHP 的强烈亲和力。这样说并不是要贬低 PHP,而是 LAMP 技术栈的低成本造成的。辉瑞公司所使用的 Microsoft 技术栈在菲律宾很难找到市场。你随便去一家供应商,他们的默认态度总是"是的,我们将用 PHP 和 MySQL做到你们的需求。 "尽管我们后来确实找到了可以使用 Microsoft 技术栈的供应商,但我始终觉得它们并不受到重视,这让我对他们的技术能力有些担心。

14、

在成本上,菲律宾肯定比中国低,而且经常比印度低。根据现在的趋势,这种情况大概会保持很长一段时间。

在许多方面,菲律宾是世界上最好的。除了成本,他们还有这个价格的国家中最好的英语技能,友善的性格,以及我在中国观察到的相同的"可以做"的态度。

15、

最后,谈谈我的外包经验。

首先,外包是一种不稳定的商品,因为程序员是不稳定的,尤其是在印度。我们当时与一家孟买的开发商合作,花了很多时间和金钱培训一个叫做 Avni 的程序员,让她掌握所需的特定技术。这个项目进展顺利,但是有一天,Avni 离开了。我怀疑她要去生孩子了,根据我的经验,这种情况通常会在发生几个月后才通知你。开发商跟我们说不要担心,会给你找另一个 Avni,跟上一个一样!

开发人员不是可以替代的商品。你不能简单地用一个人去替代另一个人,然后期望他们同样地工作。我经常看到外包供应商信誓旦旦地断言,他们能够像更换厨房灯泡那样简单地更换程序员。这是一种危险的不称职的信念,表明对软件开发的实际情况有根本的误解。

16、

第二点,外包软件的质量,不一定能够在项目交付时看出来。通常要花上数月甚至数年的时间,才能意识到你所承担的"技术债务"的成本。供应商开发完软件,将其移交给客户之后,如果客户以后要添加功能,发现代码难以辨认,将花多少钱才能解决?在软件产品生命周期中,长期的成本通常被忽略,因为人们争先恐后地希望立即节省短期成本。

我从未见过,外包供应商为项目编写任何单元测试!他们没有自动化测试流程,总是用人工测试确保一切正常。开发人员甚至从未听说过自动化测试这种概念,因为编写额外的代码将花费更多的金钱,一切在他们看来理所当然。所以,外包项目的长期可维护性和成本是可怕的。

17、

第三点,如果想让外包成功,最好采用混合模式。不是"将所有事情外包",而是"让我们的人与他们的人一起工作,各自做自己最擅长的事情"。

我花了大量时间,到世界各地的外包公司,培训他们的开发人员,跟他们的团队待在一起,交谈要开发的项目。我遇到了各种坏的故事,但也有一些非常积极的经历。

避免依赖外包组织中的个人,比如上文的 Avni,外包行业的人员流动性比一般情况大得多。相反地,应将重点放在让更多人一起参与,如果其中一个离开,你就不会损失太多的项目知识。

还可以多应用一些开发工具,比如代码质量检查工具、构建服务、版本管理等等,让工作过程变得更加可预测。

18、

第四点,也是最重要的一点,不要把小时费率视为外包成功的指标,不要根据报价的高低选择供应商。

外包给哪个供应商,通常是由公司内部对软件开发了解最少的人决定的。低报价吸引了他们,只考虑了短期成本和交付条件,没有将长期成本(诸如可维护性,可用性以及安全性之类的因素)考虑在内。因为公司的预算和业务目标总是聚焦在短期,难怪那些掌握资金却不了解技术的人做出了不明智的外包决策。

廉价的离岸外包是软件行业的麦当劳。因为需求量很大,外包公司就把软件开发做成了批量生产的产品。但如果你一直吃麦当劳,就不是很好。你最好将外包视为均衡饮食的一部分,做出明智的决定,不要因标价低而盲目选择,不考虑要支付的实际成本。

(完)