“ 很多公司和团队选择把整个软件项目或项目中某些模块或过程（比如测试）整体外包给另一家公司或团队。本文将和你一起来探讨为什么公司或团队有外包的冲动，为什么项目外包问题多和我对外包的建议。”
公司或团队选择把项目外包，无非就是想省钱、省事和转移风险。
省钱
一个软件项目需要各种专业角色，包括项目经理、技术主管、架构设计师、需求分析师、程序员、测试员、环境工程师等。具备这些专业技能的人才除了在市场上比一般人才的工资要高以外，培养这些人才的能力，都需要高昂的人力成本。
理论上，外包公司已经具备这样的人才。通过项目整体外包，作为甲方只需要关注项目的整体预算。乙方公司招聘、培育人才的成本会被平摊到各个外包项目中。
省事
还是和人有关。自己维持一个项目团队，涉及到招聘、培训、管理、团建、激励、绩效等多种人事管理开销。而作为甲方，短期而言，真正想要的是项目的产出——软件系统，而非一个专业团队。
项目管理和项目交付过程也是超级麻烦事，外包可以只关注结果，不需要管过程。
风险转移
项目交付存在巨大的不确定性，过程中充满风险。项目外包，也可以把项目交付出现问题的责任转移给外包公司。
这些因素都充满诱惑力。
但事情真的有那么美好吗？
02 为什么软件开发问题多从我的标题，大家已经可以知道我的结论，就是我不建议软件开发通过外包的形式来完成。
我们知道，现代社会是一个陌生人协作的社会。一个组织、一家公司、一个团队的能力和精力都是有限的。把非核心能力的业务外包给其他组织、公司、团队是再正常不过的事情，我并非反对一切外包行为。
我想说的是，有些东西可以外包，有些则不能。要看某项事物是否适合外包。为什么软件开发就不太适合外包呢？
我们来看软件开发有什么特性。我将通过边界、估算、验收和合同四个方面来分享我的观点。
边界
一谈到软件项目，大家一定会想到超支、延期、加班等等。所有这些，都和一个重要因素有关，就是边界不清晰。
光是在需求这个源头，就经常出现需求不清晰、需求泛滥等问题。这些情况，就算是我们自己开发，和用户坐在一起都会经常遇到和难以解决。我们怎么能指望离岸的外包团队能更好地解决这些问题呢？
另外一个最核心的问题是，有人总结得很好，从农业时代、工业时代过渡到知识时代，最大的变化就是我们的工作对象从物品变成了事情。物品的边界是清晰的，所需要的工作时间是有限的。所以在工厂，可以通过计件来量度一个工人的产出和效率。
而事情的边界是可以无限扩充的，可以膨胀成任何规模的工作。也很难量度一个知识工作者的产出。
几乎所有的知识工作，都有这样的特性。软件项目也是其中的典型例子。一个看似简单的需求，一旦挖掘到细节，就可以无限泛滥。我想这是所有软件人的痛。
简单总结就是，如果对象是物品，由于边界清晰，完全可以外包。所以在工业领域，供应链已经被证明是最有效的生产协作方式，很多手机厂商，把销售和设计以外的所有环节都外包了。如果对象是事情，由于边界模糊，外包的有效性就会大打折扣。
估算难题
还有一个问题是，软件项目的估算永远不准确，根源也和上面提到的边界问题有关。
软件项目每次都在实现不同的目标、完成不同的东西，每次都是陌生的，充满“意外”，所以无法准确估算所需要的时间。
但作为甲方，我们需要乙方提供估算，以便确定外包合同的金额和交付日期。己所不欲勿施于人，如果估算这件事情我们都觉得头疼，怎么能指望乙方估得准。
在这种情况下，无非两个结果：
- 乙方在估算时加入大量的缓冲时间，导致合同金额过高；
- 乙方在合同金额内无法完成约定交付，要么甲方追加投入，要么中止合作，得到一个烂摊子。
验收标准
由于每个项目和需求都是不一样，针对项目和需求的验收标准都必然不一样。针对每个需求，测试和验收所需要花的功夫和难度其实和设计、编程等过程其实是相当的。
需求分析、设计、编程、测试都需要对需求进行深入的理解，都是深度的知识工作，都同等重要，不分贵贱。
当我们把整个软件项目或项目中某些模块或过程（比如测试）整体外包后，如何验收就成了难题。更难的是，为了避免甲乙双方的纠纷，验收标准应该约定在合同中。但也因为刚才提到的因素，在项目开始前对每个需求约定具体的验收条件几乎是不可能的，有这个功夫，半个项目已经完成了。
这也和前面提到的边界问题有关，如果对象是物品，每个物品（比如某个零件）都应该是一样的，其验收条件完全可以标准化，清晰地写入到合同里。知识工作则很难满足这样的条件。
这就导致了项目的验收条件和合同中相应的条款是开放的，而非封闭的。验收标准一旦不能在一开始统一，将来的纠纷和扯皮就不可避免了。
合同模式
目前比较流行的外包合同模式无非就是以下两种：
- 固定金额——双方根据项目估算约定一个金额。甲方不管乙方交付项目的实际成本，只支付合同约定的金额。这种模式 ，相当于乙方承担项目交付的所有风险。
- 时间与材料（Time & Material，T&M）——甲方按照乙方投入人员的工作时间支付费用，不管乙方是否交付预期的成果。这种模式，相当于甲方承担项目交付的所有风险。
我们可以看到，在边界、估算、验收等问题的存在下，不管是哪种合同模式，都有一方明显吃亏。
但其实，不管表面上是哪方吃亏，最终后果其实都是甲方承担。我们在第一部分提到，甲方试图外包项目，无非就是想省钱、省事和转移风险。但大多数情况下，这三个目标都难以实现。
省钱
如果双方签的是固定金额合同，由于边界难以厘清，估算无法准确，乙方肯定需要在其估算基础上加大量的缓冲来降低自身风险，导致合同金额高昂。
如果双方签的是T&M合同，则更容易陷入“只收钱不出工”的窘况。
而且，对于甲方来说，最大的成本在于得不到一个想要的产品。外包过程中，交付团队与甲方的用户缺乏默契、缺乏对业务的深入理解，交付正确产品的几率本身就不高。
省事
表面上，外包团队的所有人事甲方都不需要管。但是著名的管理大师德鲁克总结道，所有的知识工作者都是管理者。要做好软件交付这件事情，需要交付团队每个人都有丰富的知识、技术、软技能（沟通与协调）和经验。
我们期望外包公司有现成的人员配备，但是实际情况往往是，外包公司由于要承担人力成本，在没有项目的时候，会尽早解散人员。所以很少在新项目启动前就组织好所有人员，往往都是在项目启动时才临时到人才市场上聘用，人员素质良莠不齐，培训不到位。
另外，参与项目人员的业务、领域知识往往非常重要，这些知识需要长期在某个具体的业务领域长期浸淫才能累积。我很难想象一个外包团队何以在短期内掌握这些知识。
如果外包团队的人员达不到甲方的这些预期，我看不到甲方如何省事。
转移风险
对于甲方而言，外包的另一个好处是，一旦项目交付出现问题，可以找到一个明确的责任方。然而，我们可以转移责任，却无法转移项目交付问题的后果。一个家居装修搞砸了，承担这个后果的只能是业主，而不是装修队。
还有一种外包形式是购买市场上现成的供应商产品。如果该产品能完全满足公司业务的需要，倒还好。但真实情况是，由于每家公司的具体业务都有差异性，也有自己的合规要求，即使是购买供应商产品，也势必需要供应商进行大量的定制化开发，这就衍生出和项目外包一样的问题了。
03 我的建议如果软件开发项目外包不可行，但甲方确实有省钱、省事和转移风险的需要，怎么办呢？
一个很典型的例子是，公司需要启动一个大型项目，短期需要大量人员。但一旦这个项目结束了，就不再需要这么多人员。所以会存在一个人员数量大幅波动的情况。
这种情况，如果全部靠公司自己组建团队，则在项目启动时需要招聘大量人员，项目结束时又要解雇人员，这为公司带来不必要的管理成本和风险。
公司通过劳务派遣的形式，就可以较好地解决这个问题，也就是说，通过借用外包公司的人员，而不是外包项目。外包人员可以嵌入到公司组建的交付团队中，与公司员工一起在公司内完成项目。
这种形式可以满足甲方省钱、省事和转移风险的需要：
省钱——在国内，甲方引入乙方人员的成本往往比自聘人员的人力成本要低。即使单个人员成本更高，由于是短期操作，相对于短期大量招聘和大量辞退的摩擦成本，也是值得的。
省事——甲方无需投入到乙方人员的招聘、一般性技能培训、绩效等人事工作（但我还是建议甲方管理人员在其他方面对乙方人员一视同仁。同是知识工作者，乙方人员的工作积极性也是项目成败的关键。对乙方人员给予同等的关怀和激励也是对人起码的尊重）。
转移风险——人员嵌入到自己的团队，更能把控，把项目风险降到最低。也能规避人员数量大幅波动对公司带来的名誉和法律风险。
这种形式甲方通常与乙方签署T&M合同来实现——按照派遣的人员数量和时间来结算。
另外，敏捷与DevOps也一直倡导把项目制转换成产品制。传统的交付模式都以项目为单位。而项目往往是一次性的短期行为，而且通常比较复杂，周期长，风险高。为项目组建的团队也是短期的。项目对于系统也缺乏长期投入使之持续改善的意愿。
所谓产品制就是以业务产品为出发点，并为其组建团队和搭建系统，由于产品的生命周期远远大于项目，团队在满足业务需求的同时，也会坚持持续改善，清除技术债，以不断提升交付效率。产品的需求也会被拆成更小的特性，通过持续交付不断实现业务价值，不像项目这样憋一大股劲一次性交付带来的巨大不确定性和风险。
这种情况下，交付模式会从项目预算驱动型转换为人员供应驱动型——业务产品团队的人员规模是相对固定的，不会有很大的波动，在这个限制条件下，业务代表（PO）选择最有价值的需求，实现价值驱动交付。
04 总结很多公司和团队选择把整个软件项目或项目中某些模块或过程整体外包给另一家公司或团队，试图省钱、省事和转移风险。
然而，由于软件项目存在边界模糊、估算不准确、验收无法标准化、缺乏两全其美的合同模式等问题，软件项目外包很难实现省钱、省事和转移风险的目标。
建议的外包形式是外包人而不外包事。从项目制转型到产品制，也是一种很好的方法。
项目负责人必读：软件项目估算永远不准怎么办？
以不变应万变——复杂系统回归测试新思路
为什么每个软件人都要懂点系统架构？
关于作者刘华（Kenneth）
- 就职于世界500强银行，负责基金服务业务软件开发与交付
- 敏捷、精益、DevOps专家
- 公众号“敏于思 捷于行”博主
- 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈
- 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲
- 著有《猎豹行动：硝烟中的敏捷转型之旅》一书
小说体敏捷/DevOps转型教科书和实战经验分享
,
