写点什么

程序员一夜暴富捷径?不,别被轻易骗进“独角兽”

  • 2020-08-27
  • 本文字数:7632 字

    阅读完需:约 25 分钟

程序员一夜暴富捷径?不,别被轻易骗进“独角兽”

本文最初发表于 Pragmatic Engineer 博客,经原作者 Gergely Orosz 授权,InfoQ 中文站翻译并分享。


“独角兽”企业没你想象的那么好。


作为一个程序员,是进入独角兽企业好呢,还是进入初创公司好呢?这确实是一个问题。


在我们的想象中,独角兽的成功总是因为创始人有着不一样的愿景,创新产品做过数据验证才会取得成功,独角兽企业有着非常好的流程化开发过程,独角兽的早期员工都非常了不起且容易暴富…


然而在数家知名独角兽企业工作过的 Gergely 说,这些都是“幻觉”。


独角兽的成功往往不是因为创始人而是运气足够好;独角兽产品主要凭直觉,要么成功要么失败;独角兽的开发流程多数不值得谈论,而且经常背负庞大的架构和技术债务;独角兽早期员工可能一直都很贫穷,最后的股权可能只值一个月的薪水…


Gergely 以他在 Skype、Skyscanner、Uber 等几家企业的多年经历,总结了十个大家以为的“独角兽幻觉”:现实和最初的高期望并不总是一致的。

不要轻信媒体信息

Skype,尤其是 Uber,在我加入前后,都有夸张的媒体报道。在我进入这些公司工作之前,我会对许多传闻信以为真。Skype 的增长似乎势不可挡:2011 年月度用户数就超过了 1 亿。或者说 Uber在 2017 年的表现如何糟糕透顶,如果看了这些文章,我会认为 Uber 是一家没有人愿意去的公司。


当你进入一家公司工作时,你就会意识到媒体和文章有多挑剔。我敢肯定,你没有读过任何关于 2013 年 Skype 用户数量惊人放缓的文章,也没有读过与 Whatsapp 在 2013~2014 年迅猛增长进行比较的文章。在大多数公司全体员工中,这是一个热门话题,然而,却没有任何一家媒体对此进行过报道。只有知情人注意到的一件事是,一段时间后,在 Skype 新闻稿中就不再报道用户数量了。


媒体通常都会写一些标题党的内容。耸人听闻的标题指向比实际发生的事情更刺激的东西,往往会带来更多的流量。令人震惊的消息——那种“天啊!你需要看这个”的这样的新闻类型效果更好。Skype 远没有那么令人惊叹,但 Uber 也没有你从主流媒体文章或 Hacker News 头版上看到的报道那么糟糕。如果你正在考虑加入知名的科技公司,请做一下调查并形成你自己的观点。你会做得比仅仅依靠媒体和论坛道听途说要好得多,因为在那里,那些耸人听闻的猜测比平凡的细节报道效果要好。

崩溃比想象的多

所有这些公司都是非常成功的公司,每月都有数千万甚至上亿的客户。所有这些公司都声称自己处于创新的最前沿,只雇佣最优秀的人才。然而,当我加入时,我惊讶地发现,在估值数十亿美元的公司里,有一堆崩溃或被忽视的问题,这是我未曾预料的


在我加入 Skype 时,主要的 Skype 客户端(当时约有 2 亿人使用)甚至没有进行过单元测试。那时 TDD 和测试已经成为主流。尽管如此,那个版本还是依赖于数十名手工测试人员来完成数千个测试用例。你提交代码后,在两到三个星期内,你将会得到一个 ping,指出它可能引入一个 Bug。甚至光是发布就要花了几个月时间,客户端就在 Delphi 中编写和维护的,团队曾多次尝试将其移植到一些不那么小众的语言上,但都没有取得成功。


