1、关于复杂汽车软件bug管理的简单思考和探索项目逐渐上线，最近我又深陷在bug中，不能自拔.这种不能自拔有两层意思，第层是琲以自拔，因为尤其在后期，大多数人的大多数精力都集中在bug上，写bug,测bug,分bug,数bug,解bug,而第二层是不愿自拔，毕竟，追若条理分明的bug去做事，相对简单，也相对体现价值如果要问，现如今的汽车软件项目的top5关健词是哪些？其中，必然少不了bug,甚至在项目中后期，说bug牵引着项目的运转，都不算过分.这篇文章会做一个简单思考和探索。1最好的过程bug管理虽然不能自拔，但从研发管理的角度，我对bug的评价和印象都还算不错，bug的管理基本算是目前汽车软件
2、开发过程的最好典型，无论是过程规范度上，还是数字化程度上，或者协同合作度上。总结下来，原因大抵有以下3个：1.1 前景效应与软件增多前景效应是一种行为心理学模型，就是说大多数人面对获利时是风险规逑的，所谓落袋为安，见好就收.对于bug,早期规范管理、优化设计及测试前移可能会降低后期bug的发生概率，这是潜在的获利，但不做这些活动就能立马减少工作员和加快交付速度，这是明确的获利.也就是说，对比当下明确的获利和未来即使更多的潜在获利，大家还是倾向于前者，这在当下这种“长期主义者”有可能活不过今年的内卷环境里，尤其如此。自然而然，bug会在中后期暴露不少.此外，汽车上的软件越来越多，软件bug也自然
3、越来越多,体现在实际项目中数量也是非常明显的，以前传统ECU的开发，量产交付时，bug清零似乎是一个常规要求，但现在，遗留几十、几百、上千的bug逐渐成为不可避免的常态。大:的bug就为bug管理提供了充足的原料1.2 汽车软件bug很复杂汽车软件不是单一的，bug经常也就不是单一问题.尤其在如今各种跨模块、跨系统、跨域功能定义的架构卜.，一个bug可能是多个ECU共同造成的，至少需要调查多个EeU之后才能有定论。即便聚焦到一个EQ还会分多个软件模块，仍然需要层层分析。此外，汽车软件有时涉及的不单是软件问题，还会有来自见送、标定、硬件甚至机械结构的耦合影响。这种技术复杂性又给了好好管理bug的
4、必要性.1.3 汽车软件bug涉众多bug的复杂主要是技术层面的复杂，技术复杂的传化方式就是打散与拆分，但拆分后一定会涉及到众多的人，众多不同职能的人.诸如工程、质量、生产、市场等，不同职能就会有不同立场，不同立场就会将技术问题推波助澜为政治问题，而一旦成为政治问题，如何解决就有了多种思路。这种涉众复杂性维埃给bugJIi畅流转与信息透明提出了要求.这是汽车软件bug管理目前的背景，似乎被迫促成了bug管理成为一个比较好的典范。但是，这不妨用bug依然是开发的痛点，所以，我们仍然有必要继续深入探讨一些优化的方向。2prob1.e与bug考虑到以上所讲的汽车软件的特点，我们可以尝试另外一种更系统
5、化且更精细化的思路。首先，我们先建立两个概念：prob1.em（问题）与bug（缺陷）PrOb1.ea是指3七发生了与覆期不符合的行为，面向项目、面向系统、面向整车、面向发现问题者，还处于汽车管理罐度.bug是指技术层面的偏差，面向组件、面向子系统、面向软件、面向解决问题者，已经落于软件工程维度.bug作为细化了项来服务于粗化的父项prob1.em,二者可以是n对n的关系。这种拆分至少有3个好处，主要体现在解耦上:将造车与软件解，让学科爱杂的造车活动与学科雌纯的软件无不干涉。将管理与工程解箱，让心思豆杂的管理者与心思单纯的工幽各司其职。将软件与软件解耦，让负责不同软件但都与这个prob1.em
6、相关的人员并行推进（有时也涉及慨件等）。当然，这种拆分也是有前提的:组织足够大prob1.a足够复杂角色拆分足够的Aui工具足够友好如果只是解决一个小开发团队自己测试发现的问题，去区分ProbIem与bug的意义就弱了很多。3有一天，prob1.em了理论上，所有人都可能遇到与预期不符的产品表现，例行测试自然会遇到，开发、5佥收、试驾、生产、售后等环节也都会，相应地，所有发现问题的人都可以去提prob1.em.当然，基于项H经脸，基本会集中在PM、测试这两类领外面问题和提内部问题的角色上.还要注意，prob1.ee的提出还要尽量满足两个原则：发粒度要大（涵藁范围广）、视角要面向价值，以避免提出
7、太多琐碎且信息至复的小问题，让人陷入这问题战争的汪洋大海中，prob1.em的存在就是要具备牵引作用，这在如今功能与问题都多的座舱类产品里颇有必要，种思路是面向大的feature来识别PrOb1.enU当问题需要提出时，其具体内容的撰写及流转也并不容易，般至少要反映如下基础内容：问题整体描述:这多少有点考验的文功底，最好一句话能说完，而I1.仅从句话中能理解应该怎么样实际仁么样，也就是准确的问题点是什么.基本原则是描述便于在组织内、项目内传递.问题发生组织:现在很多汽车软件都是多方瞄组织协同开发的，如果站在供应徒的维度看一个豆杂问题，就有必要知道问题所处的组织层级，是主机厂，是Ier1.,是第
8、三方软件，还是芯片，或者软件平台提供方。当问题肾组以时，往往会涉及不同的it程体系要求.问目!发现阶段：这个是从V链条的角度看的，看问题是在从代码到整车价后的整个开发周期中的哪个阶段，不同阶段的问题自然面对不同的相关方，也有不同的处理策略问题等级：通常,我们可以从产品本身严重度（如涉及法规、政治、功能安全、客户高抱怨的都算比较严重）和项目推进的时间优先S1.这两个视角来评价等级，但实际判断时基本是糅合在一起的，高严重度问题经常也就是高优先级.一般会有35个级别划分，这在统一组限沟通语言和标准化流程上多有禅益.比如，不同严重度的问题需要不同的分析反馈周期。责任方：责任方可以区分为团队和个人两个颗
9、粒度，团队责任方用于团队绩效整体评价或者打包管理，个人货任方是一个问题具体推进的负货人。因为PrOb1.Cm经常面向交付,所以由PM类角色主要负贵是一种选择时间信息：各类时间要求或时间微对于定义问题目标和分析问题都有帮助，般有截止日期、计划日期,发生日期,提出日期等等。辅助信息：对于PmPIem,点放在提出上，点也就是讲清整、讲完整，除了常规的预期结果、实际结果、发生环境、软硬件版本信息，还可以提供整车表现或模式（如仪表灯、电源模武等）。另外，总线或ECU内部的日志数据以及视频、录音、照片也都是后续分析的重五资札分析与解决信息：针对个prob1.em,整体的分析情况和最终结论当然也是关使信息，
10、可能分析后认为不是ProbIen）要拒绝，或者虽然是PrObIem但可以偏差许可，再或者确实是PrOb1.em也需要修复。无论如何，都要有较为明确的书面记录。状态变更：ProbIem的状态没必要设置得非常复杂，整体分为新建、分析中、so1.U1.ion已获取、so1.Ution已导入、已关闭这几大类即可。其他驱动：在汽车行业，有时候也会驱动出8D、吧财、1.1.s等其他工作，具体要视prob1.em本身的道要性与更杂性来决定。总体来说，我们可以把Prob1.e视为与汽车软件有关的问题，例于通过管理的手段解决汽车或者说系统的问题，4从prob1.进入bug当系统性问题prob1.em被提出后，就
11、非常需要系统架构师、系统工程师、软件专家或者具备系统知识经验的角色对其进行初步分析和任务分配.当然，有时将prob1.em第分析人交给受直接影响的某具体软件模块或featureowner,或许效率会更高.而具体的分析与分配结果就可以通过一到多个bug来体现，bug就会开始作为子项服务父项PrOP1.e的解决，从这里开始真正进入软件bug的解决在这里.，有时候也需要聘己有的其他bug与ProbIem建立联系，以聚拢问即与资从提出者来对比，prob1.e属于问题发现者提出，bug则为问题（缺陷）解决者提出.此外，在bug的具体推进上，除了和PrObIem类似的信息类别，bug需要在rootCaUS
12、e分析与SOIUtion识别上着墨更多，也要更技术、更软件、更翔实，包括但不限如下内容：缺陷产生的细节：什么状态机阶段、什么模式、舞个配、什么特定手噬例、连背了哪一条需求或设计要求以及底层技术机理是什么缺陷影响到的工件：诸如软件组件、各类文件版本等，这些都属于缺陷的一部分，都需要统一维护并服务于PrOb1.ea的关闭.缺陷带来的彩响：评估的维度可能包括法规、安全、功能、下游涌试、产线下线、消费者抱怨以及相关项目或产品线等，尽管这块内容本身不算那么软件，但只有深入到定的软件技术深度，才能对影响有较深的理解，这些内容也将决定PrOb1.em的应对策略，所以，在bug分析阶段，更high-1.eve
13、1.的系统层级角色仍然需要参与或提供信息临时与长期措施：面临项目或下游客户的压力，有时需要给出临时的权宜之计，或者叫临时措施，以解决当下交样、造车、浦试等紧急需求.陂后，在相对宽裕的时间里再完成长期措施的导入.缺陷验证情况：验证方式、测试用例、测试结果等相关信息也应有所体现，以明确缺陷确实被修复.缺陷引入阶段：这部分信息算是羟验复盘.识别出到底是需求没澄清，还是设计不合理，或者程序员码代码信心,又或者是平台问题的传递，这都有助于后续的持续改善,详细风险评估：如果该bug面向的ProbIem很严也且无法及时修复集成，详细的风险评估或许是必要的，这可能会涉及到FMEA的详细评估、PPM的计鸵、特定
14、用例的测试等等。状态变更：不同于ProbICm,bug的状态可以更软件些，通常可以按照软件开发的过程来标记，比如，新建、分析中、rootCaUSe已根别、编码中、代码评审、己集成、己潴试、己关闭等.当所有子项bug被关闭后，父项Prob1.Cin就可以被关闭交付了。5可能的挑战挑战无处不在，对于以上的想法，在如今的现实中，我们更可能面临如下挑战：问题太多，没有精力去进行这类层级横理.项目案急，没有时间去做这种规落掾作.产品复杂，没有能力整体分析PrObIe的定义及与bug的关系.信息杂乱，没有渠道串联对齐各级信息问题简单，没有必要搞这么复杂.6设想一个场景面对此间种种挑战，我们可以多想步。当然
15、也不局限在PrObICm或bug上f,我们设想一个理想的、包含bug管理在内的汽车软件开发场加：匿过精心研究的客户需求形成统一的整车feature.整车软件feature与其他feature从管理上解耦.整车软件feature与各域、各子系统、各ECU通过各级sub-feature串联各sub-feature与各域、各子系统、各ECU形成准确映射关系.各prob1.em面向各feature*各bug面向ECU中的软件nodu1.e.以上内容形成多个平台，各车型或各项目从这个维护良好的“绿色”与“透明”的平台上衍生奔放分支,7写在量后在如今汽车向软件转型的过程中，bug是个歪头戏，大家没得抓的时候，就抓bug,不知道该怎么办了，还是抓bug,多少有些无奈刘清
