连接才是最重要的事儿 —— 技术服务外包的七宗罪

2016-08-22

乔德地

我们是已经有5年的技术外包服务团队；在2016年我们坚持改变，团队经历了分离、重生和再造的过程。我将把我们为什么做出这样一个选择，讲给正在奋斗的兄弟们和以后要加入这场奋斗的兄弟。选择非常很重要，比坚持重要。选择了路，义无反顾的坚持，是一种优良的品质；发现问题，及时更正付出代价也要变化的决心更为珍惜，更为坚强。

耀东

2016年8月 in Beijing

技术外包怎么了

2011年 - 2012年，愉快的两年。接项目，技术团队全力以赴的扑上上去；完成，客户结款。完美的组合，漂亮的验收会，稳定的客户回款。那个时候，和一个朋友再谈另外一个项目，每次和他吃饭我几乎都有合同在包里。新项目很赞，但是我依然很难“全”部状态进行投入。我和客户打交道，2013年逐渐感受到了一些变化；一些不一样。技术外包团队的模式是这样的： 1、找到客户，参与投标 2、投标需求会和上游供应商沟通 3、投标、中标，参与客户深度需求沟通 4、撰写产品需求，按照客户的意图调整部分需求5、开始开发项目（沉默） 5、进行项目测试，交付项目上线测试 6、验收报告会，验收报告签字 7、结款 8、等待服务周期结束，结余款在这整个过程中，团队如无必要是很少其他兄弟公司发生交集的。参与竞标的公司在竞标的环境中是对头；即便是同时中标，实施项目也会相互掐架的。以前，项目合作我们还和外包的兄弟单位有大量协作，和国际巨头也一起探讨业务发展方向。独立成立公司两年以后，我们的耳朵失灵了。在一个温暖和舒适的环境中待下去必然整个团队将一文不值。回过味的时候，我们惊恐万分。如何突破？建立合作关系，不是单纯的和朋友们畅快喝酒，是要有实质的内容进行业务层面的过招和彼此嵌入。第一个想到的就是将我们的开发项目转化为运营项目。2013年下半年开始，我在以各种项目的名义在寻找一些投资就是我们想打破的一个开始。失败是必然的，内部运营转化也不合适，外部的沟通遇到的大量都是阻力。唯一好的一个项目是供应链，即：企业采购类项目。由于有巨大现金流，在遇到合适的投资者后顺利的变现了。

技术外包的七宗罪

