关于复杂汽车软件bug管理的简单思考和探索

项目逐渐上线，最近我又深陷在bug中，不能自拔。

这种不能自拔有两层意思，第一层是难以自拔，因为尤其在后期，大多数人的大多数精力都集中在bug上，写bug，测bug，分bug，数bug，解bug，而第二层是不愿自拔，毕竟，追着条理分明的bug去做事，相对简单，也相对体现价值......

如果要问，现如今的汽车软件项目的top 5关键词是哪些？其中，必然少不了bug，甚至在项目中后期，说bug牵引着项目的运转，都不算过分。

这篇文章会做一个简单思考和探索。

1

最好的过程——bug管理

虽然不能自拔，但从研发管理的角度，我对bug的评价和印象都还算不错，bug的管理基本算是目前汽车软件开发过程的最好典型，无论是过程规范度上，还是数字化程度上，或者协同合作度上。

总结下来，原因大抵有以下3个：

1.1 前景效应与软件增多

前景效应是一种行为心理学模型，就是说大多数人面对获利时是风险规避的，所谓落袋为安，见好就收。

对于bug，早期规范管理、优化设计及测试前移可能会降低后期bug的发生概率，这是潜在的获利，但不做这些活动就能立马减少工作量和加快交付速度，这是明确的获利。

也就是说，对比当下明确的获利和未来即便更多的潜在获利，大家还是倾向于前者，这在当下这种“长期主义者”有可能活不过今年的内卷环境里，尤其如此。自然而然，bug会在中后期暴露不少。

此外，汽车上的软件越来越多，软件bug也自然越来越多，体现在实际项目中数量也是非常明显的，以前传统ECU的开发，量产交付时，bug清零似乎是一个常规要求，但现在，遗留几十、几百、上千的bug逐渐成为不可避免的常态。

大量的bug就为bug管理提供了充足的原料。

1.2 汽车软件bug很复杂

汽车软件不是单一的，bug经常也就不是单一问题，尤其在如今各种跨模块、跨系统、跨域功能定义的架构下，一个bug可能是多个ECU共同造成的，至少需要调查多个ECU之后才能有定论。

即便聚焦到一个ECU，还会分多个软件模块，仍然需要层层分析。此外，汽车软件有时涉及的不单是软件问题，还会有来自算法、标定、硬件甚至机械结构的耦合影响。

这种技术复杂性又给了好好管理bug的必要性。

1.3 汽车软件bug涉众多

bug的复杂主要是技术层面的复杂，技术复杂的简化方式就是打散与拆分，但拆分后一定会涉及到众多的人，众多不同职能的人。

诸如工程、质量、生产、市场等，不同职能就会有不同立场，不同立场就会将技术问题推波助澜为政治问题，而一旦成为政治问题，如何解决就有了多种思路。

这种涉众复杂性继续给bug顺畅流转与信息透明提出了要求。

这是汽车软件bug管理目前的背景，似乎被迫促成了bug管理成为一个比较好的典范。

但是，这不妨碍bug依然是开发的痛点，所以，我们仍然有必要继续深入探讨一些优化的方向。

2

problem与bug

考虑到以上所讲的汽车软件的特点，我们可以尝试另外一种更系统化且更精细化的思路。

首先，我们先建立两个概念：problem（问题）与bug（缺陷）。

probIem是指产品发生了与预期不符合的行为，面向项目、面向系统、面向整车、面向发现问题者，还处于汽车管理维度。

bug是指技术层面的偏差，面向组件、面向子系统、面向软件、面向解决问题者，已经落于软件工程维度。

bug作为细化子项来服务于粗化的父项problem，二者可以是n对n的关系。

这种拆分至少有3个好处，主要体现在解耦上：

将造车与软件解耦，让学科复杂的造车活动与学科单纯的软件互不干涉。

将管理与工程解耦，让心思复杂的管理者与心思单纯的工程师各司其职。

将软件与软件解耦，让负责不同软件但都与这个problem相关的人员并行推进（有时也涉及硬件等）。

当然，这种拆分也是有前提的：

组织足够大

problem足够复杂

角色拆分足够细

ALM工具足够友好

如果只是解决一个小开发团队自己测试发现的问题，去区分problem与bug的意义就弱了很多。

3

有一天，problem发生了......

理论上，所有人都可能遇到与预期不符的产品表现，例行测试自然会遇到，开发、验收、试驾、生产、售后等环节也都会，相应地，所有发现问题的人都可以去提problem。

当然，基于项目经验，基本会集中在PM、测试这两类领外面问题和提内部问题的角色上。

还要注意，problem 的提出还要尽量满足两个原则：颗粒度要大（涵盖范围广）、视角要面向价值，以避免提出太多琐碎且信息重复的小问题，让人陷入这问题战争的汪洋大海中，problem的存在就是要具备牵引作用，这在如今功能与问题都多的座舱类产品里颇有必要，一种思路是面向大的feature来识别problem。

当问题需要提出时，其具体内容的撰写及流转也并不容易，一般至少要反映如下基础内容：

问题整体描述：这多少有点考验语文功底，最好一句话能说完，而且仅从一句话中能理解应该怎么样实际怎么样，也就是准确的问题点是什么。基本原则是描述便于在组织内、项目内传递。

问题发生组织：现在很多汽车软件都是多方跨组织协同开发的，如果站在供应链的维度看一个复杂问题，就有必要知道问题所处的组织层级，是主机厂，是Ter1，是第三方软件，还是芯片，或者软件平台提供方。当问题跨组织时，往往会涉及不同的流程体系要求。

问题发现阶段：这个是从V链条的角度看的，看问题是在从代码到整车售后的整个开发周期中的哪个阶段，不同阶段的问题自然面对不同的相关方，也有不同的处理策略。