需要说明的是,在快速增长和年轻的公司中,有类似上述痛点是很正常的。让我感到震惊的是,在面试中,我被灌输了(并且也愿意相信)一个运营良好的公司的形象。我还看到几个来自 Google 的工程师在第一个月就辞去了这样的独角兽公司的工作,因为他们意识到,他们被灌输的是在一家“小型 Google”公司工作的印象,但实际情况并非如此:这些公司只不过是小型的、但要杂乱得多的版本,与 Google 相去甚远。

成功很大程度靠运气

你一定看过那些文章,大谈特谈这些成功的独角兽企业都是怎么创立的,似乎创始人都有着惊人的愿景,才会有这样的结果。Garrett Camp 是如何无法可靠地打到出租车的,所以,他创立了 Uber 来解决这一问题。Gareth Williams 是如何找不到最便宜的旅游特惠产品,因此他创立了 Skyscanner


你甚至不需要在这些公司工作,就可以质疑该公司在起步之初到底有多幸运。每个独角兽企业都有几个竞争对手,它们有着相同的想法,执行方式也相似。对于 Uber 来说,有更早推出的竞争对手 Sidecar,吸引了很多投资者,令人惊叹。对于 Skyscanner 来说,竞争就要激烈得多,但它们还是赢得了欧洲市场,并在美国和亚洲也产生了重大影响。


在公司工作时,你会开始听到很多故事,讲述运气是成功的重要因素。时机、早期事件、那些在当时看来微不足道,但却被证明是有价值的随机决定。对 Skype 来说,P2P 的特性使它可以在 21 世纪头十年迅速扩张,而彼时服务器的运行成本仍然很高,但宽带开始越来越普遍了。对于 Skyscanner 来说,持久性和即时性都是非同寻常的。它们刚起步的时候就有几个竞争对手,在抓取航班优惠信息方面并没有真正赚到钱。尽管如此,Skyscanner 还是坚持了下来,在网站积极尝试屏蔽它们的情况下,仍然像玩“打地鼠”的游戏一样,进行抓取数据。它们年复一年地这样做,直到它们规模变得太大,以至于它们抓取的数据和引导流量的网站都无法忽视并开始为它们获得的流量付费。它们早期的竞争对手在半途中就倒闭了,后来的竞争对手干脆直接从 Skyscanner 购买数据,而不是花自己的钱进行数据抓取。


更有趣的是,与我交谈过的早期员工也经常告诉我,他们也没想到公司会发展这么快,或者市场对他们正在构建的东西有这么大的需求。执行力当然很重要,缺乏执行力可能会扼杀一家公司。但是,在需求增长的时候,在正确的时间里做正确的事情,这纯粹是运气使然:这是我工作过的所有独角兽企业都共有的东西。

产品是凭直觉判断的

当你推出一项成功的产品功能,并成为公司的核心部分时,很多人都认为公司一定知道它会成功。而人们认为我们至少之前做过一些用户测试。


但事实并非如此。通常会有人(通常是产品经理)提出开发某个功能的建议。如果是在公司的早期阶段,他们会将想法告诉工程师,然后工程师就实现想法并交付。如果是在公司的后期阶段,他们会写一份文档并获得批准。当你真正想交付的时候,数据是必要的,但获得正确的预测类型并不是什么大不了的事情。


虽然你可能认为,凭过多的直觉而使用很少的数据是一个糟糕的策略,但我看到了相反的情况。Skype 是我们在一个项目进行用户研究测试最多的地方。你猜怎么着?我们做出了最糟糕的决定:或者我应该说,我们几乎没有做任何决定。我们进行了为期两天的用户研究测试,有 14 个人参加,结果通常是 8:6(表示赞成/反对我们的建议)。所以我又进行了两次这样的测试,结果还是平局,产品经理决定我们将构建两个版本,然后进行 A/B 测试。当 A/B 测试结果接近平局时,我们选择了产品经理认为从一开始就会做得更好的那个版本。


