如果说软件开发的初衷是为了演示或者只是做个玩具，我并不反感甚至不认可“明天”的开发方式，因为它敏捷、高效和低成本。但是我们选择了汽车这个产品类别，这几乎是软件开发的地狱模式。很多三观需要颠覆。作为一名软件算法工程师，能够让软件在车上跑的好是唯一的目标。这个目标的逻辑没有问题，但是量产是什么概念？是多个项目的并行开发；人员严重短缺，关键人员始终处于空闲状态；需求的快速变化仍然存在很多差异。前期程序过程频发，项目时间计划不落墙。在这些背景下，需要保证大型车辆在每个版本上都能有一个线性的性能提升，并保持长期的稳定性。并且需要维护大量的数据、测试、版本、记录、流程来支撑跨部门的协作。是的，虽然简单来说，软件能跑在车上就更好了，但难度似乎不仅仅在于能跑好软件。作为一个软件算法工程师，感觉掌握核心技术就是台上的C位，这个逻辑没问题。但是每当遇到阻力的时候，一开始就是技术问题。如果你更深入地看，架构就有问题。解决了架构问题，你会发现软件工程跟不上，这就会上升到一个公司管理的问题。这一切都与人有关，与公司文化有关。虽然软件算法还是很重要的，但是一支在指挥、需求、硬件、架构、工程、软件算法、项目管理等方面能力一般的团队，才是有效战斗力的保障。作为一个软件算法项目，我觉得勇于用技术解决上下游算法和流程遇到的困难是一件好事。这种英雄气概是可贵的，但危难之时最好用，平时就忘掉。你会发现，对于任何一个问题，总有一个整体处理效率最高的环节。几百行代码解决不了的问题，上游模块可能一行代码稳定解决。如果在一个长期的项目上，你最终还是实现了一百行代码来解决这个问题，那就是噩梦的开始。可能等上游顺便解决了这个问题，你的代码就因为耦合变成了技术债。也有可能因为你的链接无法稳定解决，而你负责解决，稳定的压力和无所适从的压力就会压垮你。责任心是一种很好的品质，但大局观往往更重要。从一个成熟的系统来看，前台比后台更重要。问题越早解决越好，无论是算法中的前端感知模块，流程中的前端需求，前端测试构建，还是管理层的前端决策领导者。好的前端流程才能保证后端的质量，也能让后端有更多的时间和精力灵活解决突发问题。而一个不成熟的系统，就是前面轻，后面死。如果前端有失误，后端为了逐步消化这些问题，可能会导致结构混乱，节奏不平衡。到头来，就是一地鸡毛。一旦项目被替换，可能需要重新开始。人认真专业是不可能的，但是把认真专业的人部署到一线，效益会更好。工程化是量产的核心保障，保证了“功能实现”的健壮性、稳定性和一致性。从几个维度，我们可以对工程思路有一个初步的认识。从产品长期管理的角度来看，对于定期发布复杂产品的公司来说，往往是预研一代、研发一代、量产一代。各个功能块之间的协作背后也有一个工作流水线。产品管理最重要的是产品谱的管理，它揭示了公司发展的基本方向。当然，这需要良好的市场预测和高标准的执行力。从产品开发过程来看，汽车研发制造过程代表了制造开发过程的最高层次，其核心是提前进行APQP质量策划。简单来说，就是通过更加关注风险来弥补设计和生产过程中可能出现的故障。长期和多维的规划和风险评估是汽车工程师的常态。这种物理硬件的制造、组装和大规模生产与纯软件开发有很大不同。最大的区别是“变化周期”。涉及人和物体的工作不能突破物理限制。工人们需要时间来熟悉装配线上不断变化的流程。制造新零件需要重新设计模具和夹具。这些变化并不快，至少比起用GIT重新整合一个版本的软件来说还不够快。因此，对长期风险的预测成为制造业区别于互联网的重要特征。虽然互联网思维下的敏捷开发看似与制造业的思维背道而驰，但我个人觉得它也有很强的工程思维支持。在敏捷开发下，架构仍然是核心。业内有一句话，我很喜欢。建筑是愿景与残酷现实（需求）的交汇点。Vision只能翻译成架构设计，不能翻译的叫fantasy，介于两者之间的位置就是敏捷开发的上限。敏捷只是把开发分为架构设计和详细设计。敏捷的是详细设计，支撑敏捷的还是有长远预期的架构设计。在这一点上，制造和互联网的思路还是一样的，只是规避的风险不同。敏捷开发往往是靠关键软件模块的平台定义带来的，而不是日夜堆砌工程师的排挤。两者的边际效应差别很大。从人员管理的角度来看，团队梯度的建立、岗位AB角的设置、团队能力的平衡等最基本的东西，保证了项目人员管理的有序和稳定。为一个项目和一项复杂的任务保留70%-80%的人力资源是安全的。贸然增加人力资源可能会产生通过“人海战术”解决问题的想法，这对工程来说是不利的。综上所述，无论是制造硬件，还是互联网软件，工程的思路往往是趋同的。充分预测长期变量（架构、制造和人员），构建系统，构建结构，并制作工具来自动化一切可以标准化和平台化的东西。为短周期变量（用户需求、软件算法、功能应用）的快速迭代提供质量保证，这就是工程。
