行業內的，並且也在博世呆過。
為什麽博世裁員？先講兩個我身上發生的故事：
博世2018年時候提過內部轉型，蘇州研發中心當時招了100多有互聯網背景的開發人員，給的薪資相對於博世薪資體系來說已經非常高了，並且這部份人進來後，博世開始轉向互聯網那一套開發規則，包括敏捷開發。最後這100多人在不到三年的時間裏，剩下了不到10人。原因是博世老員工非常排斥這套變革，我在職期間和博世老開發人員有過兩次激烈沖突。
一次是一個release版本出現了一個問題，TPM不想著正向排查，卻讓我回退到上一個叠代版本，我在會上說這樣查會把叠代節奏打亂，TPM說沒關系，叠代不重要。於是激烈爭吵後我說「這個版本你是owner，你說什麽就是什麽吧」，最後依著TPM把叠代版本回退了，大家不歡而散。
還有一次，是客戶端版本出問題，客戶那時候也是約定好和博世一起搞叠代，但客戶那邊也是慣性使然不遵守開發milestone。然後這個出問題的版本是上上個叠代的（客戶實際還是瀑布開發）。要我們基於上上個版本查這個問題，不認可我的折中方案（我的折中方案是在這個版本重測此問題看還有沒有），然後這次是這個計畫的PM跳出來說按客戶的去做。
當時我是版本經理，負責推進敏捷開發模式落地，和這個PM解釋了好久，PM不認可我的說法，於是大吵一架，最後仍舊無果，被迫按PM的方式執行。
這兩個問題只是博世問題的縮影。
再講從這兩個問題上能看出博世究竟出了什麽問題？
在講這個之前，我需要講一下，現在的汽車和以前的汽車相比，究竟有什麽變化。
2010年之前的汽車，三大件是：底盤，變速箱，發動機，核心技術是硬體，控制邏輯（軟體）有，但是不多，消費者反饋的問題也主要集中在硬體上。
2010年之後的汽車，三大件有的還是底盤變速箱發動機，有的變成了電機電控電池。但不管是哪種三大件，借芯片技術起飛的光，軟體占比開始有質的變化，在這之後的車，消費者反饋的問題開始大幅向軟體問題上傾斜（因為軟體復雜度有幾何級的增加）。
博世管理層不是沒有前瞻性，不是沒有預料到這個趨勢，否則當時也不會招聘我們這些互聯網背景的人去博世。
但博世的基礎還是立足於重硬體輕軟體的那套開發，還是瀑布式那種流程，主要的人員也都沒經歷過超大規模的軟體開發協作。所以即使招聘了一批互聯網的人，也於事無補。
博世現在發生了什麽?
舊業務的產品技術已到瓶頸，被後來者趕上，進而搶奪其原有客戶（代表產品ESP），新業務需要軟體基因，博世又沒有（博世ADAS和DHU份額不斷下滑）。
博世成立至今已經一百多年了，這一百多年博世一直在變革中求生存，所以我不懷疑博世自我變革的決心。
但這一次和以前不一樣，以往博世的變更只是產品線的擴充套件，做產品的方法論和思維一直是小幅變動。這一次變更，往遠了說，是資訊科技革命在汽車行業上的延伸。沒有互聯網基因，沒有互聯網思維，很難在這次變革中活下來。
現在的裁員只是開始，博世如果不能壯士斷腕，前景暗淡。
====================
2024.11.28：
有回復問「博世不是已經有純軟體團隊了嗎，怎麽能說博世沒有轉型軟體？」
我還在博世的時候，無錫，越南，印度的軟體團隊就已經快成型了，而且和他們打交道非常多，對他們還有一些了解，這幾個團隊最大的問題：
1.品質體系，測試體系仍舊是老博世那一套，而博世體系根本不適用於軟體公司。
2.中層管理基本全都是博世老員工，人的思維對軟體開發的影響有多大，幹過軟體的人都知道。
比如說軟體開發更像是精英作戰，以人為中心，規則和制度盡量只做保底，發揮人的主觀能動性。而博世的老員工（中層管理）更信賴流程，認為流程是一切的基礎。這樣的思維如果不轉變，根本做不好軟體。
再比如博世中層管理在計畫kickoff時候就要把需求定好，這是完全不可能且沒必要的，也和軟體開發行業背道而馳，溝通成本極大。
3.薪資體系和市場脫節嚴重，缺乏精英程式設計師。
軟體開發行業更像空軍飛行員，精英往往能左右戰局，而博世這幾個軟體中心，非常非常缺乏精英程式設計師。
如我在下面回復中所說，博世最應該做的是收購，用資本控制子公司盈利，自己搞軟體研發中心也不是不可以，只要能做到這個新團隊完全遮蔽掉博世老員工，但實際上這是不可能做到的。
=============
2024.11.29：
感謝大家的回復和贊同。
我看到下面有不少人質疑「敏捷開發不適用於汽車行業，因為敏捷開發出來的軟體不穩定」。
不客氣地說，這是對敏捷開發極大的誤解。
你所能看到的網路遊戲，各種日常生活中用到的資料庫伺服器，各種通訊裝置甚至飛機的飛控裝置，都是敏捷開發的產物，如果往前追溯，敏捷開發甚至可以能追溯到波音和空客的發展史。
如果你發現你所在的企業或者團體用敏捷開發的時候出現了很多穩定性問題，那只有一種可能就是你們沒把敏捷開發搞好。
我算是敏捷開發半個專家，我這個「專家」不是純理論的，我是從一線程式設計師到計畫管理到部門管理，中間做過系統工程師做過架構，做過測試。我是從實戰中摸爬滾打過來的，我可以不謙虛地說我還算是懂敏捷開發的。
具體不展開講，因為這玩意講起來太枯燥了，只說如果想做好敏捷開發，避免出現穩定性問題，有幾個最關鍵的點：
1.各component解耦，必須要把解耦做好。
2.平台化，只有一個程式碼庫，不同計畫用適配層適配，基本的平台程式碼不動，如果動，必須CCB，而且CCB要好好開。
3.版本節奏管理，什麽時候發版，什麽時候測試，測試scope定義好。
我做過很多對產品穩定性要求非常高的計畫，比如企業級路由器，比如網路遊戲，還有基站。這些產品對穩定性的要求不比車低，車出問題了，還有冗余備份，司機還有一部份的主觀能動性，這些產品出問題了，絕大部份情況下是沒有冗余的，所以一旦出問題，結果就是金錢的損失和企業聲譽的損失。
最後想說的是，評論區有人說的對，敏捷不是萬能的，有些產品不適合敏捷，但現在的汽車，只有敏捷才能做好，而敏捷的門檻是很高的。需要管理者對軟體開發有相當深厚的了解。但實際上做好敏捷的企業不多，除了一些頭部互聯網企業以外，華為也是敏捷做的最好的企業之一。多說一句，華為之所以有今天，不光靠狼性文化，整個社會對華為的了解還是太少了。
另外，隨著回復越來越多，有人開始擡杠了，對於這些人我想說的是"對對對，你說的都對。"
