行业内的，并且也在博世呆过。
为什么博世裁员？先讲两个我身上发生的故事：
博世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定义好。
我做过很多对产品稳定性要求非常高的项目，比如企业级路由器，比如网络游戏，还有基站。这些产品对稳定性的要求不比车低，车出问题了，还有冗余备份，司机还有一部分的主观能动性，这些产品出问题了，绝大部分情况下是没有冗余的，所以一旦出问题，结果就是金钱的损失和企业声誉的损失。
最后想说的是，评论区有人说的对，敏捷不是万能的，有些产品不适合敏捷，但现在的汽车，只有敏捷才能做好，而敏捷的门槛是很高的。需要管理者对软件开发有相当深厚的了解。但实际上做好敏捷的企业不多，除了一些头部互联网企业以外，华为也是敏捷做的最好的企业之一。多说一句，华为之所以有今天，不光靠狼性文化，整个社会对华为的了解还是太少了。
另外，随着回复越来越多，有人开始抬杠了，对于这些人我想说的是"对对对，你说的都对。"
