行业动态

作者出版社

我们是一支成立5年的技术外包服务团队； 2016年，我们坚持变革，团队经历了分离、重生、重构的过程。

我会告诉正在战斗的弟兄们和以后加入这场斗争的弟兄们，为什么我们会做出这样的选择。

选择很重要，比坚持更重要。 选择道路，义无反顾地坚持，是一种优秀的品质； 发现问题，及时改正，付出代价改变的决心更加珍惜，更加坚定。

耀东

2016 年 8 月

技术外包怎么样

2011-2012，快乐五年。

接到项目后，技术团队全力以赴跳起来； 完成后，客户结清了付款。

完美的结合，漂亮的初检会，稳定的客户贷款。

当时我在和一个同学谈另外一个项目，每次和他喝水的时候，我的包里都差点有个协议。 新项目很棒，但我仍然很难全心投入。

和客户打交道，2013年逐渐感受到一些变化； 有些不同。

技术外包团队模型如下：

1、寻找客户并参与投标

2.招标要求将与上游供应商沟通

3、投标中标，参与与客户的深度交流

4.写产品需求，根据客户意向调整部分需求 5.开始开发项目（沉默）

5、开展项目测试，交付项目上线测试

6、验收报告会，初检报告签字

七、付款

8.等待服务期结束，尾款支付

整个过程中，团队如非必要，很少与其他兄弟公司有交集。 参与投标的企业是投标环境中的竞争对手； 即使他们同时中标，他们也会在项目实施过程中相互厮杀。

过去我们在项目合作上也和外包兄弟有过很多合作，也和国际大鳄说明了业务发展方向。

独立组建公司五年后，我们的眼光失败了。 待在温馨舒适的环境中，难免会让整个团队变得一文不值。

回头一看，我们都惊呆了。

如何突破？

建立合作关系不是简单的和同学小酌一杯，而是要有业务层面的竞争和相互嵌入的实质内容。

首先想到的是将我们的开发项目转化为运营项目。 从2013年下半年开始，我就以各种项目的名义在找一些投资，这是我们要打破什么的开始。 失败在所难免，内部运营转型不合适，外部沟通很多都是阻力。

唯一好的项目是供应链，即：企业采购项目。 由于现金流量巨大，在遇到合适的投资者后成功变现。

技术外包的七大罪过

技术外包服务有几个难点，这是由整个行业的特点决定的。 可以说是整个行业的悖论。 大家都害怕甲方项目结束后会发生什么，乙方害怕项目交付不了，乙方又害怕交付后的后续协议没有希望……

各种精彩的场景伴随着整个技术服务流程展开，诠释着七大罪。

技术狭窄，难以深入

2013年SaaS大​​规模投入的时候，我预测国内没有好的SaaS服务人才，至少需要3-5年的人才培养才能迎来第二次高潮。

现在看来，整个预言早就应验了。

为什么？ 就是因为在企业服务领域还没有足够的优秀人才来支撑SaaS企业的发展。 前些年，大量人才聚集在技术服务外包行业，整个行业的技术实力和能力都非常高端。

一个客户，不管他的企业有多大，都不可能超过100万个并发会话。 代码的健壮性是非常真实的。 一个刚大学毕业的中学生写的代码只要不违反基本的逻辑规则，处理一个企业的业务（包括：企业的上下游服务业务）是非常容易的。

1. 不需要掌握中级技术能力即可胜任；

2. 完成项目不需要高薪。

那么，我们为什么需要高薪、高素质的人才呢？

客户态度导致整个行业“产品化”是一个伪命题。 基础技术，如数据库、中间件等，多为美国产品； 应用层技术，比如工作流，如果美国没有开源产品，国外就不可能有好的服务商。

五年来，中国的火热就是如此。 基本被美国淘汰，我们不能快速拥抱新技术，还在平台上升温。 客户自然很难信任国外的产品，客户也不愿意为培养优秀的国外服务商付出代价（比如：日本，日本的情况，妄想。）。

在ToB领域的人力资源外包服务中，Java工程师从来没有写过JS代码，而是手写了整个项目的后台脚本。

之前遇到过几次，一个甲乙方的人力资源外包服务商，Java工程师写PC端的JS脚本，在联通端很难跑，他们的联通页面都是用我们的。

