作者 | 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??