相比之下,Uber 的一个团队在早期根据一些客户讨论推出了一个产品,但除了直觉之外,并没有真正好的预测,要么大受欢迎要么惨败。他们以超快的速度打造了一款基本的产品,并进行发布,然后开始看到了曲棍球棒式增长……这就是用现金支付 Uber 和 Uber Eats(尽管有点复杂)的由来。今天,这两个业务的营业额都达到了数十亿美元。

流程远没想象中的重要

2011 年,Skype 进行瀑布式开发。这是一个进行更改,并长时间的手动测试,然后发布的过程。他们是市场的领导者,如果你进行视频通话,那就是 Skype。从 2012 年开始,Skype 进行了敏捷转型,所有团队都接受了 Scrum 培训,我们获得了证书和设置,可以每两周进行 Sprint,并以更迭代的方式发布价值。到 2014 年,我们比以往任何时候都更加敏捷。然而,我们的市场份额却下降了,像 Whatsapp 这样的竞争对手在 Skype 上大赚了一笔。到了 2020 年,Skype 拥有比以往任何时候都更好的流程和敏捷性,那么现在你必用的视频通话应用是什么呢?很遗憾的是,我已经很长一段时间没用 Skype 了。


你阅读博客,参加会议,听取工程主管谈论流程的重要性,以及他们如何是如何进行流程更改,导致这样或那样的结果。Spotify 模式。敏捷。Scrum。kanban。Scrumban。这是很少有人会告诉你的,但是我所看到的是:对流程的关注有些过头了专注清晰透明和健康的文化更为重要:但要做到正确,比改变整个公司的流程难得多。它们也没有多少性感可言,不值得谈论或书写,因为它们都不那么令人兴奋。


Skype 在被 Microsoft 收购后,焦点很快就消失了。就算我们拥有一个崭新的、闪亮的敏捷流程,还拥有数百名经过认证的 Scrum 专家,但这都无关紧要了。公司的大部分人都停滞不前,没有一个明确的目标让我们去追求。我们是否针对 NPS 进行了优化?挑战 Whatsapp?增加每月用户数量?收入不断增长?有关公司愿景的说明被打印出来,贴在自助餐厅和厕所里,但是,连续两页的文字,并没有回答任何这些问题。


对比一下 Skyscanner。办公室里有一块屏幕,实时显示了当天赚了多少佣金,我们每天都能收到收入明细的电子邮件。当我加入这家公司后,我简直不敢相信透明度如此之高。难怪 Skyscanner 多年来是极少数盈利的独角兽企业之一,每个人都知晓自己团队的贡献有多大,这难道不是一个奇迹吗?或者是黑客松(Hackathons)提升了这个度量标准?Uber 也一样。Uber 在各个团队之间没有共享流程,但有清晰的目标和衡量标准,并且内部透明度也极高。执行是高度专注的。几年来,重点一直放在增长和活跃的客户上。另一些则是合作伙伴的满意度或安全感。我们一直都知道我们要去哪里,以及为什么要去。

快速增长也得给团队更多自主权

独角兽企业之所以能够快速地增长,是因为它们引入了大量风投资金来加快招聘和执行速度,而这种更快的执行速度会带来丰厚的回报。快速增长的现实是,如果不赋予团队和个人高度的自主权,就无法做到这一点。这就是为什么你会发现很少有什么地方能比处于高增长阶段的独角兽企业拥有更多的自由度


在 Uber,我们的办公室数量连续三年每年翻一番。这意味着,当我加入 Uber 阿姆斯特丹办公室时,对 20 名开发人员有效的流程,在开发人员达到 50 名就失效了。无论我们为 50 人想出什么办法,到 150 人也会失效。而这一切都要靠我们这些基层的人来做出改变,以保持工作效率。


Uber 的高速增长是一个极端的例子,但在我工作过的所有独角兽企业里,高速增长和自主权都是相辅相成的。自主权不仅仅是一种选择:它是公司增长的必要条件。作为所有者,积极主动地解决问题,并不仅仅是一件好事:这是在这样的地方取得成功的必经之路。自主权和所有权并不局限于软件开发。它意味着要面临做出产品决策、投入到正确的客户支持中,以及走出工程师舒适区的其他方式的挑战。正是这种接触帮助许多在这些公司工作的开发人员成为具有产品意识的软件工程师的原因。