中级技术服务人才大多在ToC服务领域。 阿里的双十二对技术有着极其强烈的依赖和需求。 SaaS所需要的技术人才储备不在ToB原来的服务商，而是在ToC的企业。

乙方把握需求，但难以了解真正的市场需求

面向乙方就是面向市场。 一个大大的“不”！

乙方就是乙方，乙方的需要就是乙方的需要。 甲方的外包服务商很清楚有多少需求来自哪里。

面临选择时，他依然冷静，误导了自己：我们是市场化企业。

没有足够的资金支持企业梳理客户需求，并将其开发成客户需要的产品； 并且没有客户配合完成项目的产品化过程。 面向市场对于外包服务商来说是一个伪命题。

依托资源获取客户

以“五铁”关系为代表的资源型获客在国内外都是毋庸置疑的，但我们对资源的依赖已经变成了纯粹的资源依赖。

有资源的“公司”拿到客户项目，交给没有资源的技术团队，技术团队再把自己不擅长的部分外包出去。

获得客户的资源方会先通过各种方式对项目进行测试； 开发公司自己都知道，遇到bug或问题，会有人帮他们改掉。 为什么要在某个项目上投入100%的项目人力，一个人承担更多的项目会更好。

由于 A 将技术能力外包给 B，因此它也依赖于资源。

部分黑色区域

一言以蔽之。

实施方为获取利益而非项目成功或乙方利益考虑的后续协议

之前网上贴了一段代码：delay=10000。

实施方项目负责人考虑的问题不是如何优化产品，如何合理控制项目实施时间，……，如何获得乙方的持续同意才是最关键的问题。

各种代码pc运维外包，或者说各种服务支持，都会在乙方与甲方的关系中体现出来。

好处不同，自然结果也不同。

乙方呼吁多项目少资金

一句话也提到了这一点。

独立项目和孤独的团队

技术外包团队的成员都是孤独的。

他们在乙方公司pc运维外包，他们不是乙方的员工，不享受乙方的一切约束，而是接受乙方的管理。 我自己的公司负责工资和各种福利，但享受不到公司本身的团队温度。

一个外包项目长则数年，短则一两个月。 员工们的遭遇是难以想象的。 当这样的团队聚在一起在母公司下一起工作时，真不知道他们的归属感和凝聚力在哪里。

一个刚毕业的大学生，下班第二天就被分配到某个项目。 必须迅速接受项目的一些原始规则和暗流。 他未来的成长，还真是要靠“造化”。

我们坚持不做人力资源外包，这是一种激励。

我们努力改变

作为外包服务商的一份子，我们不能孤军奋战。

不做企业内部信息化项目

我非常反对OA。 知道的人都知道，公司不应该有OA，所有的事情都是基于“任务”，而不是管理者； 人力资源管理交给HR系统。

不做企业内部管理系统，做帮助乙方获得客户或服务于乙方与供应商关系的项目。

或多或少让我们乞求企业内部信息带来的“服从”。

项目需求管理必须面向N个项目

我们从不做人力资源外包，只做项目外包，让我们有同时开展N个项目的价值，历史项目可以重新开发。 （二次开发的价值在整个行业是非常难得的。1.外包人员的流动性是6个月，30%；2A项目的技术沉淀B项目根本不知道，即使有KM或者内部BBS交流。 )

N 个项目促使我们做技术研讨会，并有能力提取协同工作内容以改进我们自己的代码库和协同工作组件。

两年完成：

1、自有工作流平台

2. .0/2.0 基于客户和员工通讯录的统一认证

3、基于RBAC的权限管理

4、基于模式的企业内部IM（另一种是基于XMPP合约）

5.服务于底层系统的高并发服务能力

...

依托项目管理机制，建立技术开发团队周会和双周代码评审，加强内部学习。 带来的疗效是：员工离职率提高，工程完工优良率提高。

备注：请将“我们努力改变”的内容发短信给我。

当我们正在为完成一个外包项目而苦苦挣扎时，

我们感到孤独。

改变是必要的，如何改变这三个字我们付出了沉重的代价。

试错的结果是曾经的模式和逻辑

游戏结束。

为了获得新的机遇和发展，我们必须

重生。

续（近期播出）：《连接最重要——依靠产品能力开启新征程》

牛社特约撰稿人

其实你可以看到...

点击图片或标题阅读