之前的失业日志系列里有讲，现在的就业环境不太好，有面试机会的基本都是外包岗位。刚好之前公司和外包有几次合作，主要是把一部分或者整个项目外包的外包公司，我们技术人员负责一部分的技术支持，通过几次的合作，对外包的工作也有可一个大概的了解，想谈一下自己对外包的了解和看法，以及最后要不要去外包。

外包主要分两种：项目外包和人力外包。

项目外包
- 企业将项目外包给第三方公司，产品、开发以及最终交付，有的是全部外包出去，有的只外包部分功能，比如有的只是外包开发部门，产品就公司设计。比如某为很多业务都会外包给某软国际和某通动力。
岗位外包
- 企业通过第三方公司，招聘员工，员工在企业内部工作，员工合同属于外包公司，由外包管理。工作节奏和正式员工差不多，工作也相对比较轻松。

岗位外包除了待遇稍微差一点之外，相对来说工作压力比较小，也比较稳定，对这类工作，我本身了解的也不多，本文只讨论项目外包。下面根据项目的规模讲两个比较典型外包对接经历：整项目外包和单个模块外包。

整项目外包

公司想要重构整个电商系统，想要快速一年时间完成重构，当时技术部人数不到 10 个人，所以就准备找比较比较专业的外包公司来重构整个电商系统，整项目外包是包括前提的需求、设计，以及后期的开发、测试。

当时选了三家公司竞标，最后选了一个规模和售前的专业度都更有优势的一家上市公司。他们公司的售前人员对供应链、销售、ERP系统都十分的了解，基本上提问都有对答如流，前期对接也非常顺利。当时定下半年交付核心版，一年交付整个项目的目标，公司想要的效果图：

但是售前对接完了之后，他们就撤销了，就换成了具体的实施人员（产品和技术）。这就有点像买家秀和卖家秀，等卖家展示各种优势条件之后，就换成无论专业和业务差了几个等级的人。开始是我们这边的产品负责人给他们的产品讲解需求，然后一起讨论，出原型。当时整个电商系统是一个 to B 面向企业的应用，用户不像to C 这么多，但是业务比较复杂，项目初期产品遇到几个问题：

售前高预期,实施部门低能力
工期短、业务又复杂

为啥售前和实施具体差这么多呢？是因为外包公司会花很多工资先把行业经验丰富和口才好的售前人员，而且他们也比较稳定，不会随便裁员。

而实施人员就没有那么重要的了，比如产品和技术只要能干活就能进来，给的待遇也比较普通的。所以技术能力比较普通的实施为了完成前面的售前吹得牛，都要各种绞尽脑汁的完成任务。

每个产品负责4,5个板块，公司几年累计下来的业务逻辑需要产品几天内梳理完，产品对于需求理解能力比较慢，复杂的需求给的时间又短，很多都是直接借鉴原来的原型，而且为了快，原型是能省则省，比如某个模块的列表，只画一行的数据。如果理解不够充分的话，后期各个模块之间一旦关联起来后，导致后期各种返工问题。

产品问题多，技术问题同样多，技术开始驻场之后，环境搭建用的他们公司新开发的架构系统，其实就是整合各种 Spring 组件，很多基本问题都没有解决，比如当时使用微服务架构，本地和测试都使用同一个 nacos，导致所有人的服务都注册同一个注册中心上，就会导致几个问题:

服务之间相互调用，比如 A 同学 feign 调用商品服务，就会调到技术B 注册的商品服务，而技术B的商品代码很有可能没有更新，就会调用不成功。
测试环境也可能会调用到本地开发服务，就会出现本来改好的功能，反反复复出现问题。

和产品一样，给技术的工期也很短，只有写业务代码的工期，根本就没时间处理架构问题的时间。没时间解决，只能每次关闭调自己的服务。很影响开发效率。**影响开发效率，没时间改，只能捂着鼻子硬写代码，先把功能实现再说。**实际外包做的效果：

后面实在不行，就想到了一个稍微好一点的办法：修改本地服务名,在服务名后面加一个自己的后缀，比如订单服务 order 改成 order-a。这样服务就不会乱调用了。但是就要主要不要把修改文件名提交上去了，不然又会出现问题。

前提产品和开发一些基本模块，比如商品、用户、客户，这种基础模块开发基本都是 crud 操作，开发难度也不大。等到后期需要各个模块之间关联，以及还要加权限之后，各种问题就来了。

权限和代码规范问题就像是房子的地基，前期就需要把地基打好，后面建造房子才比较稳固。现在的模式是先把房子建好，再考虑地基，结果就是权限改了很多版，在外行看来修改权限和修改业务逻辑一样简单。

产品和开发基本都是天天加班，工作模式比 996 强度还更高，每天都是从早上忙到晚上，同时需要处理各种逻辑，产品没考虑的问题，技术要返工。技术没考虑的问题，产品要返工。suo

即使这么满负荷的工作，也没有完成半年交付核心版本的任务，项目的也延期了好几个月，领导也换了好几波。但是领导解决问题办法就是**加班，死命的加班。**有一次和外包开会，他们领导说了一句经典的名言：

先加他个3天3夜，我就不信做不完，你看附近的xx项目组，凌晨3点还在热火朝天的讨论问题。你当天解决问题，都不用睡觉

