大公司 | 原創，AI翻譯
大公司的現象
大公司就像大型程式一樣。一家擁有10萬名員工和5萬名承包商的大公司，就像一個擁有15萬個方法的大型程式。
Dario Amodei表示，人才密度比人才數量更重要。兩百名非常有才華的人可以擊敗1,000名有才華的人加上800名普通人。
Dario Amodei還提到，大公司有這麼多程序和流程，是因為他們不信任員工或承包商。因此，他們需要進行大量檢查和控制。
大公司的一個特點是他們害怕犯錯。其中一個原因是，他們已經變得如此龐大，價值3000億美元或1兆美元；他們必然犯了無數錯誤並從中成長。然而，當他們成功時，他們厭惡冒險和再次犯錯。
這就像一個大型程式不喜歡錯誤並試圖消除任何錯誤，特別是在大型銀行中，特別是安全錯誤。
初創公司速度快，但初創公司的資源遠遠不足，初創公司的品牌尚未建立；他們不像大公司那樣值得信賴。
在中國，年輕有才華的人畢業後仍然想進入大公司，並努力實現這一目標。在矽谷，有許多初創公司，其中一些公司在剛開始時就做得很好，僅憑想法。
有些公司經營了20年仍在奮鬥，可能已被從股市中移除，而有些公司僅在幾個月大時就估值50億美元或100億美元。
據說Mira Murati的Thinking Machines Lab在種子輪估值120億美元。Ilya Sutskever的Safe Superintelligence籌集20億美元，估值320億美元。
因此，用建立時間來衡量初創公司不是一個好的指標；更好的是根據團隊的構成、創始人的身份以及他們所在的領域來衡量。
在我的獨立初創公司中，我只需要1分鐘部署後端伺服器，5分鐘修復一個小錯誤並部署。這是直接且快速的。對於大公司，準備部署請求需要1週，獲得經理批准，與IT團隊進行部署，並進行健康檢查。
儘管實際花費的時間可能只有8小時，但如果我們衡量，從準備部署到最終健康檢查仍然需要1週。
修復一個小錯誤並部署需要兩週時間。你會得到調查票，進行分析和測試，然後審查、合併代碼，向測試團隊報告測試，然後部署。
大公司喜歡在所有團隊或項目上強制執行他們的政策。因為對於一個擁有20萬人的大公司來說，那些僅適用於1萬人的政策或內部流程並沒有什麼意義或結果。對於一些內部流程，大公司需要投入人力或資金來開發支持它們的工具。因此，如果它只為少數員工服務，回報就不值得投資。
大公司的另一個缺點是，通常沒有人因為大錯誤而受到懲罰。
在我的初創公司中，我曾獲得50萬美元的投資來僱傭9名員工，但兩個月後，我不得不解僱他們並失去了那筆錢。我通過與兼職工程師合作完成50個小型軟體項目來賺回那筆錢，以償還投資者。
這是一段非常強烈且痛苦的記憶。這讓我時刻記住那個教訓。
在一家大型公司內部，有一個顯著的案例，觀察到那些涉事者沒有受到重大懲罰。一些高級經理和許多最近被僱傭的員工被解僱。尚不清楚這是否與快速且大規模的僱傭熱潮有關。
導致這種結果的因素之一是大公司繁瑣且眾多的流程。在公司工作了六個月到一年的工程師無法做出重大貢獻。時間表通常包括兩個月的基礎掌握，三個月的項目熟悉，三個月的繁瑣流程或測試，最後是兩個月的有影響力的用戶工作。
假設每天工作八小時，兩個月的實際生產力工作並沒有帶來重大成果。部門的預算被耗盡，用戶基礎沒有如預期般擴大，導致進一步的裁員。
看起來，這次經歷並沒有帶來有價值的教訓。最初，一群經理決定採取快速且大規模的僱傭策略，這在當時看起來似乎是不必要的。指責整個經理群體是不可行的，也不切實際地只解僱那些在公司工作時間較短的人，特別是當其他經理和技術負責人已經在團隊中工作了六到八年。
總經理並沒有從這種情況中獲得多少見解，因為這只是他們監督的三個部門之一，他們的薪酬保持不變。即使在團隊內部，那些不直接負責的人也無法從經驗中學習，這與史蒂夫·喬布斯對諮詢的評論相呼應。因此，沒有人吸收了必要的教訓，以形成一個能夠為用戶提供卓越成果的傑出團隊。
對於初創公司來說，情況似乎更好。因為它確實很嚴肅。一些失敗或失敗的創始人真的很艱難，特別是那些誠實的人。
對於那些有道德的人來說，失去大量投資資金，從數百萬美元到數億美元，最終只剩下一個基礎產品或一個用戶基礎，儘管其規模大，但產生的收入微乎其微，這可能是非常令人沮喪的。
Paul Graham曾經寫過一篇文章，僱傭已過時。
但是大公司做得好的地方是什麼？一個是長期主義。他們傾向於長期行事。對於一些好的大公司來說，他們的項目設計相當不錯；他們使用微服務來避免在十年後成為一個龐大的單體程式。他們還有治理團隊來制定一些基礎框架，並統一整個團隊的開發實踐。
流程或程序本身並不壞。但它們往往使事情變得複雜和緩慢。我們不會覺得Java統一代碼格式不愉快，因為有Spotless或Checkstyle插件來幫助。這些插件設計良好且易於使用。
另一件事是大公司傾向於為內部使用開發一些工具或項目，供前線人員使用。但該用戶群僅為數百人或1萬。該用戶群非常有限。
我認為我們更好地使用外部工具來實現該目的。如果一個工具對一家銀行非常好，它可能對200家銀行也很適用。這可以使該公司成為獨角獸。
天成樓，Pony.ai的創始人，說過公司需要獨立的原因是效率更高。這是真的。
大公司傾向於根據經驗來獎勵員工。而市場獎勵初創團隊的結果或執行。他們其實非常不同。
在大公司工作就像在學校學習。你從小學進步到中學，然後到大學。但在初創公司中，有更多的起伏，並且在從一個想法或市場轉向另一個時，有更多的靈活性。
大公司的風險規避的好處是，他們的產品相對穩定，沒有明顯的錯誤或停機。這是好的。
但就像AI一樣，實際上，許多用戶對於早期不太穩定的產品是可以接受的，例如DeepSeek。我們知道DeepSeek在2025年2月和3月下線了很多次，當它獲得大量關注時。但經過一段時間後，它變得更好，似乎沒有用戶對此有太多問題。
所以這取決於情況。有時候，對於創新產品，我們需要盡快將它們推向市場，即使它們有一些問題。用戶可以理解。
如果我們考慮流程，我們可以更謹慎。我們應該更好地分類我們的部署類型。某些類型的變更可以快速部署，而其他類型則不行。在測試方面，我們應該分類哪些部分的測試我們需要為回歸測試執行已更改的代碼，哪些部分我們不需要。對於SonarQube檢查也是一樣。
在大公司中，可以確定的是，許多檢查、測試或批准是不必要的。我們可以讓工程師做他們的工作，而由於系統有所有記錄，我們可以選擇一些進行審查。
我們也應該消除所有經理的批准。經理比工程師知道什麼？這些知識是否可以寫入代碼中自動批准或拒絕請求？
由於那裡的一切都很慢，工人不太可能改變事情。將一個運行了十年的大型單體專案轉變為微服務可能需要兩年時間。
對於軟體，代碼和邏輯緊密相連，特別是在良好設計的系統中。因此，開發、測試或協作所涉及的工作量可能很大。
這就是為什麼突然擴大團隊往往不奏效。如果有一個鬆散耦合的微服務架構，那麼團隊的產出可能與團隊成員的數量成正比。如果有一個緊密耦合的單體專案，那麼團隊的產出可能只會增加30%，如果我們將團隊規模加倍。
由於步伐緩慢，有時很難確定員工或承包商是否無能，還是系統對新加入者來說過於複雜和繁瑣。在一個我觀察到的案例中，有人在公司工作了四個月，卻幾乎沒有做出任何貢獻，僅僅改變了幾行代碼以提交拉取請求。此外，代碼的質量很差，因為他不太理解它。他的英語也很差，只能通過貼上截圖和使用基本英語來提問。
關於穩定性，我發現大公司傾向於讓多名團隊成員執行重複的任務。例如，對於任務A和任務B，他們不會分配兩名團隊工程師分別單獨工作在任務A和任務B上。相反，他們讓兩人都參與任務A和任務B的部分工作，這樣這兩名工程師就知道對方在做什麼。這使得團隊更加穩定，因為它防止了一種情況，即只有一人知道大部分代碼，並且已經在沒有協作的情況下工作了幾年。然後，如果那個人離開公司，沒有人能夠繼續工作。
大公司做得好的另一件事是維持現金流和利潤紀律。原因是，隨著他們變得更大，他們往往面臨重大的財務危機。這可能是他們優先考慮的最重要的事情。他們已經從中學到了教訓，並將這些實踐融入了他們的運營中。即使他們每年賺取100億美元或300億美元的利潤，他們仍然繼續優化他們的勞動力並進行裁員。
我的一位同事告訴我，大公司運營某些產品，這些產品需要大量的勞動力或時間來建立。這是有道理的。他們不依賴於速度，而是依賴於他們的規模、資源和品牌。
如何在大公司中生存？一個是多做，少說。這是我在外包供應商的交付經理告訴我的。
第二件事是遵循他人的做法；這是安全的。成為團隊中的普通工程師是安全的，就像在街上成為普通人一樣——既不太突出，也不太被忽視，而是正好在中間。
我必須說，有許多大公司。有些擁有超過20萬名員工，而有些則約有2萬名。也有表現良好的大公司和表現不佳的大公司。外觀或市值有时並不能透露太多。他們可能在幾年內大幅上升，就像Nvidia最近一樣，或者突然崩潰，就像瑞士信貸一樣。
大公司的工程
大公司擅長嚴格的政策控制和管理。大公司擅長進行仔細的檢查和徹底的軟體發布評估。
但許多工程無法簡化為簡單的規則。設計的簡潔性和每個方法或每個Java類的優化並不容易通過規則檢查。
SonarQube掃描是一件好事，高測試覆蓋率也是一件好事。但許多軟體設計或工程無法這樣簡單地衡量。
API的質量和功能的易用性無法輕易評估。
方法的參數無法輕易評估。函數的設計、分支策略、開發策略無法輕易衡量，命名也是如此。
阿里巴巴有它的Java指南，Google和Plantier有它們的Java格式。這是好的。但Java專案中的所有事情都無法通過代碼自動檢查。
關於測試，這是真的。有許多自動測試工具。但並非所有的測試策略、設計、哲學或技術都有固定的規則。
關於產品，這是真的。有許多A/B測試和數據驅動的產品開發。但並非所有的產品技術、技能或洞察力都能通過固定的規則來衡量。
為什麼我要討論這個？因為這意味着我們的價值在於這些領域。大公司不擅長什麼？這樣我們可以幫助他們做那些。
為什麼我提到大公司的工程而不是公司的工程？其實，這不僅僅是關於大公司或小型初創公司。它們是由人組成的；只是員工人數有所不同。
大公司的工程比初創公司的工程更不多樣化。
關於協作
協作是具有挑戰性的。它涉及共同努力以實現共同目標。讓我們從編程的角度來考慮這個問題。
本質上，每個人都像一個複雜的程式，由生活經驗、工作歷史、世界觀、親密關係、成長經歷和數位互動構建而成。
挑戰在於作為一個團隊實現目標。如何有效地協作？如何讓微服務協同運作？
在個人專案中，一個人擁有和處理一切，無需協作。如今，個人經常使用大量AI工具來實現目標。
在一個由幾個人的小團隊中，責任被分開。例如，一個人可能負責設計，另一個人專注於開發。或者，一個人負責後端，另一個人負責前端。
在大公司中，經常擔心員工離職，這會在專案中造成知識缺口。接替責任的新人可能需要幾個月甚至一年的時間來跟上，從而減緩或停滯專案。
然而，在AI時代，我相信我們應該改變我們的方法。”人月神話”的概念仍然成立。
我強烈提倡自然協作。為了團隊的利益，隨著專案的推進，某些協作習慣會在團隊中自然形成。
這類似於代碼的自然模組化。在某些開發後，我們可能有50個Java類，然後我們將它們組織成套件。同樣，在有100個Python文件的情況下，我們使用模組來管理它們。
任務分離應考慮每個人的優勢。在AI時代，個人可以在多個領域表現出色。因此，我們應重新考慮如何將大型任務分配給團隊成員。
我相信，每個團隊成員應該在一個時間負責相對較大的任務。這種方法減少了頻繁與他人溝通或對齊的需求。大型任務應相對獨立，使個人可以向擁有更多專業知識的高級團隊成員尋求幫助。這樣，更多的人可以參與，但任務主要由指定的人擁有。
如果兩個人協作來編輯每一行代碼或共同處理每一個細節，這可能會很繁瑣。他們需要在每一步上對齊行動，這是具有挑戰性的。在計算中，有許多實現目標的方式。只要結果質量良好並滿足目標，我們應該接受不同的方法或工具，無論是特定的IDE、SQL客戶端、Python腳本還是手動流程。
協作的另一個改進是確保工作記錄盡可能透明。在我的最近工作中，我與團隊成員分享了我的腳本、日誌和筆記。我可以分享我向Copilot提出的查詢、沿途遇到的問題以及相關的日誌。這種透明度使與團隊成員的溝通更容易。
通過這種方式，這類似於在執行任務時錄製我的電腦螢幕。儘管我們在此使用文字來分享信息，但更好的溝通目標已實現。
為什麼協作會失敗？什麼樣的情況會導致協作不成功？一個原因是團隊成員之間的期望不一致。可能的結果是專案延遲或工作無法達到質量要求。