如果软件开发的伊始目标就是为了演示或是纯粹做个玩具，我并不反感甚至认可“明天就要”的开发方式，因为敏捷高效成本低。但奈何我们选择了汽车这个产品品类，这几乎就是软件开发的地狱模式。很多三观是需要被颠覆的。
曾经作为一个软件算法工程师，能够让软件在车上跑的好，就是唯一的目标。这个目标逻辑上没有问题，但量产是什么概念，是多个项目并行开发；人员严重短缺，关键人员随时放鸽子；需求变化快还存在大量差异。前序流程频发状况，项目时间计划后墙不倒。在这些背景，要保证大规模车辆，在每个版本上都能够有线性的性能提升，还要维持长周期下的稳定性。并且要维持大量的数据、测试、版本、记录、流程以支持跨部门的合作配合。对，虽然简单说还是软件在车上跑的好，但难点似乎不仅仅在能够跑的好的软件上。
曾经作为一个软件算法工程师，觉得掌握了核心技术是舞台上的C位，这个逻辑上也没问题。可是但凡你碰到一些阻力，一开始都是技术点的问题，深入看是架构出了问题，解决了架构问题，会发现软件工程化跟不上，而这又会上升到公司管理问题而最终都是人的问题是公司文化的问题。虽然说软件算法还是很重要，但是一个在指挥、需求、硬件、架构、工程化、软件算法、项目管理上能力平均的团队才是有效战斗力的保障。
曾经作为一个软件算法工程，觉得勇于担当是好事，要竟可能的用技术解决上下游算法和流程碰到的苦难。这种英雄主义思想是宝贵的，但最好在危难的时候拿出来用，平时就算了。你会发现任何问题总有处理它整体效益最好的环节，你上百行代码解决不好的问题，上游模块可能1行代码就稳定解决了。如果在一个长期项目上，你最后仍然实施了百行代码去解决这个问题，那就是噩梦的开始。可能当上游顺便解决了这个问题，而你的代码却因为耦合性沦为技术债。也有可能由于你的环节无法稳定解决，但又由你负责解决，则稳定性的压力和无所适从就会压垮你。担当是好的品质，但是全局观往往更重要。
从一个成熟系统上看，都是前道重，后道轻。问题的解决越靠前越好，无论是算法上的前道感知模块，还是流程上的前道需求或是前道测试搭建，亦或是管理上领导的前道决策。良好的前道工序才能保证后道的品质，也为后道留出更多时间和精力灵活解决意料外的问题。而一个非成熟的系统，是前道轻，后道死。前道如果出现纰漏，后道为了逐级消化这些问题，就可能导致架构的混乱和节奏的失调，最终就是一地鸡毛，一旦更换项目可能就是重头再来。人不可能都很认真和专业，但认真和专业的人部署到前道，收益会更好。
工程化是量产的核心保障，其确保了“功能实现”的鲁棒性、稳定性和一致性。从几个维度我们能够初步了解工程化的点滴思想。
从产品长周期管理的角度来说，对于定期要发布复杂产品的公司来说，往往都是预研一代，研发一代，量产一代，各个职能块之间的配合，背后也有一个工作的流水线，而产品管理最重要的就是产品型谱的管理，这揭示了公司发展的基本方向。当然这需要很好的市场预判以及高标准的执行力。
从产品开发流程的角度看，汽车研发制造流程代表了制造业开发流程的最高水平，其核心就是APQP质量先期策划。简单来说，就是通过对风险的更多关注，来补偿设计生产过程中可能出现的失败。长期而多维度的计划与风险评估是汽车工程师的常态。这种物理硬件的制造，组装和大规模生产和纯粹的软件开发差异很大。最大的区别就是“变化周期”。有人和实体物参与的工作，都无法突破物理限制，工人在流水线上变更工艺，需要时间熟悉，制造新的零件需要重新设计模具和夹具，这些变化并不快，至少相对GIT重新集成一版软件来说并不快。因此对长周期风险的预判成了区别制造业和互联网的一个重要特征。
互联网思维下的敏捷开发，虽然读上去感觉和制造业的思路背道而驰，但个人感觉其同样有浓厚的工程化思维支持。在敏捷开发下，架构仍然是核心。行业有一句话我非常喜欢，架构是远景与残酷现实(需求)的黎明交汇。愿景只能是被翻译成架构设计的那些内容，无法被翻译的叫幻想，两者之间的位置是敏捷开发的上限。敏捷只不过开发分成了架构设计和细节设计。敏捷的是细节设计，而支持敏捷的仍然是具有长周期预判的架构设计。在这点上制造业和互联网的思想仍然是一样的，只不过规避了不同的风险。敏捷开发往往是软件关键模组的平台化定义所带来的，而不是堆砌工程师没日没夜的推倒重来压榨出来的，两者的边际效应天差地别。
从人员管理上来说，最基本的诸如团队梯度的搭建，岗位AB角的设置以及团队能力的平衡，保证项目人员管理的有序、稳定。往往一个项目一个复杂工作，维持70%-80%的人力资源是稳妥的，贸然增加人力资源，可能导致通过“人海战术”解决问题的思想出现，这对于工程化是不利的。
综上所述，无论是制造业的硬件还是互联网的软件，工程化的思路往往是殊途同归。对长周期的变量（架构，制造，人）给予充分的预判，建体系，搭架构，做工具把一切可以标准化，平台化的东西自动化。为短周期变量（用户需求，软件算法，功能应用）的快速迭代提供质量保障，这就是工程化。
