作者 | Pen Magnet
策划 | 云昭
谷歌开始裁员了！
9月15日，外媒宣称谷歌开启了裁员行动，从现任CEO Sunder Pichai 六年前自己创建的屡创佳绩的关键部门120区员工开始，该部门将保留原来一半左右员工数量。多年来，该内部孵化器的生产效率一直很高—它催生了50多个项目。
这之前并非没有征兆。7月，Alphabet公布了公司连续第二个季度的盈利和收入不及预期，其收入增长停滞在13%，而2021年同期则为62%。
钱不是从树上长出来的，像谷歌这样有前途的公司明显真的被刺激到了。就在不久前，9月1日的谷歌内部全员会议上，Pichai声称，谷歌正在一个“具有挑战性的宏观经济环境”中运作，员工应该“深入思考变化”，并且宣布了名为“Simplicity Sprint，简单冲刺）”的方案，旨在提供员工的生产效率。
以下是 Sunder Pichai 在他的演讲中所说的：
谷歌确实担心，我们的整体生产力并没有达到我们现有的人数所需要的水平。请帮助我创建一种更注重使命、更注重产品、更注重客户的文化。我们应该考虑如何最大限度地减少分心，真正提高产品卓越性和生产率。
这并不奇怪。然而，很少有人会想到谷歌公开宣布需要提高员工生产力。
强调效率的真实用意
在如今的大环境下，可能裁员本身并不奇怪。然而，很少有人会想到作为全球最大的科技公司之一，谷歌公开宣布需要提高员工生产力，多少还是让人有些唏嘘。
因为谷歌一直被人们津津乐道的是开放的员工文化，丰厚的工作福利。至少在公开场合，谷歌的高层也很少谈及员工的“生产力”、“效率”。
相反，同为FAAMG成员的亚马逊，则一直强调利润而在员工加班和解雇方面表现得更为“豪放”。因此，大幅度裁员也会让其受到“高损耗”的诟病。正因如此，它很少因员工生产力下降而牺牲利润。
但谷歌不是亚马逊。事实上，在对待员工方面，它正走向了另一个极端。
谷歌是现代开放文化的创始人
处于Larry 和Sergey时代的谷歌是当今 IT 行业享有的开放文化的创始人。
彼时在硅谷，谷歌极端的内部民主和透明度一度被视为是“边缘无组织”状态。
- 部门的决策很少受到高层管理人员的猛烈抨击。
- 调查和内部民意调查确保每个人都知道公司的发展方向，每个人都被听到，至少在投票方面。
- 谷歌的 20% 项目福利（允许员工20%的工作时间开发自己的项目）被称为其创新配方的公开秘密成分。
在Larry和Sergey于 2019 年从 Alphabet 高层离职后，谷歌第一次面临盈利挑战。
除了极高层的谷歌内部人士之外，没有人能回答这些问题：谷歌的投资者会强迫其管理层采用类似亚马逊的文化来衡量开发人员吗，就像一个驯兽师对待他的动物一样？如果是，谷歌会妥协吗？
生产力下降是开发者的锅？
效率下降的真正含义是什么？ 作为一名开发者，也许关注的并不是 Simplicity Sprint 公告背后的经济因素，而是它的后果和影响。
而谈到生产力，季度和年度数据对大公司来说并不重要。他们有长达十年的产品推广计划。如果某件事今天看起来很糟糕，那更有可能是源于 5 年前某个人的错误判断，而这个人目前可能已经不在指责游戏的视野之中了。
让我们解构我们的主要问题：
- 当你想改变公司文化以提高生产力时，你具体是怎么做的？
- 如何在不影响盈利能力的情况下做到这一点？（有一百万种方法可以提高生产力并降低利润）
- 如何做才能对员工积极性影响最小或没有影响？（不是每个雇主都关心它，但这里我们说的是开放公司文化的创始人）
- 对于一个拥有 10 名开发人员的亏损 IT 商店与拥有 1,70,000 名的万亿美元估值组织，你如何做到这一点？
- 当你想进行大规模的组织变革时，需要非常谨慎地衡量成功的方式。
做某事最快的方法就是把它做好，不管需要多长时间。
你需要对组/团队/角色的边界做出简明的定义，同时构建坚实的体系维度来综合考核个人和团队的通过/淘汰，以便：
- 表现优异者可以获得奖励
- 中等水平的人鼓励变得更好
- 表现不佳的人可以得到指导，或者在最坏的情况下，给予改过自新的机会
作为一个 20 年的资深程序员，每次想到生产力，我能想到的都是卓越。换句话说，就是做某事最快的方法就是把它做好，不管需要多长时间。
忙里偷闲之际，我们需要深入了解生产力在程序员的生活中意味着什么。
对编程者使用生产力原则很冒险
生产力是单位时间内完成的工作量。
时间就是金钱——这不仅仅是一句谚语，而是一个经济事实。
工人工作的时间越长，其得到的报酬就越多。项目运行的时间越长，成本就越高。
作为买家，你总是希望供应商能够在尽可能短的时间内完成你的订单。
作为公司所有者，你需要一个始终满负荷工作的工人，生产越来越多的产品来运送，从而丰富你的金库。我们与生产力的执念如此之深，以至于所有的经济矩阵体系都在激励（提高）生产力。在所有因素相同的情况下，生产力是一个国家提高 GDP 的唯一有机途径。
然而，当在编程中应用相同的生产力原则时，事情就会变得很冒险。计算机是一种使工作自动化的设备。但它的大小完全取决于它的程序员主人——因为是他们在代码中进行类型设置。
今天，一个在普通PC上运行的智能程序可以在几个小时内处理十亿条记录。但每个智能程序的背后是聪明的程序员以及合适的基础设施，其中的学习、设计、编码、测试和迭代，都会花费大量的时间。
在编程领域，恰恰与工厂和服务行业相反，生产力远不是线性的。普通程序员每天都在编写代码，但在 sprint 结束时却无法交付。另一方面，专家级的程序员，几天过去了，可能都没有几行代码，但往往在冲刺结束时，他们却能会提供完全可行的解决方案，这一点连他们自己也会感到吃惊。
更令人惊讶的是，如果你将普通程序员和专家程序员的角色互换，结果并没有什么不同！生产力不再受制于专家。
编程的生产力是通过一开始做正确的事情来实现的，这取决于以下两个因素：
- 程序员的能力——其对计算机科学基础的掌握
- 程序员为设计解决方案而经历的富有成效的爆发时刻——它们的频率和持续时间
生产力测量变成了薛定谔的猫
软件产品公司历来使用用例、类、功能或 LOC（代码行）的数量来衡量生产力。在数据丰富的源代码控制系统时代，最流行的标准也是程序员执行的合并请求和/或提交的数量。服务公司通过关闭的票证数量来衡量生产力。
在每家公司的某个时候，生产力测量都会变成薛定谔的猫。措施越精细，测量就会变得越混乱。所有的衡量标准最终都会变成苹果与橙子（或者更糟糕的是，苹果与飞机）的比较。除了测量开销之外，这种努力最终会给团队带来巨大且不必要的压力，降低他们的生产力，从而抹杀掉其真正的目标。
在宏观层面上考虑生产力测量，是非常有意义的。亚马逊凭借其工厂时代的管理方式，成功实现了这一目标，尽管当中也为此付出了不少代价。
一家具有 Google 工作文化水准的公司如果愿意，可以巧妙地实现这一目标。
降低员工效率的真实原因
当 Google 觉得其员工效率低下时，这并不意味着他们无法在相同的时间内完成相同（理想）的工作量。这意味着随着时间的增加，他们无法将工作的影响成倍增加。
- 创建出色模块/产品的程序员不知道如何使用它们
- 创建出色数据模型的数据科学家不知道要包含哪些参数
- 拥有不少工作积压的经理无法找到具有适当能力的资源
- 不断创建和 A/B 测试新设计的产品设计师，不知道测量结果的原因，或者说不清楚结果是否已经达到了饱和点
- 最容易忘记的：上述所有角色都知道如何处理他们的交付，但他们的上级或谷歌本身没有赋予他们足够的权力。
这就是他们说谷歌员工效率低下的意思。
但如何纠正这一点呢？
- 商业分析：商业分析的重要性不言而喻。推出新产品的白领们，可以花时间与来自各个地区的底层用户进行接触与沟通。此外，积极跟踪分析事件，即使是很少发生的事件。
- 少做+重用：SOLID、DRY、测试和自动化。使用代码生成样板。如果东西已经存在，就要避免自己重复推出。
- 构建“提升功能”的功能：普通程序员在 N 小时内构建 N 个功能。专家程序员则在 N 小时内构建1个功能，但这个功能却可以让普通程序员能够创建无限数量的功能。
- 研究具备切实有益的想法：与其致力于火星表面图像搜索，不如使用相同的算法研究 YouTube 图像搜索
- 不惜一切代价：避免只能用时间线性来度量的任务（如果一项任务可以在 N 分钟内完成，相同任务的 M 个实例将花费 M*N 分钟）在软件中，性能的提升从来都不是线性的。那么为什么要这样测量那些实现者呢？
大O表示法
《Comprehensive Approach to Senior Developer Interview》一书的作，Pen Magnet 提出了一种完全不同的程序员生产力测量范式。
范式可以用非常著名的大 O 表示法来表达（大O这个算法性能概念对于程序员可谓烂熟于心，面试中经常被问及）。
谷歌（或同规模的公司）可以采取以下方法：
- 对组织角色进行分类，并定义其时间与影响功能。例如，CXO 角色的时间与影响函数的复杂度为 O(log N)，即如果 CEO 将他/她的工作时间增加 8 倍，结果只会增长 3 倍。
- 绘制每个员工的影响值，X 轴为时间，Y 轴为影响。
- 为了使业务目标在生产力等式中发挥重要作用，需要为 Y 轴值引入一个乘子。（示例值：创新 = 10，效用 = 7，支持 = 5）
- 比较相似类别下的员工得分（开发人员与开发人员、CXO 与 CXO 等），然后根据一个人是领先还是落后来奖励/协助
当对整个组织范围内的创新规模进行衡量之后，帮助表现不佳的员工、奖励成就者都是容易开展的。
大（O）分类示例
以谷歌为例，下面是我想出的分类。（每个人对角色的评价都不一样，你按照自己的方式对 Google 员工进行分类）。
首先，来自谷歌面试的终极真相：
O(1) < O(log n) < O(n) < O(n log n) < O(n^x)，其中所有 log n < 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 倍错误、重构尝试和回归的最终看门人。以上这些都是要遵循我们之前建立的假设：
做某事最快的方法就是把它做好，不管需要多长时间。
结论
科技巨头在面临重大转折时都各有选择。
在 2000 年之后的十年间，微软几乎面临生存危机。当它决定重振旗鼓时，它并没有选择亚马逊的数据驱动人员管理方式。
相反，它选择授权其开发人员。它还采用了更新的技术，对开源更加开放——这曾是它一直强烈反对的事情。
Ben认为，谷歌目前的问题在于它已经处于员工处理自由度光谱的另一个极端。有了这个新的基调，它就只能走亚马逊的路，不管这条路有多难走。
任何对人的衡量方式的重新定义的尝试，都必然会给整个组织带来一些情感上的损失。
谷歌在“橙子和橙子”之间作比较时越理性，它在这一转变之后实现复兴的可能性就越大。
原文链接：
https://levelup.gitconnected.com/why-google-employees-dont-work-f6a7521a6ed6
