跨职能问题管理
确保责任落实到底的问题跟踪软件
为产品、QA、支持和交付团队提供统一的工作记录：发生了什么、下一步由谁负责、哪些事项受阻，以及什么证据能够证明问题已经解决。
登录后可查看已填充的视图，再安装带示例数据的应用，以测试关联记录、决策和仪表板。
问题系统应清楚呈现什么
实用的问题跟踪软件不只是收集工单。它应保留原始报告，区分紧急程度与影响，明确下一项行动的责任人，记录例外情况，并将解决决策与其依据关联起来。
- 关联的问题、修复、验证和发布记录
- 原生分诊与验证决策
- 已填充的严重、受阻、重开和已完成示例
从信号到闭环
让每个问题经过六个责任明确的关键环节
记录会在团队之间流转，但上下文不应在每次交接时丢失。
记录
记录症状、受影响组件、版本、环境和证据。
澄清
退回信息不完整的报告，不凭空判断严重程度或指定负责人。
分诊
确认影响、紧急程度、重复情况、负责人和目标版本。
处理
针对指定的待测版本，持续跟踪诊断和修复进展。
验证
针对确切构建版本，结合测试证据判定通过、失败或受阻。
解决
关闭、重新打开，或将已知风险纳入发布决策。
面向不同决策的视图
让每个角色看到自己能够处理的队列
共享数据库只有在报告人、负责人、QA 和发布负责人都能看到自己的下一项决策时才真正有用。
分诊队列
包含足够决策信息的新报告、退回报告和重复报告。
负责人队列
按组件和目标版本分组的已分派及逾期修复。
QA 队列
待测试候选版本、失败检查和受阻环境。
发布视图
严重阻断项、待验证事项和已接受的已知风险。
选择合适的工作流
区分软件缺陷、一般任务、项目风险和质量事件
问题跟踪与多种工作流有所重叠，但所管理的对象和要做的决策并不相同。
| 需要管理的工作 | 最适合的工作流 | 适用边界 |
|---|---|---|
| 从软件问题发现到验证 | 缺陷跟踪软件 | 必须确认问题可复现，并记录待测版本和 QA 验证结果。 |
| 一般分派工作 | 任务管理软件 | 不需要复现信息或发布证据。 |
| 项目交付风险 | 项目问题跟踪器 | 由项目计划和里程碑结果负责。 |
| CAPA 或不合格项 | 质量管理软件 | 由受控质量与法规记录管理。 |
问题与适用边界
团队在落地问题跟踪前常问的问题
以下回答说明系统适用于哪些场景，以及如何避免形成无人负责的工单积压。
问题跟踪与任务管理有什么区别？
问题始于已观察到的故障或例外，通常需要分类、证据和解决决策；任务则是已经明确并分派的工作。Jodoo 可以关联两者，而不必强迫每项任务都经过缺陷分诊。
支持、产品和 QA 团队可以共用一条问题记录吗？
可以。将原始报告和业务背景保留在问题记录中，再把技术修复和验证作为独立记录关联起来。这样各团队可以负责自己的部分，又不会互相覆盖信息。
应如何处理重新打开的问题？
保留此前的修复与验证历史，记录失败的构建版本和证据，再将问题重新交回当前负责人。不要删除先前的决策。
Jodoo 会取代 Git 托管平台或自动化测试吗？
不会。Jodoo 负责协调生命周期中的记录、交接、证据和决策。代码、提交、CI 结果和测试产物可以关联或集成，但此应用不宣称提供原生代码仓库或测试执行能力。
从已填充的工作模型开始
重建现有跟踪器之前，先查看完整生命周期
打开示例应用，了解报告、分诊、修复、验证和发布决策如何保持关联。