我在独角兽企业工作室发现,在它们的成长阶段,自主权和高速专业发展是最有价值的

不搞砸甚至比创新更重要

在我加入的时候,所有这些独角兽企业成立都还没到十年。在大多数情况下,它们做得非常好,能带来客户和收入。对于 Skype 来说,它可以可靠地呼叫其他人;对于 Skyscanner 而言,能够查找最便宜的航班;而对于 Uber,可以在 5 分钟或更短的时间内打到车。


此外,所有公司都在创新和建立新的业务线上投入了大量资金。Skyscanner 推出了酒店和汽车租赁业务。Uber 推出了 Uber Eats、Uber Freight 和其他数十家公司。但是,一直成功的独角兽企业一直高度专注于确保它们的“核心”产品持续增长,让人们使用它,喜欢它,并为它付费。Skyscanner 对航班的覆盖范围和收入非常看重。Uber 关注的是出行率和司机满意度,并据此做出决策。当指标或市场份额开始下降时,它们就会迅速做出反应,扭转这一趋势。


不过,在 Skype 这个地方,我见证了我们专注于核心增值的地方,以及如果我们失去竞争优势后会发生什么。当时,Skype 已经拥有大量的客户,我正在为 XBox One 开发 Skype,我们买下了群呼通话的 GroupMe,并启动了一个名为Qik的新应用。当所有的讨论和焦点都集中在“新”——新平台、GroupMe 和 Qik 上的时候,我们似乎忘记了倾听用户的意见。用户对他们在 Skype 上的短信需要几分钟或几个小时才能送达感到不满。这是因为消息传递使用了 P2P 协议,而这种协议在延迟方面根本无法与其他大多数纯聊天应用所使用的集中式模式竞争。


在季度全员大会上,员工们经常问到的问题是,“我们对 Whatsapp 获得巨大人气有什么应对措施?”但领导层并没有给出我们希望听到的明确答案。相反,他们是这种“别担心,他们和我们不是一个档次”的不屑态度。Skype 的领导层一直强调,即时通讯应用不是我们的竞争对手,因为它们不提供视频通话,因此,在将人们联系起来的方面上,它们并不能达到我们所能达到的水平。我们忘记了无缝的、一流的通信才是 Skype 的核心价值所在。尽管我们关注了很多事情,但提高消息传递的非视频部分的可靠性并不在其中。我们花了好几年的时间才让消息传递变得可靠,而且还是基于服务器的,但那时已经为时已晚:Skype 给人们留下了这样的印象:Skype 只能用于视频,不能用于收发文本。尽管 Skype 不断创新,从新功能,新应用,再到后来的大规模重新设计,但 Skype 最终还是失去了市场份额,从一个市场领头羊变成了众多视频通话解决方案之一。

CTO 比你想象的更重要

我见过的每一家创立 5~10 年的独角兽企业都背负着数额惊人的技术债务。这些技术债务大部分是可以理解的。这些公司一开始就是一个想法,很快就得到了验证。最小化可行产品的表现远远超出了预期。公司扩张速度也超过了任何人的预期。产品的 V1 还在原型上运行。对于 V2,几乎没有时间来解决架构之类的问题。现在,5~8 年后,有了数以百万计的付费用户和成百上千的开发者,快速前进仍然是必不可少的。但是,如何偿还工程技术长期以来背负的庞大架构和技术债务呢?


我已经目睹强大的 CTO 对于灌输健康的工程文化至关重要,这种文化能够让组织在采取务实的方法来解决技术债务的同时持续交付。此外,缺乏这样的 CTO 在早期的后果是显而易见的。那些只有临时的或不干涉的 CTO 的地方,这些地方的工程输出和质量看起来都非常“应付”。虽然有些团队表现不错,但许多其他团队无法解决堆积如山的债务,他们甚至花了很长时间才能做出哪怕是很微小的更改。


