跨项目问题清单用于登记关联项目之间相互影响的问题，让项目集例会有统一的讨论依据。核心字段包括问题编号、涉及项目、影响项目、跨项目影响描述、严重程度、责任人、目标解决日期和状态。本文先给一张可直接复制到表格或文档中的空白模板，再逐项说明填写口径、必填与选填的取舍、一条完整填写示例，以及清单长期运行时的调整与维护规则。
要点总览（TL;DR）
- 跨项目问题清单的核心字段是问题编号、涉及项目、影响项目、跨项目影响描述、严重程度、责任人、目标解决日期和状态，其中“涉及项目”与“影响项目”分开记录，才能看清问题从哪来、拖住了谁。
- 最小可用字段集为九项：问题编号、问题标题、涉及项目、影响项目、跨项目影响描述、严重程度、责任人、目标解决日期、当前状态；项目数量少时先只填这些，月度汇总再补选填字段。
- 填写时把影响落到具体交付物和里程碑，例如写明受影响的页面、接口和延期天数；目标解决日期写具体日期，责任人为能推动解决的单一负责人。
- 维护上建议每周集中更新一次进展与状态，状态按“待确认—处理中—待验证—已关闭”流转，关闭需影响项目确认、责任人填写解决方式、协调人复核影响是否解除。
- 清单可放在表格、文档或 ONES Plan、ONES Wiki 中承载；工具服务于字段口径和维护规则，先定规则再选载体。
可直接复制的跨项目问题清单空白模板
下面这张表可以直接复制到 Excel、在线表格或文档中。表头已覆盖跨项目问题登记所需的基本字段，其中“涉及项目”“影响项目”“跨项目影响描述”是区别于单项目问题清单的关键列，用于说明问题从哪个项目产生、又波及哪些项目。空白行可按需增删，建议保留一行作为填写格式参照。
| 问题编号 | 问题标题 | 问题来源 | 涉及项目 | 影响项目 | 问题描述 | 跨项目影响描述 | 严重程度 | 优先级 | 提出人 | 责任人 | 协调人 | 提出日期 | 目标解决日期 | 当前状态 | 最新进展 | 关闭日期 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
如果清单放在文档中而非表格中，可以把每一列转成一条记录卡片，按“编号—标题—涉及项目—影响项目—影响描述—严重程度—责任人—目标日期—状态”的顺序排列，保持字段名称与上表一致，便于后续汇总。
每个字段记录什么：字段说明
字段说明的作用是让不同项目的人按同一口径填写。跨项目问题最容易出现的偏差，是各项目对“严重程度”和“影响范围”的理解不一致，导致清单无法横向比较。下表逐字段给出含义与填写口径。
| 字段 | 记录内容 | 填写口径 |
|---|---|---|
| 问题编号 | 清单内唯一标识 | 建议采用“项目集缩写-序号”格式，如 PJ-001，编号一经分配不再复用 |
| 问题标题 | 一句话概括问题 | 写清对象和现象，控制在 20 字左右，避免只写“接口问题”这类无法检索的标题 |
| 问题来源 | 问题被发现的渠道 | 可填例会、评审、联调、客户反馈、依赖方通知等，便于回溯发现机制 |
| 涉及项目 | 问题产生或主要所在的项目 | 填写一个主要项目；若问题由多个项目共同造成，在备注中说明其余项目 |
| 影响项目 | 因该问题受到牵连的项目 | 可填多个，用逗号分隔；没有明确受影响项目时填“待确认” |
| 问题描述 | 问题本身的事实 | 写清发生时间、现象和已确认的信息，不写推测性结论 |
| 跨项目影响描述 | 问题如何影响其他项目 | 说明受影响的交付物、里程碑、接口或资源，例如“导致 B 项目联调延期两周” |
| 严重程度 | 问题造成后果的等级 | 建议分三级：高（影响关键里程碑或对外交付）、中（影响部分计划但可调整）、低（有影响但可内部消化） |
| 优先级 | 处理先后顺序 | 与严重程度分开填写，严重程度高但已有替代方案的问题，优先级可以下调 |
| 提出人 | 登记该问题的人 | 填写姓名，负责补充背景信息 |
| 责任人 | 推动问题解决的人 | 只填一人，需具备跨项目协调权限或能调动所需资源 |
| 协调人 | 负责跨项目沟通的人 | 通常由项目集经理或PMO担任，在责任人与影响项目之间传递信息 |
| 提出日期 | 问题登记时间 | 用于计算问题滞留时长 |
| 目标解决日期 | 计划完成解决的时间 | 填写具体日期，不写“尽快”“本季度”等模糊表述 |
| 当前状态 | 问题所处阶段 | 建议取值：待确认、处理中、待验证、已关闭、挂起 |
| 最新进展 | 最近一次更新内容 | 每次更新写日期加一句话，保留历史可另建更新记录 |
| 关闭日期 | 问题关闭时间 | 状态改为已关闭时填写，与目标解决日期对照可评估解决及时性 |
| 备注 | 补充信息 | 记录关联问题编号、临时应对措施或其他项目名称 |
“涉及项目”与“影响项目”需要分开记录，原因在于二者承担的动作不同：涉及项目通常要参与原因排查和方案制定，影响项目主要关注自身计划如何调整。合并成一列后，清单就无法回答“哪些项目正在被别人的问题拖住”。
必填与选填：最小可用字段集
字段齐全的清单便于分析，但填写负担过重会让登记流于形式。建议先确定最小可用字段集，保证每条问题都能被追踪和分派，再按项目集成熟度补充选填字段。
| 类别 | 字段 | 理由 |
|---|---|---|
| 必填 | 问题编号 | 唯一标识，用于引用和汇总 |
| 必填 | 问题标题 | 例会快速浏览的基础 |
| 必填 | 涉及项目 | 定位问题归属 |
| 必填 | 影响项目 | 跨项目清单的核心字段 |
| 必填 | 跨项目影响描述 | 说明影响的具体交付物或节点 |
| 必填 | 严重程度 | 决定讨论和资源投入顺序 |
| 必填 | 责任人 | 没有责任人的问题无法推进 |
| 必填 | 目标解决日期 | 形成时间约束，便于逾期提醒 |
| 必填 | 当前状态 | 支撑状态流转和关闭判断 |
| 选填 | 问题来源 | 用于分析问题发现渠道，规模较小时可省略 |
| 选填 | 问题描述 | 标题足够清晰时可暂不展开 |
| 选填 | 优先级 | 问题数量少时可由严重程度代替 |
| 选填 | 提出人 | 登记人固定时意义有限 |
| 选填 | 协调人 | 项目集经理兼任时可省略 |
| 选填 | 提出日期 | 需要统计滞留时长时再补 |
| 选填 | 最新进展 | 有独立更新记录时可省略 |
| 选填 | 关闭日期 | 需要评估解决及时性时保留 |
| 选填 | 备注 | 用于补充关联信息 |
精简版适用于项目数量在五个以内、问题每周不超过十条的项目集，只保留必填字段，登记和更新都能在十分钟内完成。完整版适用于项目之间存在较多接口依赖、需要向管理层汇报的项目集，此时来源、优先级、协调人和关闭日期能支撑趋势分析。两种版本可以共存：日常登记用精简版，月度汇总时再补齐选填字段。
填写示例：一条跨项目问题如何登记
以下示例为演示情景，用于说明字段之间的对应关系，不构成真实案例。背景设定：某项目集包含 A、B 两个关联项目，A 项目负责提供数据接口，B 项目基于该接口开发前端功能，两个项目共用一名后端开发人员。
| 字段 | 填写内容 |
|---|---|
| 问题编号 | PJ-007 |
| 问题标题 | A 项目接口字段变更未同步 B 项目 |
| 问题来源 | B 项目联调例会 |
| 涉及项目 | A 项目 |
| 影响项目 | B 项目 |
| 问题描述 | A 项目于本周二调整了订单接口的返回字段，B 项目按旧字段开发的前端页面出现数据缺失 |
| 跨项目影响描述 | B 项目原定下周的联调验收需推迟，涉及三个页面；若两周内未解决，将影响 B 项目里程碑 |
| 严重程度 | 高 |
| 优先级 | 高 |
| 提出人 | B 项目前端负责人 |
| 责任人 | A 项目后端负责人 |
| 协调人 | 项目集经理 |
| 提出日期 | 示例日期：3 月 12 日 |
| 目标解决日期 | 示例日期：3 月 19 日 |
| 当前状态 | 处理中 |
| 最新进展 | 3 月 14 日：A 项目已提供新字段说明，B 项目评估改造工作量 |
| 关闭日期 | 待关闭后填写 |
| 备注 | 需在项目集周会上确认接口变更通知机制 |
这条示例体现了几个填写要点：影响描述写到了具体页面和里程碑，而非笼统的“影响 B 项目”；责任人是能直接推动接口调整的 A 项目后端负责人，协调人负责在两个项目之间传递信息；目标解决日期早于 B 项目里程碑，为验证留出时间。备注中记录的不只是本条问题，还指向了需要改进的通知机制，这类信息在定期复核时很有价值。
清单的调整与维护方法
清单做好后能否持续使用，取决于字段规模是否匹配项目集复杂度，以及更新、复核和关闭是否有明确规则。以下规则可按团队实际情况取舍。
按项目集规模增减字段
- 项目数量少于五个、依赖关系简单时，使用必填字段加备注即可，避免为每条问题填写十余列。
- 项目数量增加或出现多个项目共用资源时，补充“协调人”和“优先级”，用于区分谁负责沟通、谁先处理。
- 需要向管理层汇报时，补充“提出日期”“关闭日期”，以便统计平均滞留时长和按期解决比例。
- 问题反复出现在同类接口或同类依赖上时，增加“问题类别”字段，用于归类和趋势分析。
更新频率与责任人
建议每周固定一次集中更新，由各问题责任人在例会前完成“最新进展”和“当前状态”的填写，协调人负责检查影响项目是否已同步。日常出现状态变化时可随时更新，但周更新不可省略，否则清单会退化为历史记录。更新时保留日期，便于判断某条问题是否长期没有推进。
状态流转与关闭条件
状态建议按“待确认—处理中—待验证—已关闭”流转，暂时无法推进的问题标记为“挂起”并写明原因和复核时间。关闭需要满足三个条件：影响项目确认影响已消除或已接受；责任人填写了解决方式；协调人复核了跨项目影响描述中的交付物和里程碑是否已恢复。仅由责任人单方面标记完成，不足以关闭跨项目问题。
定期复核跨项目影响
每月或每个里程碑节点，协调人应复核一遍清单中的开放问题，重点检查三件事：影响项目是否发生变化，原定的目标解决日期是否仍然合理，已关闭问题的影响是否真正解除。复核结果可以直接作为项目集例会的输入，也可以据此调整下阶段的资源安排。
清单落地时需要承载工具。ONES Plan 支持多项目总览，可自定义项目属性管理不同类型项目，并查看多项目数据集合、多维度掌控项目进度；其产品管理能力可通过工作项属性跨项目管理，并与 ONES Project 数据互通。对于以文档方式维护清单的团队，ONES Wiki 支持使用模板库一键创建文档、页面组关联项目，文档可嵌入任务进度与各类报表，并支持页面版本记录与回滚、按角色配置读写权限，便于把空白模板固化为团队共用版本，同时保留每次更新的历史。工具选择取决于团队已有的协作习惯，清单本身的字段口径和维护规则才是长期有效的部分。
常见问题
跨项目问题清单和单项目风险登记表有什么区别，能不能共用一张表？
两者关注的对象不同。单项目风险登记表记录本项目内部可能发生的不确定事件及其应对措施；跨项目问题清单记录已经发生、并在关联项目之间产生实际影响的问题，重点在“影响项目”和“跨项目影响描述”两列。共用一张表时，建议增加“问题类型”字段区分单项目事项与跨项目事项，并在例会上分开讨论，避免单项目内部事项挤占跨项目协调时间。单项目风险的识别与应对方法，可参考项目风险管理相关主题。
问题登记后迟迟没有进展，清单里应该怎么体现？
建议在“最新进展”中保留每次更新的日期和一句话说明，让停滞时长可见；同时把“当前状态”改为“挂起”，并在备注中写明挂起原因和下次复核时间。周更新时由协调人筛出超过目标解决日期仍未关闭的问题，在项目集例会上逐条确认：是目标日期需要调整，还是需要追加资源或升级处理。清单本身不解决推进问题，但能让停滞被看见、被追问。
一个项目的问题同时影响多个项目，涉及项目和影响项目怎么填？
“涉及项目”填写问题产生或主要所在的那一个项目，便于定位原因排查的主体；“影响项目”可以填多个，用逗号分隔，把每个受影响项目及其受影响的具体交付物写进“跨项目影响描述”。如果问题由多个项目共同造成，在备注中列出其余项目，并在协调人组织下共同确认解决方案。这样拆分后，清单既能回答“问题出在哪个项目”，也能回答“哪些项目正在被拖住”。
项目集规模扩大后，清单字段要不要跟着增加？
按实际管理需要增加，避免一次加满。项目数量增加或出现多个项目共用资源时，补充“协调人”和“优先级”；需要向管理层汇报时，补充“提出日期”“关闭日期”，用于统计滞留时长和按期解决比例；同类接口或同类依赖反复出问题时，增加“问题类别”做趋势分析。每次增加字段后，同步更新字段说明中的填写口径，否则不同项目的填法会再次分化。
用文档维护清单和用项目管理工具维护，各自适合什么情况？
文档适合问题数量少、参与人固定、以周会讨论为主的团队，编辑门槛低，复制模板即可开始。问题数量增多、需要按项目筛选、跟踪状态流转和统计逾期情况时，项目管理工具更合适。ONES Plan 支持多项目总览，可自定义项目属性管理不同类型项目，并查看多项目数据集合；ONES Wiki 支持使用模板库一键创建文档、页面组关联项目，并支持页面版本记录与回滚、按角色配置读写权限，适合把空白模板固化为团队共用版本。选择取决于团队已有的协作习惯。
清单里的问题关闭后，还需要保留记录吗？
建议保留。已关闭问题是后续复核和趋势分析的依据：可以对照目标解决日期与关闭日期评估解决及时性，也可以从备注中找出反复出现的接口变更、通知机制缺失等共性问题。保留方式可以是把已关闭问题移入单独的归档表，或在同一张表中用状态筛选隐藏；无论哪种方式，问题编号不复用，历史记录可追溯。
