搭建车载软件研发数字化管理系统，这3个坑你可能爬不出来

对于一个现代化的企业来说，数字化管理系统非常重要。

将范围缩小到汽车行业，企业的数字化管理系统大致包含了ERP（人力、资源、财务、供应商等）、MESS（生产制造）、PLM（BOM、PDM、供应商管理，有形的硬件产品生命周期）和ALM（需求管理、测试管理、bug管理，无形的软件产品生命周期管理）。

一些汽车行业的企业，在搭建自身的车载软件研发数字化管理系统中，存在的一些误区，以及可能导致的一些风险。

1. 过于关注单点问题的高效解决，而忽视了整体流程的高效管理

2. 高估了流程的独特性，而低估了流程的通用性

3. 被动收集各类平台数据，形成“虚假”且“臃肿”的研发数字化管理系统

1 过于关注单点问题的高效解决，而忽视了整体流程的高效管理

有一次我去给一家企业讲解研发管理系统，客户是做电驱系统的架构设计与集成。我的讲述思路是，如何在满足汽车行业的三大法规标准（ASPICE、功能安全和信息安全）的情况下，实现从需求管理、开发任务管理、测试管理、项目管理、质量管理等流程的全打通。

我自以为讲解的还算比较充分，事实上也得到了对方实施这一计划的工程师认可，将我推给了其他正在创业的同事。

不过我也碰到了一些挑战，对方的负责人质疑说，整个系统是站在流程质量和项目管理的角度来设计的，对于工程师直接提高某一现有工序的效率，比如帮助需求工程师更快速地、自动化地生成需求，帮助测试工程师更快地生成自动化测试用例，或者更高效地扫描出代码缺陷等，则缺少效果。

这家公司拥有业界最优秀的汽车工程师。事实上，他们一方面能提供最佳的产品设计品味、最好的内外饰设计思路、富有竞争力的售后运维服务，但是却在研发和运营效率上有所拖累。内部系统和工具过多，数据传输效率低于同行。

在公司创业早期，人员冗余+强大的工程师个体，是一个优势，很容易通过赛马机制，使得某一方提前跑出来。但是当同行都推出车型之后，此时更考验不同团队的精细化管理和效率提升，庞大而臃肿的研发团队和研发数据，反而形成了太多噪音，成为拖累。

以车载软件开发为例，这是一个涉及多个环节的复杂过程，包括需求分析、系统设计、编码实现、测试验证、部署上线以及后续的维护和更新。如果管理者只关注测试用例的自动化，或者代码自动扫描，可能会导致以下几个问题：

1. 研发流程的瓶颈转移：即使测试用例的自动化提高了测试效率，但如果需求分析和设计阶段存在问题，可能会导致测试阶段频繁修改用例，反而增加了工作量。同时，如果代码实现阶段的质量控制不到位，可能会导致测试阶段发现大量问题，导致测试工作量激增，从而形成新的瓶颈。

（精益管理里面，有一个很经典的提高效率的例子。比如项目是“某五星级餐厅准备晚餐”，分析其流程包含了：确定菜品、app下单买菜、小哥送菜、洗菜、炒菜、上菜。这其中不仅涉及了像炒菜这种“工序”，还包含了炒菜和上菜这两道工具之间的交接时间。因此，为了提高整体的做饭效率，需要先调研每一个工序花费的时间，以及工序之间的交接时间，找到效率瓶颈，然后再逐点解决。可见，不仅仅是“工序”会成为效率瓶颈，工序与工序之间的“交接流程”本身，也可能成为效率瓶颈。）

2. 资源分配不均衡：过多的资源可能被分配到测试自动化上，而其他同样重要的环节，如需求分析的准确性、系统设计的合理性、代码的可读性和可维护性等，可能因资源不足而受到影响。

3. 产品质量风险：车载软件对安全性和稳定性的要求极高，如果开发流程中的某些环节被忽视，可能会导致软件在实际运行中出现严重的安全问题或稳定性问题。

4. 市场竞争力下降：如果因为开发流程中的问题导致产品上市延迟，或者产品质量不符合市场预期，可能会导致公司在激烈的市场竞争中失去优势。

5. 维护成本上升：在车载软件的后续维护阶段，如果因为前期开发流程的问题导致软件存在大量隐患，可能会导致维护成本大幅上升，甚至需要进行昂贵的召回。

因此，管理者应该采取一个更全面的视角，关注整个车载软件开发流程的每一个环节。

2 高估了流程的独特性，而低估了流程的通用性

这里也分享一个案例，这个案例来自于我和某车载团队一名测试leader的对话。

我和其讨论的话题是：如何更好地构建测试团队的管理工具，以提高软件测试团队的效率。他向我展示，在测试管理工具层方面，他的团队做了大量工具开发，形成了一个相对完善的测试管理系统，包含所有的测试用例、用例评审、测试计划、发版计划、执行结果回填等等。

1. 当我问他，整车需求和该团队的产品需求、开发任务，都存在于需求管理系统，测试用例如何和这些需求、开发任务做关联？----通过链接关联，双向点击可访问，已解决

2. 以及需求、开发人员是否能随时访问他的测试平台，以方便查看测试用例和结果？----局部可以开放权限，大部分人不行，因为这个平台是测试部门内部的平台