在 Uber,我就体验到了一个稳定的、亲力亲为的 CTO 所能带来的巨大变化。Uber 在更短的时间内实现了更快的增长,比我之前工作过的任何一家公司都要快。在加入时,我看到庞大的开发工具团队正在改进开发人员的工作流程,让我很是惊讶。我们对开发人员、随叫随到的工具以及单体应用上都进行了前期投资。关于技术债务的讨论不仅发生在工程师之间,也会发生在 CTO 级别。我们开始了自上而下的支持计划,如Fixit Weeks:所有的工程师(数以千计的开发人员)只从事技术债务消除工作的一个星期。工程技术能够实现投资,这在其他公司从未见过:我相信,这很大程度上要归功于 CTO,他与其他业务部门建立了牢固的信任和信誉。


我看到了与此类似的转变,Bryan是我认识的实践经验最丰富的工程主管之一,他加入 Skyscanner 担任高级工程副总裁,很快就成了 CTO。在短短的两年时间里,Bryan 在建立自主的工程团队文化方面做出了显著的贡献。Bryan 是我所知道的最具实际操作能力的高管之一,他了解最新的技术,并深入探讨架构问题,这既富有挑战性,又能赋予工程师和工程经理权力。他很快就在工程师中建立了信任:利用这种信任在引入全公司开发最佳实践方面做出改变,从而以更快、更高质量地进行迭代。

并非所有老员工都会随公司一起成长

与我共事过的一些最优秀、最鼓舞人心的同事都是公司的早期员工。但并非所有早期员工都同样出色。在每家公司,都有一些你最好能避开的人。这些人有两种类型。


有些人只是停止了与公司一起成长。典型的早期员工,会从工程师发展到高级工程师再到技术主管,但后来才发现他们是不怎么优秀的主管。他们停止了成长,很明显,他们对现状并不满意,而其他早期员工的进步更快。这些人知道如何独立完成任务,但不喜欢与他人在同一个团队中工作。


另一种类型的人,给我留下了深刻的印象:等期休假(rest and vest)。(译注:硅谷有一个公开的秘密:有一群身价百万的工程师,每天上班的内容就是休息,光拿高薪不干活。)在我加入时,有几家独角兽企业还没有发生流动性事件(译注:即期权兑现),这意味着,如果早期员工离开,他们将不得不拿出大笔资金行使期权,但仍无法从中获利。因此,有那么几个人(他们有很多期权)就呆在那里,等待第一次期权兑现。期权兑现后,他们通常很快就会离开。


早期员工之间的差异非常显著,因为他们都是真正有才华的人。我有幸与 Skype 的一些创始工程师和 Uber 的 1 号移动工程师共事,他们的工作效率都非常高。但是,当你加入一家独角兽企业时,不要想当然地认为每个早期员工都很了不起:搞清楚谁了不起,你很快就会发现有些员工可能不怎么样。

早期员工暴富的并不多

我一直认为,作为独角兽企业的第一批员工(前 10~20 名员工),一定意味着当公司估值达到独角兽级别时,这些人肯定能够成为百万富翁。虽然这对一些公司来说可能是真的,大多都是那些早期对股权慷慨的公司,但这不是我见过的普遍情况。


在一些案例中,那些几年后才加入,但谈判能力更好的人比在那里已工作多年的早期员工的薪水要高,换言之,他们处于同一级别。这一点在 Skype 尤其令人瞠目结舌,它的运营方式似乎与大多数独角兽企业截然不同。据我所知,eBay 的收购并没有让许多早期的 Skype 工程师变得富有,而随后的私募股权收购也没有给那些老工程师带来什么激励。我认识一名资深工程师,他七年前的 Skype 股权在几次 Skype 收购(eBay、Silverlake、Microsoft)后,只相当于一个月的薪水。


