项目问题责任人负责单个问题的推进与闭环，并不承担所有执行工作。分工的关键是把“谁负责推进、谁提供信息、谁做决策、谁验收关闭”拆开，再用问题台账和例会机制固定下来。本文给出一套可直接落地的角色划分、五步流程、台账字段与检查清单，适用于项目推进障碍类问题；缺陷管理与服务事件管理另有专门流程。
要点总览（TL;DR）
- 问题责任人负责单个问题的推进与闭环，具体方案和执行由领域处理人完成；提出人负责描述现象与验收，升级决策人负责资源与优先级裁决，项目经理维护台账规则与升级通道。
- 落地路径是五步流程：登记、定责、推进、升级、关闭；其中定责要写明处理人与期望完成时间，关闭要经过提出人验收。
- 用问题台账承载分工：问题描述、影响、提出人、责任人、处理人、优先级、期望完成时间、当前状态为必填字段，状态按待受理、处理中、待验收、已关闭、已升级流转。
- 机制持续运转靠每周问题例会、两级升级通道和以台账为准的信息同步；每月抽查责任人是否明确、状态是否按时更新、升级是否及时触发。
- 角色可以合并，但同一问题上提出人与验收人、处理人与关闭确认人应尽量分离，避免自提自验、自处理自关闭。
先定角色：问题责任人、提出人、处理人、决策人各管什么
分工混乱通常来自一个误解：把“责任人”理解成“所有事都由他做”。项目问题管理里，责任人的价值在于让一个问题始终有人盯着、有人协调、有人推动到关闭，具体的技术方案和操作动作由领域处理人完成。把角色边界写清楚，后续流程才有依据。
以下五类角色覆盖了项目问题从出现到关闭的主要职责。角色名称可以按组织习惯调整，职责内容建议保持一致。
| 角色 | 核心动作 | 不承担的事 | 输出物 |
|---|---|---|---|
| 问题责任人 | 确认受理、补齐字段、判断归属、指定处理人、跟踪状态、协调阻塞、发起升级、确认关闭 | 不替代处理人给方案或执行具体动作；不独自承担跨团队裁决 | 完整的问题记录、推进记录、关闭确认 |
| 提出人 | 描述现象与影响、提供复现信息或现场信息、参与验收 | 不负责定责与推进节奏；不自行关闭问题 | 问题初始描述、补充信息、验收结论 |
| 领域处理人 | 分析原因、给出方案、执行具体动作、反馈进展与阻塞 | 不决定问题优先级；不代替提出人验收 | 处理方案、执行结果、完成说明 |
| 升级决策人 | 裁决优先级与资源、处理跨团队冲突、决定是否调整目标或时间 | 不介入单个问题的日常跟踪 | 裁决结论、资源调配决定 |
| 项目经理 | 维护台账规则与字段标准、组织问题例会、维护升级通道、复盘机制运行情况 | 不替责任人推进具体问题 | 台账规则、例会议程与纪要、升级通道说明 |
小团队里角色合并很常见，例如项目经理兼任升级决策人，或责任人由提出人所在小组的负责人担任。合并时守住两条原则：同一问题上，提出人与验收确认尽量分离，处理人与关闭确认尽量分离。自提自验、自处理自关闭会让验收环节失去意义，问题看似关闭、实际未解决。人员确实紧张时，至少让另一名成员复核关闭结论，并在台账中留下复核记录。
核心操作步骤：从问题登记到关闭的五步分工流程
角色定清楚后，需要一条固定的动作顺序，让每个环节都知道自己该做什么、交付什么。以下五步适用于大多数项目问题，每步都给出输入、动作、输出和完成标志，便于对照执行。
| 步骤 | 输入 | 动作与角色 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 登记 | 现象描述、影响范围、发生时间与场景 | 提出人提交问题；责任人确认受理，补齐影响、优先级、期望完成时间等字段 | 一条字段完整的问题记录 | 责任人字段已填写，状态为“待受理”转“处理中” |
| 2. 定责 | 问题记录、相关团队分工信息 | 责任人判断归属，指定领域处理人，约定期望完成时间 | 处理人指派与时间约定 | 处理人已确认接单，时间写入台账 |
| 3. 推进 | 处理人方案、进展反馈 | 处理人给出方案并执行；责任人跟踪状态，识别阻塞并协调 | 方案记录、进展更新 | 方案已记录，状态按实际进展更新 |
| 4. 升级 | 超时记录、跨团队冲突、资源缺口 | 责任人发起升级；升级决策人裁决优先级与资源 | 裁决结论与新的时间约定 | 裁决结论写入台账，责任人与处理人确认执行 |
| 5. 关闭 | 处理人交付结果 | 处理人提交完成说明；提出人验收；责任人确认关闭 | 验收结论、关闭记录 | 提出人验收通过，状态改为“已关闭” |
五步中最容易被跳过的是第2步定责和第5步验收。定责不清，问题会在多个团队之间来回转手；验收缺失，问题会在“处理人认为完成”时提前关闭。责任人在这两步上的动作要具体：定责时明确写出处理人姓名和期望完成时间，验收时确认提出人已给出结论，而不是由处理人自行标记完成。
推进环节还有一个常被忽略的动作：责任人要区分“处理人在做”和“问题在往前走”。处理人反馈“正在排查”属于过程信息，责任人需要进一步确认当前卡点、下一步动作和时间点，把这些写进台账，避免问题长期停留在“处理中”状态却无人察觉。
问题台账字段与状态设计
分工要落到具体载体上，最直接的方式是一张问题台账。台账的作用是让每个角色知道自己在哪个环节改哪个字段，减少口头交接造成的信息丢失。以下字段清单可作为建表起点，组织可按项目类型增减。
| 字段 | 填写角色 | 说明 |
|---|---|---|
| 问题描述 | 提出人 | 现象、发生场景、期望结果 |
| 影响 | 提出人、责任人补充 | 影响的迭代、交付物、团队范围 |
| 提出人 | 提出人 | 后续验收的责任角色 |
| 责任人 | 项目经理或受理人 | 单问题推进与闭环负责人 |
| 领域处理人 | 责任人 | 给出方案并执行的角色 |
| 优先级 | 责任人，升级时由决策人调整 | 结合影响与时间压力确定 |
| 期望完成时间 | 责任人与处理人约定 | 作为超时判断依据 |
| 当前状态 | 按状态流转规则由对应角色更新 | 见下方状态说明 |
| 升级记录 | 责任人 | 升级时间、触发原因、裁决结论 |
| 验收结论 | 提出人 | 通过或不通过及原因 |
状态建议设为五档：待受理、处理中、待验收、已关闭、已升级。状态与角色的对应关系要写进规则：提出人提交后进入“待受理”，责任人确认受理并完成定责后改为“处理中”；处理人交付后由责任人改为“待验收”；提出人验收通过后由责任人确认改为“已关闭”；触发升级时标记“已升级”，裁决后回到“处理中”并更新期望完成时间。每次状态变更都记录变更人和时间，便于复盘。
时限设置上，建议为“待受理”和“待验收”分别设定响应时限，例如受理在一个工作日内确认、验收在两个工作日内给出结论；处理中的时限按问题优先级分档。台账可设置超时标记，由项目经理定期检查，超时未升级的问题在例会上说明原因。时限取值需结合团队节奏确定，本文给出的是参考区间。
示例：一个跨团队阻塞问题如何分工推进
以下为演示情景，用于说明各角色在具体环节的动作与交接，不代表真实项目数据。
情景设定：某迭代测试阶段，测试环境因两个团队共用的配置变更出现阻塞，测试无法执行，迭代存在延期风险。测试负责人作为提出人提交问题，描述现象为“测试环境登录后接口持续报错，影响本轮全部回归用例”，影响范围写明涉及的两个团队和预计延期天数。
登记与定责：问题责任人（由项目经理指定）在一个工作日内确认受理，补齐优先级为高、期望完成时间为两个工作日，并判断问题涉及平台团队与应用团队。责任人指定平台团队一名工程师为领域处理人，同时请应用团队提供近期配置变更记录。台账状态改为“处理中”。
推进：处理人排查后给出方案：回滚一项配置变更并补充校验步骤。责任人将方案写入台账，约定当天完成回滚、次日验证。回滚完成后测试仍有一项用例失败，责任人识别出这属于应用团队侧的适配问题，追加应用团队处理人，并把期望完成时间顺延半天，同步告知提出人。
升级：顺延后的时间点仍未解决，且两个团队对是否调整迭代范围存在分歧。责任人触发升级，升级决策人（项目集负责人）裁决：本轮迭代保留该功能，测试范围先覆盖不受影响的部分，阻塞问题按高优先级继续处理。裁决结论与新的时间约定写入台账。
验收与关闭：应用团队完成适配后，处理人提交完成说明。提出人按原描述的场景复测，确认回归用例全部通过，给出验收通过结论。责任人核对验收记录后确认关闭，状态改为“已关闭”，并在例会上简要说明处理过程与耗时。
协作机制：例会、升级通道与信息同步
流程和台账解决单个问题怎么走，机制解决整套分工能否持续运转。缺少固定节奏，台账会逐渐变成只登记不更新的记录，责任人的跟踪动作也会被日常事务挤掉。
问题例会建议每周一次，时长控制在半小时到一小时。参与角色包括问题责任人、项目经理、各领域处理人代表，升级决策人可按需参加。议程固定为三项：上周新增与关闭情况、超时与升级问题逐条过、需要协调的资源或跨团队事项。会议只处理台账中已有记录的问题，避免变成临时问题收集会；会上形成的结论当场更新到台账，由项目经理核对字段完整性。
升级通道建议分两级：一级由责任人在团队内协调，适用于处理人时间冲突或信息不足；二级由升级决策人裁决，适用于超时未解决、跨团队优先级冲突或需要调整迭代范围的情况。触发条件写清楚，例如超过期望完成时间一个工作日未推进、涉及两个以上团队且无法达成一致。责任人按条件发起，不必等到问题严重影响交付才升级。
信息同步以台账为准，减少多通道重复沟通。状态变更、处理人调整、时间顺延由责任人在台账更新后通知提出人和相关处理人；升级结论由责任人同步给升级决策人和项目经理。责任人与项目经理在机制中的分工是：责任人管单个问题的推进质量，项目经理管台账规则、例会组织和升级通道的维护，两者不互相替代。
当问题数量增多、跨团队协作频繁时，台账、状态流转和升级记录可以放到项目管理工具中承载，让字段、状态和通知在同一处维护。ONES 可用于承载问题台账与状态流转，具体配置方式需结合团队实际流程确定。
完成检查：分工机制是否落地的核对项
机制是否有效，不看制度文档写得多完整，而看台账里的记录能否支撑以下核对项。建议每月抽查一次，由项目经理组织，逐项给出“是”或“否”，对“否”的项说明原因和调整动作。
- 每个未关闭问题是否都有明确的责任人和领域处理人，字段无空缺。
- 提出人、处理人、验收人是否按角色履职，是否存在自提自验、自处理自关闭的情况。
- 状态是否与实际进展一致，是否存在长期停留在“处理中”但无进展记录的问题。
- 期望完成时间是否按时更新，超时问题是否有超时标记和原因说明。
- 升级是否在超时前或冲突出现时触发，升级记录是否包含触发原因和裁决结论。
- 关闭是否经过提出人验收，验收结论是否写入台账。
- 问题例会是否按频率召开，议程是否覆盖超时与升级问题，结论是否回写台账。
- 台账是否定期复盘，重复出现的问题是否被识别并调整处理方式。
核对中发现的问题，优先修正字段与状态规则，再调整角色安排。多数分工失效源于规则不清或更新不及时，而非人员不配合。把检查结果与例会结合，逐月收敛，分工机制才能稳定运转。
常见问题
小团队人手紧张，问题责任人和处理人由同一人担任可以吗？
可以，但需要保留一道外部确认。责任人与处理人合并后，推进和执行由同一人完成，效率较高；风险在于关闭环节缺少独立判断。建议至少让提出人完成验收，并在台账中记录验收结论和确认时间。如果提出人也不便验收，可指定另一名成员复核关闭结论，复核记录写入台账。合并角色时优先保证“提出与验收分离、处理与关闭确认分离”这两条边界。
问题长时间停在“处理中”，责任人应该怎么处理？
先区分两种情况：处理人确实在推进，还是问题已经停滞。责任人可以要求处理人给出当前卡点、下一步动作和预计时间点，把这些信息写入台账；如果超过期望完成时间一个工作日仍无实质进展，按升级条件发起升级，由升级决策人裁决优先级或调配资源。责任人不必等到问题严重影响交付才升级，超时本身就是触发条件。
跨团队问题的优先级由谁定，责任人能直接调整吗？
责任人可以在受理和定责阶段给出初始优先级，依据是影响范围和交付时间压力。当两个以上团队对优先级存在分歧，或需要调整迭代范围、追加资源时，由升级决策人裁决，裁决结论写入台账并同步给相关处理人。责任人负责发起升级和跟踪执行，不独自承担跨团队优先级裁决，这样既保证决策有权限支撑，也避免责任人在团队之间反复协调。
问题台账和缺陷管理、服务事件管理需要合并成一张表吗？
不建议合并。项目问题台账关注项目推进障碍，字段围绕影响范围、责任人、处理人和期望完成时间设计；产品 Bug 归缺陷管理，服务中断归服务事件与问题管理，两者的流程、状态和统计口径不同。分开管理可以让每类记录的状态流转更清晰，也便于各自复盘。如果组织需要统一视图，可以在报表层汇总，底层仍按类型分开维护。
问题例会怎样开才不至于变成临时问题收集会？
把议程固定在台账已有记录上：上周新增与关闭情况、超时与升级问题逐条过、需要协调的资源或跨团队事项。会前由项目经理整理待议清单，会上只讨论清单内的问题，临时提出的问题先登记入台账，排入下次议程或按升级条件处理。会议结论当场回写台账，由项目经理核对字段完整性。这样例会的作用是推动已有问题闭环，而不是替代登记流程。
