问题管理基础概念

各位同学，今天我们聊聊问题管理里最基础、也最容易混淆的两个概念——问题（Problem）和缺陷（Bug）。

我在项目评审时经常发现，团队把这两个词混着用。有人报告说「发现一个Bug」，结果一查是需求没写清楚。也有人把真正的代码缺陷当成「问题」挂在那里，几个月没人管。嗯，这里得先理清楚。

问题（Problem）与缺陷（Bug）的区别

说白了，问题是因，缺陷是果。我个人的理解是这样的：

• 问题（Problem）：任何偏离预期、需要关注或解决的状况。它可能来自需求、设计、测试、生产、甚至客户投诉。
• 缺陷（Bug）：特指产品实现中存在的错误，比如代码写错了、设计遗漏了、配置搞反了。

举个例子。我在一个ADAS项目中遇到过：测试发现「车辆在雨天识别行人失败」。这是一个问题报告。但深入分析后发现，根本原因是算法模型在低光照条件下漏检——这才是缺陷。你想想看，如果只把「雨天识别失败」当成Bug去修，可能修了表面，根因还在。

在ASPICE流程里，问题管理覆盖的范围更广。缺陷只是问题的一种特殊类型。我建议团队在工具里把这两个字段分开：一个叫「问题类型」，下拉选「缺陷/需求变更/流程问题/外部依赖」等。这样统计时一目了然。

问题报告（Problem Report）的要素

一份合格的问题报告，应该让接手的人不用再追问「你当时到底看到了什么」。我曾经吃过这个亏——有次收到一份报告，只写了「系统崩溃」，没有日志、没有复现步骤、没有环境信息。我花了三天才定位到是某个内存泄漏。从那以后，我强制团队用模板。

一份标准的问题报告，至少包含以下要素：

要素	说明	示例
问题ID	唯一标识	PR-2025-0042
标题	简明扼要描述现象	雨夜场景下AEB误触发
发现阶段	需求/设计/编码/测试/生产	系统集成测试
严重等级	致命/严重/一般/轻微	严重
优先级	立即/高/中/低	高
环境信息	硬件版本、软件版本、配置	VCU v2.1, 固件20250301
复现步骤	1,2,3... 可操作	1. 设置雨天模式 2. 车速40km/h 3. 行人从右侧出现
实际结果	发生了什么	车辆紧急制动，无碰撞风险
预期结果	应该发生什么	系统报警但不制动
附件	日志、截图、视频	log_20250301_1532.bin
报告人	姓名+日期	张三 2025-03-01

问题生命周期状态机

问题不是一成不变的。它从被发现到最终关闭，会经历一系列状态。我见过很多团队只用「打开/关闭」两个状态，结果问题到底修没修、验证没验证，全靠口头沟通。这在ASPICE审核里是过不去的。

一个典型的问题生命周期状态机如下：

状态机（简化版）：
[新建] → [已确认] → [分析中] → [已修复] → [验证中] → [已关闭]
   ↑          |            |           |           |
   |          ↓            ↓           ↓           ↓
   |       [拒绝]      [需更多信息]  [重新打开]  [延期关闭]
   |          |            |           |
   └──────────┴────────────┴───────────┘

每个状态的含义：

• 新建：问题刚被提交，还没人看过。我建议24小时内必须有人确认。
• 已确认：问题被接受，确实是需要处理的问题。不是误报。
• 分析中：正在找根因。这个阶段可能会标记「需更多信息」——比如复现不了，需要报告人补充。
• 已修复：代码或设计已修改。注意，不是修了就完事，还要等验证。
• 验证中：测试人员或报告人确认修复是否有效。
• 已关闭：验证通过，问题终结。

另外，状态机里还有两个特殊路径：

• 拒绝：确认不是问题，比如用户操作错误。需要写明拒绝理由。
• 重新打开：验证不通过，或者问题再次出现。状态回到「分析中」或「已确认」。

为什么要有这么细的状态？你想想看，在ASPICE的审核中，审核员会抽查几个问题，看它们的生命周期是否完整。如果发现「已关闭」的问题没有验证记录，直接开不符合项。我经历过一次，从那以后老老实实把状态机做完整。

下一节我们会讲问题管理的角色与职责，包括谁负责分析、谁负责修复、谁负责验证。这些角色定清楚了，流程才能跑起来。