业绩大幅下滑，谷歌如何提高员工的生产力？
神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：谷歌是开放文化的创立者，这家科技巨头从一开始就为员工营造了非常宽松的工作氛围。但是，最近公司 CEO 居然公开宣称要提高员工的生产力了。这似乎是破天荒的一件事。随着最新堪称“血崩”的财报出炉，谷歌的员工效率是不是降低了？如何才能更好地衡量员工的生产力？本文来出个主意。文章来自编译。
在最近一次全体会议上，谷歌首席执行官 Sundar Pichai 宣布将推出 Simplicity Sprint 计划。
这项计划的目的是要应对一项挑战：提高员工效率。
员工需要提高效率应该不足为奇。不过，谷歌会公开宣布需要提高员工的生产力倒是很多人想不到的。
以下是 Sunder Pichai 演讲的原话：
真正令人担忧的是，我们整体的生产力并没有达到这样的人数规模所需要的水平。大家得帮助我创造一种更专注于使命、更专注于我们的产品、更加以客户为中心的文化。我们应该考虑如何最大限度地减少干扰，真正提高产品卓越与生产效率的门槛。”
谷歌要提高效率的直接原因：
谷歌要提高效能的驱动力来自其季报，谷歌的最新季报（Pichai 演讲之前）显示收入增长率为 13%。如果你不知道这个数字意味着什么，只需知道去年同一季度这个数字是惊人的 62%。
市场菜鸟可能会提出异议，称去年的数字之所以那么高，是因为后疫情时代的重新开放以及消费者支出增加推动的。但投资者不会被这样的看法动摇。钱不是天上掉下来的，像谷歌这么有前途的公司也受不了数字掉得这么厉害。
谷歌最新季报收入增长率为 13%，而去年同期为 62%。
不过，谷歌几乎算不上孤例。在最近讨论到 2025 年程序员的未来的那篇文章里，我警告了经济衰退对 FAAMG （Facebook、亚马逊、苹果、微软、谷歌）劳动力的影响。在撰写本文时，Facebook 已经冻结了招聘，微软已经发布了为忠诚员工而不是新员工提供福利包的一揽子计划。
在同一篇文章中，我曾预测谷歌的日子也不会好过。在线广告，尤其是谷歌和 Facebook 那种靠用户数据来卖广告的方式，已经过了鼎盛时期。
后疫情时代经济不见复苏，加上全球地缘政治的高度不确定，可能会让 FAAMG 以及第二梯队的 IT 公司成为第一批倒下的多米诺骨牌之一。
谷歌很少讨论效率问题：
据我所知，至少很少公开讨论。
FAAMG 俱乐部当中，亚马逊是个异类。这家公司将员工视为机器，做软件的员工也包括在内。其结果是，公司的人员流失率往往很高，而且在业界名声不好。正因为如此，它很少会因员工生产力下降而牺牲利润。
但谷歌不是亚马逊。事实上，在对待员工方面，它处在光谱的另一头。
谷歌是现代开放文化的创始人。
在拉里·佩奇与谢尔盖·布林联袂主政的时代，谷歌是当今 IT 行业所享有的开放文化的创立之父。在硅谷，谷歌内部极度的民主与透明被认为近乎无政府的状态。下面的决策很少会受到高层管理人员的猛烈抨击。调查和内部民意调查确保了每个人都知晓公司的发展方向，每个人都能被倾听，至少在投票方面是这样的。
谷歌的 20% 项目福利（员工每周可以留出 20% 的时间用于开发自己的项目）路人皆知，被称为其创新配方的公开秘密成分。
自从 2019 年拉里·佩奇与谢尔盖·布林先后淡出 Alphabet （谷歌母公司）高层后，这是谷歌第一次面临盈利挑战。除了最极端的谷歌内部人士之外，没有人能回答这些问题：
谷歌的投资者会强迫公司管理层采用类似亚马逊的文化，像驯兽师对待动物一样去衡量开发者的表现吗？ 如果是的话，谷歌会顺从吗？ 如果会的话，谷歌怎么才能做到这一点？在讨论谷歌可能的行动计划之前，我们不妨先从总体上剖析一下编程的生产效率。
程序员的生产效率可以归结为一件事：
如果我们必须替谷歌回答这些问题的话，我们该怎么做？
作为一名程序员，我关注的不是 Simplicity Sprint 公告背后那些经济上的催化剂，而是它的后果和影响。
说到生产力，季报和年报数据对大公司来说其实并不重要。他们有长达十年的产品推进计划。如果某个东西今天看起来很糟糕，那更有可能是源于 5 年前某个人的错误判断，而这个人现在已经摆脱了这场指责游戏。
我们先把主要问题解构一下：
当你想通过改变公司文化来提高生产力时，具体会怎么做？ 如何才能在不影响盈利能力的情况下做到这一点？（可以提高生产力但会降低利润的方法有一百万种） 如何才能在对员工积极性影响最小或没有影响的情况下做到这一点？（不是每一位雇主都关心这个问题，但这里我们说的是创立了开放文化的那家公司） 如果公司是一间只有 10 名开发者、总是亏损的 IT 作坊，你该怎么做？如果公司有 170000 名员工市值达万亿美元，又该怎么做？当你想进行大规模的组织变革时，对于如何衡量成功这个问题，你需要非常谨慎。
要想快点做完一件事，最好的办法是把它做好，不管需要多长时间。
你需要定义简洁的小组/团队/角色，再加上强大的模型来确定个人和团队是通过还是不及格，以便：
表现好的可以获得奖励 表现一般可以受到鼓励变得更好 表现不佳的可以得到帮助，或者在最坏情况下得到恢复作为一名有 20 年经验的资深程序员，每次想到生产力，我都会想到卓越。
换句话说，要想快点做完一件事，最好的办法是把它做好，不管需要多长时间。
OK，废话少说，我们就来深入了解一下生产力在程序员的生活中意味着什么吧。
为什么说编程的生产力是个奇怪的概念：
生产力就是单位时间内完成的工作量。
时间就是金钱——这不仅仅是一句谚语，也是经济事实。工人工作的时间越长，他/她得到的报酬就越多。项目持续的时间越长，成本就越高。
作为买家，你总希望供应商能够在尽可能短的时间内履行你的订单。作为公司所有者，你需要的是始终满负荷工作的工人，能制造出越来越多的东西发送出去，让你的腰包越来越鼓。
我们对生产力的理念是如此痴迷，以至于所有的经济模型都奖励生产力。在所有因素相同的情况下，生产力是一个国家提高 GDP 的唯一有机途径。
时间就是金钱——这不仅仅是一句谚语，也是经济事实。
但是，如果把同样的生产力效率应用到编程去的时候，情况就会变得危险。计算机是把工作自动化的设备。但它的能力完全要取决于它的主人——程序员，要看主人给它编出来什么样的程序。
现如今，一款智能程序（甚至在普通个人计算机上面就能跑）可以在几个小时内处理十亿条记录。但是，开发出这样一款程序需要非常聪明的程序员，还要有合适的基础设施。以及在学习、设计、编码、测试和迭代上面花费大量时间。
就编程而言，变成的编程与工厂和服务行业相反，远非线性的关系。
普通程序员天天都在写代码，但 sprint （冲刺，敏捷软件开发的术语，指时间固定的周期，在此周期内要完成一次迭代开发）结束时还是没法交付。另一方面，专家级的程序员可以无所事事一行代码都没写就过了好几天，但在 sprint 结束时，却能提供完全可行的解决方案，这一点往往连他们自己都感到惊讶。
更令人惊讶的是，如果你将程序员的角色颠倒过来，结果并没有什么不同！生产力不再受制于专家。
这种模式让我想起了 XKCD 的那幅漫画：
上：鲍尔默峰值，描述了编程技能与血液酒精浓度的关系；下左：该曲线名为鲍尔默峰值，由微软于上世纪八十年代发现。原因不明。不过血液酒精浓度在0.129%到0.138之间可有超人的编程表现。下中：不过要维持这种效应需要小心校准，不可能给一群码农一整年的威士忌然后就叫他们开工。下右：有过先例吗？还记得Windows ME吗？我就知道！ 资料来源：XKCD
如何实现编程的生产力？要靠一开始就做对的事情来实现，而这又要取决于以下两个因素：
程序员的能力——他/她对计算机科学基础的掌握情况 他/她为设计解决方案而经历的生产力爆发时刻——这种时刻的频率和持续时间在某些时候，衡量生产力会变成薛定谔的猫。
产品公司历来都采用用例、类、功能或 LOC（代码行）的数量来衡量生产力。在数据丰富的源代码控制系统时代，最流行的标准也可以是程序员执行的合并请求及/或提交的数量。服务公司则通过关闭的工单数量来衡量生产力。
任何一家公司到了某个时候，衡量生产力都会变成薛定谔的猫。衡量得越精细，事情就会变得越混乱。所有的衡量标准最终都会变成苹果与橙子的比较（或者更糟，苹果与飞机的对比）。除了衡量的开销之外，这些做法最终还会给团队带来巨大的而不必要的压力，降低他们的生产力，从而抹杀其真正的目的。
在宏观层面上衡量生产力是非常有意义的。凭借着工厂时代的管理方式，亚马逊成功实现了这一目标，尽管实现这一点付出了大量人员流失的代价。
如果愿意的话，具备谷歌那种工作文化水准的公司也可以巧妙实现这一目标。
当谷歌说员工生产力下降时，其实它真正的意思是：
当谷歌觉得自己的员工效率低下时，意思并不是说他们没法在相同的时间内干完相同（理想）的工作量。
它的意思是随着时间的增加，他们没法让工作的影响成倍增加。
能开发出好模块/产品的程序员不知道该拿这些东西来干什么 建立起出色数据模型的数据科学家不知道要纳入哪些参数 手头积压着出色产品的经理找不到具备适当能力的资源 不断做出新设计并进行 A/B 测试的产品设计师不知道为什么会出现这样的测试结果，或者是否已经通过了饱和点 最容易忘记的一点：上述所有角色都知道怎么处理自己的交付物，但他们的上级或谷歌本身没有给予他们足够的授权。这就是他们所谓的谷歌员工效率低下的意思。
但是这些问题该如何纠正呢？
业务分析：推出更新的产品的工作人员要花时间，与来自各个地区的创收用户打交道。此外，要主动跟踪分析事件——哪怕是很少发生的事件。 少做 + 重用：SOLID（单一功能、开闭原则、里氏替换、接口隔离以及依赖反转）、DRY（不要重复自己）、测试以及自动化。样板文件用代码生成。如果东西已经有了，避免重复造轮子。 建设能开发功能的能力：普通程序员 N 小时开发 N 个功能。专业程序员 N 小时开发 1 个能力，这样普通程序员就可以开发出无限数量的功能。 研究能产生有益影响的想法：用同样的算法时，与其研究火星表面图像的搜索，不如研究 YouTube 图像的搜索 不惜一切代价：避免只能用时间线性衡量的任务（如果一个任务可以在 N 分钟内完成，相同任务的 M 个实例需要花 M*N 分钟）总结：
对于软件来说，进展从来不是线性的。那么为什么要衡量实现软件的那些人呢？
大 O 表示法：
我说的是一种完全不一样的衡量程序员生产力的范式。（这个范式也可以适用于其他职业，但这个话题需要单独讨论）
这个范式可以用非常著名的大 O 表示法来表达（一个描述算法性能的概念，为了能在谷歌面试中胜出，那些程序员都会熟记于心）
谷歌（或与其规模相当的任何公司）可以采取以下方法：
对组织角色进行分类，定义一个时间与影响的关系函数。比方说，CXO 角色的时间与影响的关系函数的复杂度为 O ( log N)，也就是如果 CEO 把他/她的工作时间增加 8 倍，结果只会增长 3 倍。 绘制每一位员工的影响，X 轴为时间，Y 轴为影响。 为了让业务目标在生产力方程中发挥重要作用，不妨给 Y 轴的值引入一个乘数。 （比方说：创新乘数 =10，效用乘数 = 7，支持乘数 = 5） 比较相似类别下的员工得分（开发人员与开发人员比、CXO与CXO 比等），然后根据得分是领先还是落后来予以奖励或协助在对整个组织范围内的创新情况进行衡量后，不管是帮助表现不佳的员工，还是奖励表现突出者都会变得相当容易。
Big( O) 分类示例：
如果由我来掌管谷歌的话（老天保佑，其实它最糟糕的日子还远没到来），我会这么分类。但每个人对角色的评价都不一样，你可以用自己的方式对谷歌员工进行分类。
首先，谷歌面试的终极真相是这个：
O( 1) < O(log n) < O(n) < O(n log n) < O( n^x ) 算法
其中所有对数底均 < n。
O( 1)：客户服务人员——这类员工的工作时间对公司的盈利能力甚至客户满意度的影响最小。
O(log N)：CXO——他们的大部分时间都花在对一线运营影响最小的出差、战略会议、聚会及/或会议上。他们在推出新产品方面很敏捷，但很难在不出现灾难的情况下有效转型。下游的员工已经在听命行事了。
O( N)： DevOps 、UX 设计师、测试人员——在敏捷时代，部署是每个项目的核心。DevOps 掌握着所有重要的开关。不过，他们的自动化确保结果出现在即将到来的周期内。
尽管现在的 UI 设计工具已经越来越智能，但 UX/UI 设计师仍然必须按照 UI 元素的比例进行原型设计。
所有类型的测试用例与用例/功能单元都是等比的关系，所以测试人员的工作也属于同一个 O( N) 类。
O( N log N)：架构师——他们的工作对代码质量非常重要。即便在设计确定之后，架构师干预的对错也会对产品的质量和推广决策产生相当大的影响。
O( N^X)：核心开发人员——核心开发人员是唯一知道如何编码的需求所有者，也是实际的代码编写者。他们越了解自己的工作，获得授权越多，产品就能产生几个数量级的差距。就算写错一个字符，如果在整个 SDLC （软件开发生命周期）中都不被发现的话，就有可能导致数百万的损失。
核心开发人员是最终的看门人，有可能引入或排除未来 1000 倍数量的 bug、重构尝试以及回归。这只是遵循我们之前建立的假设：
做一件事最快的方法就是把它做好，不管需要多长时间。
结论：
在员工能处理什么这件事情上，谷歌处在自由度最大的另一端
在 2000 年之后的十年间，微软面对的几乎是生存危机。当它决定重振旗鼓时，它并没有选择亚马逊那种数据驱动的人员管理方式。
相反，它选择了对开发人员充分授权。它还采用了更新的技术，对开源的态度更加开放——它之前一直强烈反对开源。
谷歌的问题在于，在员工的自由度方面，它已经走到头了。有了这个基准，它就只能走亚马逊的路，只是走的时候需要非常非常小心。
当然，任何重新定义绩效考核方式的尝试都必然会给整个组织带来一些情感上的损失。
谷歌在对比橙子和橙子的时候越理性，就越有可能在完成这一转变之后的某一天实现复兴。
译者：boxi。
相关推荐
折叠屏手机能提高我们的生产力吗？
名创优品业绩下滑，号召员工降薪、停薪留职 | 钛快讯
苹果、谷歌、微软齐发二季报：营收百亿美元规模，利润均大幅增长
谷歌园区改造计划：后疫情时代，如何吸引员工回归办公室？
微软谷歌Meta集体“扑街”，投资人却在狂欢？
谷歌、微软、苹果发布财报：业绩大增、未来难以维持增幅
业绩大幅下滑的高通，股价为啥创十年新高？
苹果业绩风向标：富士康四季度收入同比下滑
如何看待企业明星员工
一个谷歌员工的“数字游牧”实践
网址: 业绩大幅下滑，谷歌如何提高员工的生产力？ http://m.xishuta.com/newsview65401.html
