项目问题管理要先把“问题”定义清楚：只收录影响项目推进的障碍，产品Bug归缺陷管理、服务中断归服务事件管理。然后建立一张问题台账，每条问题写清现象、影响、责任人、解决期限和当前状态；按影响程度分级，明确升级触发条件和升级对象；在例会中固定评审、更新和关闭，形成从提出、分派、处理、验证到关闭的闭环。
要点总览（TL;DR）
- 项目问题管理先划边界：只收录影响项目推进的障碍，产品Bug走缺陷管理，服务中断走服务事件管理。
- 台账必填问题编号、现象与影响、影响范围、优先级、单一责任人、解决期限和状态，按阻塞级、高、中、低四档分级。
- 日常按提出登记、分派确认、处理记录、验证关闭四步走，每步都有可检查的完成标志。
- 升级条件写清超期、影响扩大、跨团队协调无果、超出权限四类，按项目负责人、部门负责人、项目发起人逐级升级并回写结论。
- 按月核对台账完整性、更新及时性、责任落实、升级有效性和闭环率，重点修正反复超期和关闭缺验证的环节。
先划清边界：哪些事项进入项目问题台账
项目问题管理的第一步是划定收录范围。项目问题指已经发生、正在阻碍项目按计划推进的事项，例如关键资源迟迟不到位、跨部门接口人空缺、外部审批卡住里程碑、需求方决策延迟导致开发无法启动。判断标准可以归纳为一句话：这件事如果不解决，项目的某个交付节点、范围或质量目标就无法按当前计划达成。
把产品Bug和服务事件排除在外，是为了让每类事项走各自更合适的流程。产品Bug有复现步骤、严重等级和修复版本，适合在缺陷管理中跟踪；服务中断有响应时限、恢复目标和值班机制，适合在服务事件管理中处理。项目问题台账关注的是“项目推进中的障碍”，它的处理方式往往是协调资源、推动决策、调整计划，而非修改代码或恢复系统。
以下示例帮助判断收录边界：
| 事项 | 是否进入项目问题台账 | 判断依据 |
|---|---|---|
| 第三方接口文档延迟两周提供，联调无法开始 | 收录 | 外部依赖阻塞项目关键路径 |
| 登录页面在特定浏览器下报错 | 不收录，转缺陷管理 | 属于产品功能缺陷，有明确修复流程 |
| 生产环境数据库宕机两小时 | 不收录，转服务事件管理 | 属于服务中断，按事件响应流程处理 |
| 客户方项目负责人更换，验收标准需重新确认 | 收录 | 决策链变化影响验收节点 |
| 测试环境服务器磁盘不足 | 视情况收录 | 若已阻塞测试执行且需跨团队协调资源，则作为问题跟踪；日常运维扩容按运维流程处理 |
台账字段在建立初期就应固定下来，避免后续反复改表。建议的字段清单如下：问题编号、提出日期、提出人、问题描述（现象与影响）、影响范围、优先级、责任人、协办人、解决期限、当前状态、解决措施、验证结论、关闭日期。其中问题描述必须同时写清“发生了什么”和“影响了什么”，只写现象不写影响的问题，后续很难判断优先级。
建台账：字段、分级与责任落实
台账设计的关键是让每条问题都能被追问三个问题：谁负责、什么时候解决、现在到哪一步了。围绕这三点，字段分为必填和选填两类。
必填字段包括：问题编号（唯一且连续）、提出日期、提出人、问题描述（现象与影响）、影响范围（涉及哪些任务、里程碑或团队）、优先级、责任人（单一责任人，避免多人共同负责）、解决期限、当前状态。选填字段包括：协办人、关联任务或里程碑、升级记录、备注。协办人用于记录提供支持的角色，但责任仍由责任人承担。
影响程度分级建议采用四档，标准需在团队内统一并写入台账说明：
| 级别 | 判定标准 | 期限要求建议 |
|---|---|---|
| 阻塞级 | 已阻塞关键路径，当前里程碑无法按期达成 | 当日确认，最短期限内给出解决方案或升级 |
| 高 | 影响里程碑交付，但尚有缓冲时间 | 按里程碑倒排期限 |
| 中 | 影响单个任务或小组推进，不波及整体节点 | 在当周内处理 |
| 低 | 暂不影响交付，但需持续跟踪，防止恶化 | 纳入例行评审，按周更新 |
责任人的确定方式是“谁有能力推动解决，谁就是责任人”，而非“谁提出的谁负责”。责任人确认接收后，台账状态从“待确认”变为“已分派”。解决期限由责任人与项目负责人共同确认，不能由提出人单方面设定。状态取值建议统一为：待确认、已分派、处理中、待验证、已关闭、已挂起。挂起必须注明原因和恢复条件，例如“等待客户方确认验收标准，恢复条件为收到书面确认”。
状态流转规则要写清楚：待确认经分派后进入已分派；责任人开始处理后改为处理中；处理完成提交验证后进入待验证；验证通过后关闭；验证不通过退回处理中。每次状态变更都记录变更时间和操作人，便于后续复盘。
日常运转：提出、分派、处理与验证的操作步骤
问题管理的日常运转由四个步骤组成，每一步都有明确的输入、动作、输出和完成标志。
第一步：提出与登记。输入是发现障碍的场景信息。动作是提出人按台账字段填写问题描述、影响范围和期望解决时间。输出是一条状态为“待确认”的问题记录。完成标志是问题描述同时包含现象与影响，且影响范围指向具体的任务或里程碑。
第二步：分派与责任确认。输入是待确认的问题。动作是项目负责人在例会上或会后指定责任人，与责任人确认解决期限。输出是状态为“已分派”的记录，责任人和期限字段已填写。完成标志是责任人明确表示接收，而非默认接受。
第三步：处理过程记录。输入是已分派的问题。动作是责任人推进解决，在台账中更新进展、阻碍和下一步动作，需要协调时提出升级。输出是状态为“处理中”的记录及过程备注。完成标志是解决措施已执行完毕，问题具备可验证的条件。
第四步：解决验证与关闭。输入是处理完成的问题。动作由提出人或指定验证人确认障碍是否消除，例如接口文档是否已提供、决策是否已书面确认。输出是状态为“已关闭”的记录，包含验证结论和关闭日期。完成标志是验证人确认影响已消除，且相关任务或里程碑可以恢复推进。
这四个步骤在项目管理工具中承载时，台账对应工作项列表，状态取值对应工作流状态，责任人和期限对应字段配置，过程记录对应评论或活动日志。ONES 支持在工作项中配置自定义字段、状态流转和责任人分派，问题从提出到关闭的每次状态变更都会留下操作记录，便于例会上直接按状态筛选待确认、待验证和已超期的问题。具体字段和权限配置需按团队实际使用的项目模板核验。
升级机制：什么情况下升级、升级给谁
升级不是对责任人的否定，而是当问题超出责任人权限或处理能力时，把决策权交给更合适的人。升级触发条件应事先写清楚，常见的有四类：超过解决期限仍未处理；影响范围扩大到关键路径或新增受影响里程碑；跨团队协调无法达成一致；需要超出责任人权限的资源或预算决策。
升级路径按层级设置，每一级对应明确的角色和响应要求：
| 升级层级 | 触发情形 | 升级对象 | 响应要求建议 |
|---|---|---|---|
| 一级 | 责任人处理受阻，需要跨小组协调 | 项目负责人 | 一个工作日内给出协调意见 |
| 二级 | 项目负责人协调无果，或涉及部门间资源冲突 | 部门负责人 | 两个工作日内给出资源或决策结论 |
| 三级 | 影响项目整体目标，需要调整范围、进度或预算 | 项目指导委员会或项目发起人 | 按约定会议周期决策，形成书面结论 |
升级后的处理要求包括：升级发起人在台账中记录升级时间、升级对象、升级原因；被升级对象在响应时限内给出决策或下一步安排；问题状态保持“处理中”，并注明“已升级至某层级”。升级结论无论是否解决问题，都要回写台账，避免升级后无人跟进。升级记录本身也是复盘材料，能反映哪些环节反复成为瓶颈。
角色与交付物：谁在什么时点做什么
问题管理能否持续运转，取决于每个角色是否清楚自己的动作和产出。下表按角色列出职责与交付物：
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 问题提出人 | 描述现象与影响，提供必要背景，参与验证 | 完整的问题登记记录、验证结论 |
| 责任人 | 推进解决，更新状态与过程记录，必要时发起升级 | 解决措施记录、状态更新、升级申请 |
| 协办人 | 按责任人要求提供资源、信息或技术支撑 | 支撑材料或处理结果 |
| 项目负责人 | 分派问题、确认期限、协调跨团队事项、决定是否升级 | 分派记录、协调结论、升级决策 |
| 例会主持人 | 组织台账评审，检查更新及时性，推动超期问题处理 | 例会评审记录、待办清单 |
| 升级决策人 | 在响应时限内给出资源或方向决策 | 书面决策结论 |
例会中的分工建议固定下来：主持人按状态筛选台账，先看阻塞级和已超期问题，再由责任人逐条更新，最后确认本周新增问题和关闭问题。评审的重点是状态是否真实、期限是否合理、升级是否及时，而非逐条讨论技术细节。会议结束时形成待办清单，明确下次评审前需要完成的状态更新。
示例：一个跨团队阻塞问题从提出到关闭
以下为演示情景，用于说明台账填写和流转过程。
问题登记。某项目进入联调阶段，前端团队提出：第三方支付接口的沙箱环境账号尚未开通，联调无法开始。台账填写为：问题编号P-021，提出日期3月4日，提出人前端负责人，问题描述“支付沙箱账号未开通，支付相关联调无法执行”，影响范围“支付模块联调，影响3月15日联调完成节点”，优先级“阻塞级”，责任人暂空，状态“待确认”。
分派与处理。例会上项目负责人将责任人指定为后端接口负责人，解决期限定为3月7日，状态改为“已分派”。责任人联系第三方对接人，发现对方需要合同补充条款审批后才能开通账号，3月6日更新状态为“处理中”，备注“卡在对方合同审批，预计3月10日完成，已超出期限”。
升级触发与决策。3月7日期限到达仍未开通，满足“超过解决期限”和“跨团队无法协调”两个升级条件。责任人发起一级升级至项目负责人，项目负责人协调商务部门推动合同审批，仍无进展后于3月8日二级升级至部门负责人。部门负责人与对方接口人电话确认，约定先开通测试账号、合同条款并行审批，3月9日账号开通。台账记录升级时间、对象和结论。
验证关闭。前端负责人确认沙箱账号可用、联调已启动，3月9日状态改为“待验证”，当日验证通过后关闭，填写验证结论“账号已开通，支付联调于3月9日恢复”，关闭日期3月9日。该问题从提出到关闭历时五天，其中升级环节占两天，复盘时可据此评估外部依赖的提前介入时机。
完成检查：问题管理机制是否运转起来
机制建立后，需要定期检查它是否真正在运转。以下清单可按月核对，每项给出通过标准：
| 检查项 | 核对内容 | 通过标准建议 |
|---|---|---|
| 台账完整性 | 必填字段是否齐全，问题描述是否包含现象与影响 | 抽查记录中必填字段无空缺，描述可判断影响范围 |
| 更新及时性 | 处理中的问题是否按约定频率更新状态 | 阻塞级和高优先级问题在评审周期内均有状态更新 |
| 责任落实 | 是否每条问题都有单一责任人和明确期限 | 无责任人空缺、无期限空缺的记录 |
| 升级有效性 | 超期问题是否按规则升级，升级后是否有结论 | 超期问题均有升级记录，升级后响应在约定时限内 |
| 闭环率 | 已关闭问题占全部问题的比例，关闭是否有验证结论 | 关闭记录均含验证结论，长期未关闭问题有挂起原因 |
| 遗留问题 | 挂起和长期未关闭问题的清单是否清晰 | 每条遗留问题注明恢复条件或后续处理计划 |
检查结果应回到例会中讨论，重点看两类信号：一是超期和升级频繁出现的环节，往往说明分派时期限设定不合理或外部依赖介入太晚；二是关闭记录缺少验证结论的情况，说明闭环最后一步被省略。把这两类问题修正后，台账才会从记录工具变成推动项目前进的管理手段。
常见问题
问题提出人可以直接指定责任人和解决期限吗？
不建议。提出人的职责是把现象和影响描述清楚，并给出期望解决时间作为参考。责任人的确定原则是“谁有能力推动解决，谁就是责任人”，通常由项目负责人在例会上或会后指定；解决期限由责任人与项目负责人共同确认。这样安排的原因是提出人往往只看到障碍的一面，难以判断谁掌握解决资源，单方面设定期限也容易脱离实际。
如果提出人本身就是能推动解决的人，可以由项目负责人确认后由其兼任责任人，但仍需在台账中明确记录，避免责任模糊。
问题挂起很久，既不关闭也不处理，应该怎么管？
挂起状态必须附带原因和恢复条件，例如“等待客户书面确认验收标准”。没有恢复条件的挂起记录，应在下次例会评审时要求责任人补充，否则视为台账不完整。
对长期挂起的问题，建议每月单独列一份遗留清单，逐条判断三种去向：恢复条件已具备则转回处理中；条件短期无法具备则调整影响评估并降低优先级；问题已失去意义则说明理由后关闭。关键是让挂起成为有判断的状态，避免问题在台账中长期停留却无人决策。
团队规模小、问题不多，还需要完整的台账和分级吗？
可以简化，但保留三个核心要素：单一责任人、明确期限、可验证的关闭结论。问题数量少时，分级可以只保留“阻塞”和“一般”两档，状态也可以压缩为待分派、处理中、已关闭。台账字段同样可以精简，但问题描述仍需写清现象与影响，否则后续无法判断优先级。
随着项目复杂度上升，再逐步补充协办人、升级记录和遗留问题清单。机制的价值在于让每条问题都有人负责、有期限、有结论，表格的繁简程度可以随团队实际调整。
升级后问题仍未解决，接下来怎么办？
升级不是终点，被升级对象需要在约定时限内给出决策或下一步安排。如果二级升级后仍无结论，应按预设路径继续升级至项目发起人或指导委员会，同时由项目负责人评估该问题对项目目标的影响，必要时提出调整范围、进度或预算的方案。
每次升级的结论无论是否解决问题都要回写台账，注明决策内容、责任转移情况和新的期限。反复升级仍无进展的问题，往往说明决策权限设置或资源投入方式需要调整，应在阶段复盘中单独讨论。
问题关闭由谁验证，验证不通过怎么处理？
验证人建议由提出人或受影响的交付方担任，因为他们最清楚障碍是否真正消除。验证时要对照登记时写的影响范围逐项确认，例如接口文档是否已提供、决策是否已形成书面记录、相关任务是否可以恢复推进。
验证不通过时，问题退回处理中状态，责任人需补充解决措施并重新提交验证，台账中保留退回记录和原因。关闭记录必须包含验证结论和关闭日期，缺少验证结论的关闭应视为流程未完成。