技术外包服务有几个怪圈，是整个行业的特性决定的，可以说整个行业的悖论。每个人都在担心A项目结束后的事儿，甲方担心项目无法交付、乙方担心交付后的后续合同没有着落……。各种精彩的戏份伴随着整个技术服务的过程展开，演绎出了七宗罪。 技术浅薄，无法深入 2013年SaaS被大规模投资的时候，我预言过中国没有好的SaaS服务人才，需要至少3—5年的人才培养才会迎来第二个高潮。现在看来整个预言已经是事实了。为什么？就是因为企业服务领域没有足够的牛逼的人才支撑SaaS类企业发展，以往大量的人才在技术服务外包行业，整个行业的技术实力和能力非常低端。一个客户，无论他的企业多么大，超过100万日并发是不可能的。代码的健壮性很显然了。一个刚离开大学的学生写出的代码只要不违反基本的逻辑规则，对付一个企业的业务（含：企业上下游服务业务）非常容易。 1、不需要掌握高级的技术能力就能胜任； 2、不需要高工资就能完成项目。那么，为什么要高工资、高素质人才？客户心态导致整个行业的“产品化”是一个伪命题。基础技术，如：数据库、中间件等，大量的是国外产品；应用层技术，如：工作流，如果国外没有开源产品国内不可能有好的服务商。近两年来，Openstack的火爆就是这样的情况。基本被国外淘汰了，我们无法很快地拥抱新技术，依然在Openstack平台上取暖。客户自然无法信任国内产品，客户依然不愿意付出代价培养国内的优秀服务商（例如：韩国、日本的情况，痴人妄想。）。在To B领域的人力资源外包服务中，Java工程师从没写过JS代码，就干上手写整个项目的前端脚本。曾经遇到过几次，某某甲方的人力资源外包服务商，就是Java工程师写PC端JS脚本，在移动端无法运行，他们的移动页面全部采用我们的。高级技术服务人才大多数都在To C服务领域，阿里的双十一对于技术的依赖和需求是非常强烈的。SaaS需要的技术人才储备不在To B原有的服务商这里，而在To C的企业中。 甲方把握需求，无法理解真是的市场需求 面向甲方，就是面向市场。大大的一个“No”！甲方就是甲方，甲方的需求就是甲方的需求。很多需求是怎么来的，乙方的外包服务商自己都很清楚。面临一个选择的时候，依然很镇定的自己欺骗自己：我们是市场化企业。没有足够的资金支撑一个企业，将客户需求梳理并开发成客户需要的产品；也没有客户配合完成项目的产品化过程。面向市场，在外包服务商这里就是伪命题。 依赖资源获得客户 以“五铁”关系为代表的资源型客户获取，无论中外是毋庸置疑的，然而我们对资源的依赖变成了纯资源依赖。有资源的“公司”获得客户项目，承接给没有资源的技术团队，技术团队再将自己不擅长的部分再次外包。获得客户的资源方会通过各种手段将项目验收；开发企业自己都知道遇到bug或者问题会有人帮助他们摆平。为什么要把项目人力投入100%的给某个项目，一个人多承接几个项目收入会更好。因为A把技术能力外包给B，也是依赖资源。 部分灰色地带 一句话带过吧。 为了获得利益实施方考虑的后续合同签订而不是项目成功或甲方利益 曾经网上流传过一段代码：delay = 10000 。实施方项目经理思考的问题不是产品如何优化，项目实施时间如何合理控制，……，如何获得甲方持续的合同是最关键的问题。林林总总的各类代码，或者形形色色的各种服务支持，都会体现在甲方和乙方的关系中。利益点不同，自然结果不同。 甲方诉求多项目资金少 这个也一句话带过。 独立的项目和孤独的团队 技术外包团队的成员是孤独的。他们在甲方公司，不属于甲方员工，不享受甲方的所有约束，却接受甲方管理。自己的公司负责工资和各类待遇，却无法享受公司本身的团队温度。一个外包项目长则几年，短则一两个月。员工经历的的事儿是无法想象的。这样的团队再聚首到母公司旗下一起办公的时候，我真的不知道他们归属感和凝聚力何在。一个新毕业的大学生，刚来上班的第二天就被安排到某项目上，项目原有的一些规则和暗流必须快速接受，他未来的成长在哪里真的要看“造化”。我们坚持不做人力资源外包这是一个原因。

为了改变我们曾经努力过

作为外包服务商的一份子，我们不可能独清。 不做企业内部信息化项目 我是极其反对OA的。知道的人都熟悉，公司应该没有OA，所有的事情是基于“任务”的，不是基于管理人的；人力资源的管理交给HR的系统。不做企业内部的管理系统，做帮助甲方搞定他的客户或者服务甲方和他的供应商关系的项目。多少让我们拜托了企业内部信息带来的“唯命是从”。 项目需求管理必须面向N各项目 我们一直不做人力资源外包，仅做项目外包让我们拥有了同时进行N个项目，和历史项目可以二次被开发的价值。（二次被开发的价值是整个行业非常难得，1 外包人员的流动性是6个月，30%；2 A项目的技术沉淀B项目根本不知道，即便是有KM或者内部BBS交流。） N个项目，使得我们做技术研讨会有能力抽取共工内容建立自己的代码库和共工组件。五年完成了： 1、工作流平台的自有 2、基于客户员工通讯录的Oauth1.0/2.0统一认证 3、以RBAC为基础的权限管理 4、以Socket模式的企业内部IM（另外一个是基于XMPP协议的） 5、服务于底层系统的高并发服务能力 …… 依赖项目管理机制，建立技术研发团队的周会和双周代码评审，强化内部学习。带来的效果是：员工离职率降低和项目完成率优良率的提升。 备注：关于“为了改变我们曾经努力过”的内容进入交流，发邮件给我吧。corpm@sina.com 当我们全力以赴完成某个外包项目的时候， 我们感受到了孤单。 变化是必须的，怎么变我们为这三个字付出了沉痛的代价。 经过反复试验的结果是以前的模式和逻辑 game over。 要想获得新的机会和发展，必须 重生。 续（近期放送)：《连接才是最重要的事儿 ——依托产品能力开始新的征程》

牛透社特约撰稿人