从 Uber 裁员谈到：造轮子，要还是不要？

Uber 在 2014 至 2018 年间造了不少的轮子，比如服务发现的 Hyperbahn, 任务队列 Cherami, 基于 MySQL 的 NoSQL Schemaless, 资源调度器 Peloton, 服务部署平台 uDeploy 等等。如今 Uber 裁员甚至裁到了工程团队上，股价低于15年的估值，到底造这些轮子是功是过？创业公司应该招人造轮子还是应该拿来主义？

管理是个金字塔，花花轿子人抬人，人是靠人顶上去的，任何管理者的政治素养第一课就是把手下的人招的多多的。招大量的工程师在 VC 投钱的公司来讲也是一个有意思的指标，因为投资者不懂技术，而认为人头数多的公司自然发展的更好。

所以很多人都有为自己多招人的动机，而如何衡量这个动机的正当性呢？这个对于机械性的工作，比如在工厂，是比较简单的，因为产出是直接可衡量的；而脑力工作则不好说，尤其是写代码这种事情。比尔盖茨说，靠代码行数来衡量开发进度，就像是凭重量来衡量飞机制造的进度。我甚至听说，谷歌有专门的组来计算每个组对于公司的贡献程度。

管理者喜欢招人，工程师喜欢造轮子。一方面，创造者天生享受创造的乐趣；另一方面，工程师可能会有要不得的 ego 觉得，如果用别人的技术，岂不是显得我的技术不行。管理者提供“想要什么”，工程师提供“想做什么”，做出来的东西是这两种力量产生的结果。

比如，老牌零售公司请了来自硅谷的新 CTO，新 CTO 招大量 Engineer 做项目，并坚称一旦找到了好的人才，就能够带来有用的项目。他还想要把一些内部软件打包卖服务，尽管这些服务还是跑在一个大型主机上。CTO 还真信这一套。这里的关键问题是，做这些事情到底有没有 ROI （投资回报）？

如果 ROI 没法预先知道，那么如何有效地平衡按需招人和浪费资源呢？答案是注重“打造用于概念验证的原型产品 (POCs)”。用最小的投入来试水，管用就多招人，不管用就不招人。

如果 ROI 能够预先知道，那么答案就是一个简单的算术题。比如 HipChat 每个人每月收 $5, 然后 Uber 有 6 万全职员工和合同工，那么一个月的服务需要花 30 万，而招一个工程师去拿开源的 Mattermost 来魔改的话，每个月只需要付 3 万。那么"自己造轮子"省钱能省到大概是原来的五分之一到十分之一。

也有造了很多轮子，同时又发展得特别好的公司，在其中强力的管理和工程文化起到了很重要的作用，他们推崇简单至上和技术责任感。如果外部现成的轮子功能专一、方案成熟，他们会拿来即用；如果外部现成的轮子什么都做、复杂不可控，他们会自己造轮子。我记得当初 Uber 没有第一时间采用 Cassandra 的一个重大原因就是公司里面没有 Apache Cassandra 的内部人士，技术不可控。

简单至上四字箴言与注重细节并不冲突。比如你可以先选择昂贵笨重的来自微软、SAP 甚至甲骨文的 ERP，然后在跟你业务结合紧密不得不做特殊处理的地方，自己写一些服务，但是要保证服务短小精悍易于维护。而那些新一代的创业公司做 ERP 的时候不注重细节，连最重要的“审计”功能，比如会计里面的复式记账，都做不好，是他们失败的重要原因。