其实大部分的领导为了完成任务，也会强调多加班，但是像这么明目张胆的说，我还是第一次听。

延期几个月之后，才勉强上线，上线后用户也反馈系统体验不好。接手开发之后，也是各种限制，比如前端一定要用他们的组件按照一定的规则写代码。

因为当时项目延期比较严重，后期我们也辅助他们负责几个模块的开发，熟悉了之后，发现他们的工作模式就是有项目的时候，天天加班。没有项目的时候，天天休假，领最低工资。他们这种外包还会签项目合同，比如做项目，一天多少钱，没有项目之后，只能领最低工资。

单模块外包

说了整个项目外包后，其实还有很多比较小的单模块开发，比如一个模块的某个功能外包出去，而且还不是全部外包出去，产品和设计不外包，只外包技术部分。这种项目比上面的整项目报价低，项目周期短。这有两个问题：

为了中标，各种压低价格和工期
需求不明确，一直改来改去

当时是做一个订单模块的开发，只是技术外包出去了，开始也是和上面整外包一样，选了几家公司备选，产品先给几家竞争的外包公司讲解需求点。公司为了中标，就把工期和价格压得很低，当时领导就选了一家工期和价格最低的外包。

前期外包面临几个问题：

产品需求不明确，前期讲个大概，原型也比较简单。实际功能比较多，就要靠自己一个一个去问。又不是驻场外包，沟通成本也高。
代码是在原来的基础上修改，而甲方为了代码的安全，只给一部分的代码，无法调试一个完成的环境，有时候本地没问题，测试又有问题。
业务逻辑需要自己了解和甲方技术讲解，这就纯看甲方技术负责态度了，如果态度好，也会讲解和技术支持。如果技术不支持，就很容易卡住在那里。

当时我们作为技术也比较配合，给外包讲解原来的业务逻辑，其他模块需要修改的业务也能及时的更新。但是还是有很多问题。

比如前面说的，产品原型都是一个比较简单的原型很多地方都问题文字说明，最后测试才发现需要修改，反复改动需求的时间比开发功能的时间都多。本地无法调用其他模块的服务的话，只能是造一些假数据。

为什么会有外包

很多公司把一些非核心部分的工作，外包出去。就可以降低公司的运营成本。有需求就有市场，很多外包公司就应运而生。不过他们有一个更好听的名字服务提供商。

外包公司基本是靠接项目挣钱，比如招标一个项目，标价 100 万，中标之后，就开始招员工，给的薪水可能会比普通技术会稍微高一点，这里面也是有很多坑的。员工进去之后，不是签固定工资合同，而是项目合同，项目才能领全额公司，没有项目只能领底薪。

前几年行情好的情况，甲方要求也不多，项目也多。现在行情没有之前好，甲方要求多，预算少。**外包为了中标，会把工期和价格死命的压低。**本来三个月才能做完的，压到两个月。那就只能没日没夜的加班，一周只能放一天的假，这还只基本操作。还有前期各种需求快速讲解，没有一个适应的过程，又要在短时间之内出原型，只能是一个半成品，需求不明确又是改来改去，开发和产品的压力都很大。

作为一个技术开发人员，在压工期的情况下，都没有时间思考技术方案、数据库设计、接口或者方法的可扩展性，怎么快怎么来，有的时候恨不得变量名都是越简单越好。这种情况下很难积累技术能力和行业经验，也就不难理解为啥很多公司不会招聘外包出来的员工。

再回来看之前提的问题，为啥只有外包的岗位特别多，因为外包的工作模式就是**有活干的时候，天天加班。没活干的时候，只有底薪。**假设在深圳领底薪，也就是深圳的最低工资，房租都不够，基本都会自己离职。等有活的时候，再招新的员工干活，做完再等员工自己离职。

利弊分析

优点
- 进入门槛较低，适合职场新人积累项目经验。
- 部分岗位外包工作强度较低，较为稳定。
缺点
- 成长空间有限：外包开发常以快速交付为目标，缺乏对架构设计、技术创新的重视。
- 不稳定性高：外包岗位受项目周期影响大，工作节奏不稳定。
- 职业发展受限：长期外包经历可能导致技术能力与行业经验不足，不利于后续求职竞争力。

万不得已，千万不要去外包

现在行情不太好的情况下，如果一直找不到工作，也可以暂时过度一下，毕竟外包的机会也很多。也有可能有的外包公司还不错。

刚毕业的时候，年轻体力好，可以加班，也熬的动，外包也可以做，但是长时间的加班，没有技术的技术的提高，一旦没有项目就只能换公司，对自己来说也是不划算的。当年龄增加的时候，也要增加自己的技术能力和行业经验，这样即使再换工作的时候，也能找到更好的工作。

总结

外包并非一无是处，但它更多是一个不得已的选择。对于刚毕业的职场新人或短期面临就业压力的人，外包是一个获取项目经验的机会；但从长远来看，应尽快转向更能提升技术能力、积累行业经验的正式岗位，才能在职场中走得更远。

外包公司可能给你一时的工作，但不能给你长久的未来。希望每一位技术人都能为自己找到更适合的职业道路。