#粉丝投稿# 希望文中提到的“老大”，能看到这篇投稿。

刀哥你好，我在一家汽车Tier 1供应商工作。最近集团老大要来事业部检查工作，现在整个事业部已经进入了“迎检模式”，高层一边疯狂优化数据，一边强推所谓的敏捷改革，下面的人已经快被折腾疯了。

所谓“优化数据”，你懂的。业绩要好看，利润要好看，项目验收也要好看，总之最后呈现出来的结果就是：虽然今年行业这么卷，但我们依然取得了非常不错的成绩，而且改革正在如火如荼地进行。

但真实情况是，这段时间人员流失非常严重，有些核心团队甚至出现了成批离职。大家嘴上都在讲改革，下面为了完成指标，各种形式主义和数据包装反而越来越多。

最让我担心的还是研发流程。

现在事业部老大想把自己以前在其他行业做敏捷开发的成功经验，直接复制到汽车业务上。简单说，就是希望产品经理在需求输入阶段，把需求、风险、可行性尽可能一次性想清楚，然后直接拆成非常细的验收条件，研发、测试按照这些条件快速往下做。

听起来效率确实提高了，但问题是，我们做的是汽车产品，不是普通互联网产品。

以前一个需求进来，研发会细化需求，测试会制定测试方案和用例，然后研发、测试、产品以及客户前端相关人员一起评审。大家一轮轮讨论，经常会发现最初根本没有考虑到的问题。这个过程确实慢，开会也多，但很多风险恰恰是在这里被提前消灭的。

现在为了“敏捷”，这些环节被大量压缩甚至合并。

需求一旦拆完，后面的开发和测试对于产品和客户前端来说，很大程度上变成了黑盒。等到Demo验收的时候才重新看到东西。如果发现结果和客户实际需求不一致，要么认为前期需求没有拆细，要么接受一个不够完善的版本，再进入下一轮修改。

这套逻辑放在互联网产品上可能成立。一个功能先上线，有问题再快速迭代，A版本不行做B，B不行再做C。

可汽车行业的问题是，很多东西最终要装到车上。

而且现在主机厂自己的需求也经常变化。可能第一次需求刚输入，过几天客户内部讨论之后，需求又变了。难道后面的变化全部拒绝？还是等Demo做完以后才发现客户需求早就变了，然后重新开发、重新测试，甚至让客户重新做一遍整车验证？

更重要的是，互联网产品一个功能做错了，大不了下个版本修复。但汽车上的一些系统如果设计、验证阶段漏掉了问题，后果完全不是一个量级。

我们下面也有人提出过，工业产品不能完全照搬互联网的敏捷开发，因为产品设计、测试验证和多方评审本身就是风险控制的一部分。

但现在最大的问题是，管理层曾经靠这套方法成功过，所以非常相信这套经验。

我现在越来越觉得，一家公司最危险的时候，可能不是领导没有成功经验，而是领导有一套曾经非常成功的经验，并且坚信它在哪里都能成功。

至于这套改革最后到底行不行，我也不知道。

只希望最后验证它的人，不是客户，更不是消费者。