狗屁大廠，都是草臺班子

早上刷牙時，腦子裡突然蹦出個念頭：大廠，其實都是草臺班子。

這想法有點大逆不道，畢竟人家個個市值千億

但是，大廠的發家史，本質上就是一部“先幹起來再說”的野史。

聽說，滴滴的第一個版本是花8萬塊錢外包做的，字節跳動最早在錦秋家園租房子，張一鳴親自寫代碼，辦公室堆滿服務器，夏天熱得像蒸籠

別管姿勢多難看，先跑起來再說。

有個朋友在TMD大廠做開發，他們組最老的系統是用COBOL寫的，現在全司上下對待這段代碼的態度，比考古學家對待兵馬俑還謹慎——畢竟這玩意兒要是崩了，可能連會修的人都挖不出來。

CTO說要搞"中臺戰略"時，新來的架構師打開代碼庫一看，當場就報了工傷——這哪是技術債？這分明是技術高利貸！

在大廠待久了就會發現，這裡最魔幻的不是技術，是人。

實習生改了個按鈕顏色，週報上寫"通過UX重構提升生態轉化率"；程序員刪了幾行廢代碼，彙報時說"完成技術減負戰略"；產品經理加了個篩選框，非得說是"構建用戶心智矩陣"。最絕的是某廠的年終評優，有個組靠"成功將系統崩潰時間從每週五次降到三次"拿了創新獎——這要擱醫院，就是給ICU大夫發"最佳續命獎"。

有個VP的名言特別精闢："在我們這兒，能把一棵草說成森林的都當總監了，真把森林種出來的還在通宵改bug。"這話讓我想起前同事的至理名言："大廠的PPT就像女明星的妝容——功能不重要，重要的是看起來值錢。"

總之，只要PPT夠華麗，問題就不是問題。

在大廠，老實人埋頭改需求，聰明人琢磨怎麼寫OKR。你說你做了600個需求？領導皺眉：“沒有聚焦。”但如果你說“通過技術賦能，提升搜索效率90%”，那就是“高潛力人才”。

等公司上市了，老闆們終於想起來要“優化流程”“提升效率”，但這時候的架構，已經成了一座哈爾的移動城堡——新系統上線？老系統不敢關，只能並行跑。數據遷移？搬一半發現不對，又搬回去。業務不能停，只能搞“兼容”，美其名曰“平滑過渡”，實際就是“湊合着用”。

大廠技術三件套：重構、遷移、兼容。

重構=“我們把代碼重新寫了一遍，但功能一點沒變。”

遷移=“數據搬來搬去，業務方根本不知道。”

兼容=“新舊系統一起跑，誰崩了算誰的。”

你說這能不出問題嗎？當然能。但大廠不怕

爲什麼草臺班子還能賺錢？答案很簡單：規模夠大，容錯率就高。

大廠的生存智慧在於：用20%的精英cover80%的混亂，靠用戶規模自動填坑，實在不行就砸錢——系統崩了？加服務器！體驗差？發補貼！代碼爛？反正投資人又看不懂！

所以在大廠混，得掌握核心生存法則：

黑話要夠黑——"修bug"要說成"技術債重構"，"拍腦袋"要包裝成"頂層設計"

姿勢要夠帥——同樣的需求，要說"這個要閉環""那個要賦能""整體要沉澱"

心態要夠佛——當你看到新來的95後總監把"用戶增長"說成"流量生態反哺"時，要像郭德綱看公式相聲一樣保持微笑

所以，大廠真的是草臺班子嗎？

從微觀看，是的——系統混亂、流程冗長、人人都在甩鍋。

但從宏觀看，它已經成了一個有機體，能自我修復、持續進化。破個口子留個疤，照樣活蹦亂跳。

大廠虐我千百遍，我待大廠如初戀。

不是因爲它多完美，而是它給的實在太多了。

所謂成熟，就是發現所有公司都是草臺班子後，依然認真演好自己的角色。

寫完這篇文章，我的OKR自動升級了：關鍵結果從"獲得1個在看"變成了"引發行業深思"。要是沒達標？那就改叫"戰略性數據沉澱"。

畢竟在大廠，改KPI比改代碼容易多了。

來源 | 陳天宇宙（ID：chentianyuzhou）

作者 | 陳天宇宙 ; 編輯 | 蝦餃

內容僅代表作者獨立觀點，不代表早讀課立場