3. 其他测试部门是否也使用他的平台？----不使用，其他部门也会开发自己的测试管理平台

4. 为什么其他测试部门不使用他的平台，而需要自己独立开发？------因为每个部门的测试流程和使用习惯不同

5. 追溯性的统计，功能安全、信息安全流程如何支持？----暂时无法解决，也不考虑

6. 如果产品和开发很少能访问他们的测试工具，那如何才能让产品、开发、测试形成一个更高效的沟通机制？----

他有点犯难了，他认为那是整个大部门的事情，他这边没有办法干涉，也解决不了，所以他只能想尽办法让测试过程更高效，至于整体团队的效率，他难以推动

这位测试leader虽然意识到将测试管理平台，和需求、开发平台一体化管理，能提高效率，他却无法推动整个团队往一个平台上使劲儿和迁移。

即使他意识到，各个部门重复建立测试管理平台，是资源的大浪费，他也无法推动其他部门使用他的工具。

这不是工程师个人能力的问题，而是因为，这是企业一把手工程。

使用不同的测试平台，和各个部门测试流程的独特性有一定关系，但显然关系不大。

因为看了一遍他的系统，我们自己开发的MappingSpace系统，也能够在几乎不怎么调整的情况下，满足绝大部分功能。

换句话说，我们往往容易高估企业流程的独特性，而低估了企业流程的通用性。

这也是很多国内公司非常喜欢做定制化系统的原因。

宁愿摒弃一套行业通用的平台，也要找业余团队定制化开发，认为自己的流程非常独特。往高大上了讲，就是源码可见，自主可控，随时可调整。

不过深入分析里面的原因却很复杂，和国民性格、复杂的采购申请流程、对产品的认知、对乙方的信任、幕后交易都不无关联。但是，自研有很大风险。

一方面，部门之间的测试管理系统，差距肯定会越来越大，这样的测试平台，在诞生之初，就无需考虑设计的通用性。

另一方面，随着差距越来越大，再也无法做到统一，此时就进入了下一个状态——打通。请看下一个故事。

3 被动收集各类平台数据，形成“虚假”且“臃肿”的研发数字化管理系统

这个故事是我和整车部门的一位大项目管理的对话，这位PM的目标是开发整车项目管理的数字化平台。他自述是这个平台的第4代产品经理，因为前面三代产品经理都离职了，留下了一大堆还未完成的feature，他这个平台的目的是，将各个部门、各类工具上的研发数据汇总，建立追溯性，然后在这个平台上以更加可视化、结构化的方式显示出来，基于此来做更高效、更清晰的项目管理和质量管控。

我说那这个系统岂不是很复杂，因为他不仅要去和各个业务部门梳理业务数据，以判断这些数据分别属于什么类型，然后才能和自己做的这个平台的数据结构做匹配。而且这似乎只是一个“数据汇总平台”，离真正的研发流程管控还差了很远。

他表示同意，现阶段各个部门不同的工具平台都太多了，还有不少部门在线下管理，没有形成线上的数据，没有办法去做流程管控，只能先将业务数据汇总到这样一个平台上来，然后基于数据再去反推流程，针对异常数据或者无法提供数据的部门，再去各个击破。

这确实是一个很复杂、很繁琐的工程，而且我非常怀疑这个项目在第四代产品经理手上，能不能顺利完工。我对这个数据汇总平台，能产生多少效果，也有一些怀疑。

最终，我提了一个可能的方向：现在这种情况，有点像逆向工程。通过结果数据来反推过程。但是由于需要理清楚的过程涉及到太多不同的部门，以及部门之间的交互错综复杂，这是一个庞大得似乎看不到头的工程。有没有可能采用正向开发的模式，先找到一个大家都认可的开发流程，然后将已有的流程往这个正向开发的流程的方向去靠近，最终将大家的流程梳理到一个统一的平台上

总结

汽车行业的研发数字化系统搭建过程中，对于以下三点的考虑非常重要：

第一：要站在全局的角度设计。所谓的全局，应尽可能依赖汽车行业的标准和法规，减少后期逆向工程来满足法规的成本和代价。基于标准和法规，并不一定意味着繁琐，也可以裁剪，追求更快地开发速度。

第二：中大型企业的数字化研发系统设计，应尽可能让不同部门采用相似的流程，采用相同的工具。而不是每个部门采用一套工具，最终去打通数据流转，极易造成上述第二和第三个例子中的情况，从而拖累整体的研发数字化流程。

第三：单点效率很重要，但整体的流转流程更重要。使用精益管理的方法，逐个分解流程中涉及的“工序”和“交接”，各个击破，提高整个团队的协作效率。

END       

作者介绍：

       罗宇超，云体科技创始人，软件质量工程师，工具连接工程师

写在最后

推荐阅读：

◆智能驾驶产品开发中如何贯彻“正向开发”理念

◆智能驾驶“正规军”与“杂牌军”的关键区别：是否具备系统性思维

◆助力智驾出海 —— 从功能层面解读欧洲智驾法规

◆做“擦屁股”的多传感器融合，对开发者的意义是什么？

◆万字长文推演智能汽车EE架构的终极形态

◆那些相信了『软硬件解耦』的自动驾驶公司，大都被坑得很惨