当然,我也认识一些早期员工,他们确实做得很好,这要归功于他们对时机的把握和他们对公司持续的贡献。但这并不是一个普遍的规则。如果你很早就加入初创公司,希望能因此发大财,那你恐怕要失望了

写在最后

为这些被数百万人使用的知名品牌工作,也会为我带来一些意想不到的“名声”。如果是在像 Hacker News 这样的公共论坛上,我提到我所在的公司,就会收到一大堆关于我们是如何实现这个或那个的问题。在做技术演讲或写博客时,品牌联想也会起到意想不到的积极作用。我敢肯定,如果我没有“Skype/Skyscanner/Uber 开发人员”的头街,那么我的演讲被会议和技术会议接受的几率就会更小。谈到这些公司的技术选择和最佳实践时,大家都非常感兴趣。


虽然品牌联想通常带来的是积极的影响,但也有不利的一面。下面是一条我认为无关紧要的推文,这推文提到了我的团队是如何在 Uber 从微服务转向宏服务,结果,在 Twitter 火起来了。



很多人都将这条推文解读为 Uber 放弃了微服务,但很少有媒体注意到我的后续回复,并按照我的意图来解读这条推文。《高可扩展性》(High Scalability)和他们的文章《Uber 一团队正从微服务转向宏服务》(One Team at Uber is Moving to Macroservices)就是对这条推文线索的一个很好的总结。


作者介绍:


Gergely Orosz,拥有实践经验的工程经理,拥有十年开发经验。目前在 Uber 工作。


原文链接:


https://blog.pragmaticengineer.com/surprising-things-about-working-at-tech-unicorns/


2020-08-27 11:161801

评论 2 条评论

发布
用户头像
不知道是原文逻辑跳的太快,还是翻译质量不好,看得很费劲。
2020-08-27 13:00
回复
再看了看,确实有种机翻的味道。。。
2020-08-27 13:00
回复
没有更多了
发现更多内容

食堂就餐卡系统设计

Aldaron

架构学习之架构图设计(1)

Paula_l

食堂就餐卡系统设计

桔子

第一周学习总结

Gavin

脑子不够怎么学架构

紫极

闲谈 极客大学架构师训练营

食堂就餐卡系统设计

食堂就餐卡系统设计

Ph0rse

极客大学架构师训练营

架构学习

呱呱

极客大学架构师训练营 作业

食堂就餐卡系统设计

atlasman

第一周作业二:学习总结

iHai

极客大学架构师训练营

架构homework1

蜡笔小晗

如何编写一份合格的架构设计文档(一)

izerone

架构师第一周学习小结

K先生

就餐卡系统架构文档

Geek_bobo

架构师第一课学习总结

曾祥斌

架构师训练营 第1周作业

Lingjun

极客大学架构师训练营

架构师训练营-作业一

Jemmy

【Week01】架构师如何做架构

Aldaron

食堂就餐卡系统设计

谭焜鹏

食堂就餐卡系统设计

豌豆爸比

【极客大学】【架构师训练营】【第一周】学习总结:如何使用UML图达成设计意念

NieXY

极客大学架构师训练营

就餐卡系统设计

dongge

食堂就餐卡系统架构设计⽂档

一点点..

【极客大学】【架构师训练营】【第一周】 食堂就餐卡系统设计

NieXY

极客大学 极客大学架构师训练营

架构师训练营(第1周作业)

李德政

极客大学架构师训练营

架构师赋能

will

架构师

架构师训练营第一周作业

fenix

架构师课程第一周总结

dongge

食堂就餐卡系统设计

周冬辉

架构师训练营week1-学习记录

lijia_toby

极客大学架构师训练营

第一周架构训练营(就餐卡系统)

Gavin

程序员一夜暴富捷径?不,别被轻易骗进“独角兽”_文化 & 方法_Gergely Orosz_InfoQ精选文章