从 Uber 裁员谈到:造轮子,要还是不要?

430 阅读4分钟

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 的时候不注重细节,连最重要的“审计”功能,比如会计里面的复式记账,都做不好,是他们失败的重要原因。

如果这篇文章对你有帮助,请在 Github 上 Follow 我 :)

本文首发于硅谷io