问题等级：通常，我们可以从产品本身严重度（如涉及法规、政治、功能安全、客户高抱怨的都算比较严重）和项目推进的时间优先级这两个视角来评价等级，但实际判断时基本是糅合在一起的，高严重度问题经常也就是高优先级。一般会有3~5个级别划分，这在统一组织沟通语言和标准化流程上多有裨益。比如，不同严重度的问题需要不同的分析反馈周期。

责任方：责任方可以区分为团队和个人两个颗粒度，团队责任方用于团队绩效整体评价或者打包管理，个人责任方是一个问题具体推进的负责人。因为problem经常面向交付，所以由PM类角色主要负责是一种选择。

时间信息：各类时间要求或时间戳对于定义问题目标和分析问题都有帮助，一般有截止日期、计划日期，发生日期，提出日期等等。

辅助信息：对于proplem，重点放在提出上，重点也就是讲清楚、讲完整，除了常规的预期结果、实际结果、发生环境、软硬件版本信息，还可以提供整车表现或模式（如仪表灯、电源模式等）。另外，总线或ECU内部的日志数据以及视频、录音、照片也都是后续分析的重要资料。

分析与解决信息：针对一个problem，整体的分析情况和最终结论当然也是关键信息，可能分析后认为不是problem要拒绝，或者虽然是 problem但可以偏差许可，再或者确实是problem也需要修复。无论如何，都要有较为明确的书面记录。

状态变更：problem的状态没必要设置得非常复杂，整体分为新建、分析中、solution已获取、solution已导入、已关闭这几大类即可。

其他驱动：在汽车行业，有时候也会驱动出8D、DFMEA、LLs等其他工作，具体要视problem本身的重要性与复杂性来决定。

总体来说，我们可以把problem视为与汽车软件有关的问题，侧重于通过管理的手段解决汽车或者说系统的问题。

4

从problem进入bug

当系统性问题problem被提出后，就非常需要系统架构师、系统工程师、软件专家或者具备系统知识经验的角色对其进行初步分析和任务分配。

当然，有时将problem第一分析人交给受直接影响的某具体软件模块或feature owner，或许效率会更高。

而具体的分析与分配结果就可以通过一到多个bug 来体现，bug就会开始作为子项服务父项proplem的解决，从这里开始真正进入软件bug的解决。在这里，有时候也需要将已有的其他bug与problem建立联系，以聚拢问题与资源。

从提出者来对比，problem属于问题发现者提出，bug则为问题（缺陷）解决者提出。

此外，在bug的具体推进上，除了和problem类似的信息类别，bug需要在root cause分析与solution识别上着墨更多，也要更技术、更软件、更翔实，包括但不限如下内容：

缺陷产生的细节：什么状态机阶段、什么模式、哪个配置、什么特定手顺用例、违背了哪一条需求或设计要求以及底层技术机理是什么......

缺陷影响到的工件：诸如软件组件、各类文件版本等，这些都属于缺陷的一部分，都需要统一维护并服务于problem的关闭。

缺陷带来的影响：评估的维度可能包括法规、安全、功能、下游测试、产线下线、消费者抱怨以及相关项目或产品线等，尽管这块内容本身不算那么软件，但只有深入到一定的软件技术深度，才能对影响有较深的理解，这些内容也将决定problem的应对策略，所以，在bug分析阶段，更high-level的系统层级角色仍然需要参与或提供信息。

临时与长期措施：面临项目或下游客户的压力，有时需要给出临时的权宜之计，或者叫临时措施，以解决当下交样、造车、测试等紧急需求。随后，在相对宽裕的时间里再完成长期措施的导入。

缺陷验证情况：验证方式、测试用例、测试结果等相关信息也应有所体现，以明确缺陷确实被修复。

缺陷引入阶段：这部分信息算是经验复盘，识别出到底是需求没澄清，还是设计不合理，或者程序员码代码粗心，又或者是平台问题的传递，这都有助于后续的持续改善。

详细风险评估：如果该bug面向的problem很严重且无法及时修复集成，详细的风险评估或许是必要的，这可能会涉及到FMEA的详细评估、PPM的计算、特定用例的测试等等。

状态变更：不同于problem，bug的状态可以更软件些，通常可以按照软件开发的过程来标记，比如，新建、分析中、root cause已识别、编码中、代码评审、已集成、已测试、已关闭等。

当所有子项 bug被关闭后，父项problem就可以被关闭交付了。

5

可能的挑战

挑战无处不在，对于以上的想法，在如今的现实中，我们更可能面临如下挑战：

问题太多，没有精力去进行这类层级梳理。

项目紧急，没有时间去做这种规范操作。

产品复杂，没有能力整体分析problem的定义及与bug的关系。

信息杂乱，没有渠道串联对齐各级信息。

问题简单，没有必要搞这么复杂。

6

设想一个场景

面对此间种种挑战，我们可以多想一步。当然，也不局限在problem或bug上了，我们设想一个理想的、包含bug管理在内的汽车软件开发场景：

经过精心研究的客户需求形成统一的整车feature。

整车软件feature与其他feature从管理上解耦。

整车软件feature与各域、各子系统、各ECU通过各级sub-feature串联。

各sub-feature与各域、各子系统、各ECU形成准确映射关系。

各problem面向各feature。

各bug面向ECU中的软件module。

以上内容形成多个平台，各车型或各项目从这个维护良好的“绿色”与“透明”的平台上衍生释放分支。

7

写在最后

在如今汽车向软件转型的过程中，bug是个重头戏，大家没得抓的时候，就抓bug，不知道该怎么办了，还是抓bug，多少有些无奈......

审核编辑：刘清