项目集结构图用一张表把共同目标、预期收益、组成项目、项目间依赖、关键角色和治理节点放在同一视图里，帮助读者看清哪些关联工作为一个共同收益协同。本文提供可直接复制的空白表、逐字段填写口径、必填与选填划分，并用一个完整示例演示两张表如何配合，最后说明结构图随项目集变化时的维护方法。
要点总览（TL;DR）
- 模板由两张表组成：项目集总览表说明共同目标、预期收益、治理角色与审批节点，项目明细表说明组成项目、交付物、项目间依赖与里程碑。
- 最小可用版本只需填写项目集名称、共同目标、预期收益、起止时间、项目集负责人，以及明细表中的项目编号、项目名称、项目负责人、所属阶段、交付物和与其他项目的依赖。
- 判断一组项目能否构成项目集，可检查三点：是否共享同一共同目标、是否存在实质性输入输出依赖、收益是否只能在协同后实现。
- 结构图需随项目增减、依赖变化和收益目标调整而更新，建议在治理例会上定期评审，并用变更记录保留历史版本。
可复制空白项目集结构图模板
模板由两张表组成：项目集总览表回答“这个项目集为什么存在、由谁治理”，项目明细表回答“由哪些项目组成、彼此如何依赖”。两张表通过项目集名称关联，填写时先完成总览表，再逐行补充明细表。表格可直接复制到文档或表格工具中使用。
表一：项目集总览表（空白）
| 字段 | 填写内容 |
|---|---|
| 项目集名称 | |
| 共同目标 | |
| 预期收益 | |
| 收益度量方式 | |
| 起止时间 | |
| 项目集负责人 | |
| 治理机构 | |
| 审批节点 |
表二：项目明细表（空白）
| 项目编号 | 项目名称 | 项目负责人 | 所属阶段 | 交付物 | 与其他项目的依赖 | 依赖类型 | 关键里程碑 | 状态 |
|---|---|---|---|---|---|---|---|---|
字段说明：每个格子填什么
字段说明的目标是让不同人填写同一张表时口径一致，避免出现“目标”写成任务清单、“收益”写成口号的情况。以下定义与空白表字段一一对应。
总览表字段定义
| 字段 | 定义与填写口径 |
|---|---|
| 项目集名称 | 项目集的正式名称，建议包含业务对象或成果方向，便于与单个项目名称区分。 |
| 共同目标 | 说明要达成什么，描述多个项目协同后希望实现的业务状态。写成一句可判断是否达成的话，避免罗列各项目任务。 |
| 预期收益 | 说明协同后得到什么可度量的结果，例如成本下降幅度、交付周期缩短、覆盖范围扩大。与共同目标的区别是：目标回答“要达成什么”，收益回答“达成后得到什么、如何衡量”。 |
| 收益度量方式 | 写明指标名称、数据来源和统计周期，使收益可被跟踪。例如“按季度统计的单位交付成本”。 |
| 起止时间 | 项目集的整体周期，精确到月即可；单个项目的周期放在明细表里程碑中体现。 |
| 项目集负责人 | 对共同目标和收益负责的角色，通常不是某个单项目的负责人。 |
| 治理机构 | 对项目集进行决策与监督的会议或委员会，写明名称即可。 |
| 审批节点 | 项目集层面需要审批的关键节点，如立项审批、阶段关口评审、收益验收。 |
明细表字段定义
| 字段 | 定义与填写口径 |
|---|---|
| 项目编号 | 项目集内唯一编号，建议采用“项目集缩写-序号”格式，便于在依赖字段中引用。 |
| 项目名称 | 项目正式名称，与立项文件保持一致。 |
| 项目负责人 | 对单项目交付负责的角色。 |
| 所属阶段 | 项目当前所处阶段，取值建议统一为：规划、执行、验收、关闭。 |
| 交付物 | 该项目向项目集或其他项目提供的可交付成果，写成果名称而非活动描述。 |
| 与其他项目的依赖 | 写明依赖的项目编号及依赖内容，例如“依赖 P-02 提供接口规范”。只写有实质影响的依赖，避免把所有协作都记为依赖。 |
| 依赖类型 | 描述依赖的性质，建议取值：输入依赖（需要对方交付物才能开始）、输出依赖（本方交付物被对方使用）、双向依赖（双方互相需要）。同一行可标注多个类型并注明对象。 |
| 关键里程碑 | 该项目对项目集有影响的时间点，写日期与里程碑名称。 |
| 状态 | 项目当前健康度，建议取值：正常、关注、风险、暂停。与阶段字段区分：阶段表示进度位置，状态表示健康程度。 |
必填与选填：哪些字段不能空
必填字段决定结构图能否支撑基本判断：能否看出共同收益、由哪些项目组成、项目之间是否真的相关。选填字段用于提高治理精度，可按项目集规模和治理成熟度逐步补齐。
| 字段 | 必填/选填 | 缺失后的影响或适用场景 |
|---|---|---|
| 项目集名称 | 必填 | 缺失则无法与明细表关联。 |
| 共同目标 | 必填 | 缺失则无法判断各项目是否为一个共同收益协同，结构图退化为项目清单。 |
| 预期收益 | 必填 | 缺失则项目集存在的理由不成立，也无法在后期验收。 |
| 收益度量方式 | 选填 | 治理成熟度较低时可先写收益、后补度量口径；进入收益跟踪阶段前应补齐。 |
| 起止时间 | 必填 | 缺失则无法安排治理节点与评审节奏。 |
| 项目集负责人 | 必填 | 缺失则共同目标无人负责。 |
| 治理机构 | 选填 | 小型项目集可由负责人直接决策；跨部门项目集建议填写。 |
| 审批节点 | 选填 | 受监管或高投入项目集建议填写，用于明确关口评审。 |
| 项目编号 | 必填 | 缺失则依赖字段无法准确引用。 |
| 项目名称 | 必填 | 缺失则明细表无法识别。 |
| 项目负责人 | 必填 | 缺失则单项目交付责任不清。 |
| 所属阶段 | 必填 | 缺失则无法判断项目集整体进度分布。 |
| 交付物 | 必填 | 缺失则无法判断项目之间的输入输出关系。 |
| 与其他项目的依赖 | 必填 | 缺失则结构图无法体现“关联工作”，这是项目集与项目清单的核心区别。 |
| 依赖类型 | 选填 | 依赖较少时可先文字描述；依赖密集时建议统一标注类型，便于识别关键路径。 |
| 关键里程碑 | 选填 | 项目集进入执行阶段后建议补齐，用于对齐跨项目时间点。 |
| 状态 | 选填 | 初次搭建结构时可暂不填写，进入运行跟踪后按评审周期更新。 |
最小可用版本只需填写：项目集名称、共同目标、预期收益、起止时间、项目集负责人，以及明细表中的项目编号、项目名称、项目负责人、所属阶段、交付物、与其他项目的依赖。这组字段已经能够回答“为什么把这些项目放在一起、它们如何相互支撑”。治理机构、审批节点、依赖类型、关键里程碑和状态可随项目集运行逐步补充。
填写示例：一个完整填好的结构图
以下为演示情景，用于说明字段填写方式，不代表真实客户案例。某制造企业将三个关联项目组成一个项目集，目标是统一区域仓储与配送能力。
总览表填写示例
| 字段 | 填写内容 |
|---|---|
| 项目集名称 | 区域仓配一体化项目集 |
| 共同目标 | 在华东区域建成统一的仓储与配送协同能力，使订单从下单到送达的流程在三个项目交付后贯通运行。 |
| 预期收益 | 区域订单平均履约周期缩短，仓储与配送环节的重复交接减少，单位订单履约成本下降。 |
| 收益度量方式 | 按季度统计区域订单平均履约天数与单位订单履约成本，数据取自订单系统与财务月报。 |
| 起止时间 | 2025年3月至2026年6月 |
| 项目集负责人 | 供应链总监 |
| 治理机构 | 项目集指导委员会（供应链、IT、财务三方代表） |
| 审批节点 | 立项审批、仓储系统上线关口评审、收益验收 |
明细表填写示例
| 项目编号 | 项目名称 | 项目负责人 | 所属阶段 | 交付物 | 与其他项目的依赖 | 依赖类型 | 关键里程碑 | 状态 |
|---|---|---|---|---|---|---|---|---|
| P-01 | 仓储系统升级 | IT 项目经理 | 执行 | 新版仓储管理系统及接口规范 | 向 P-02 提供接口规范；接收 P-03 的库位规划方案 | 输出依赖（对 P-02）；输入依赖（来自 P-03） | 2025年9月接口冻结 | 正常 |
| P-02 | 配送调度平台建设 | 物流项目经理 | 规划 | 配送调度平台及运力匹配规则 | 依赖 P-01 提供接口规范后才能进入开发 | 输入依赖 | 2025年11月平台试运行 | 关注 |
| P-03 | 仓库布局与库位优化 | 运营项目经理 | 执行 | 库位规划方案与作业流程手册 | 向 P-01 提供库位规划方案 | 输出依赖 | 2025年7月方案确认 | 正常 |
示例中，三个项目通过 P-01 的接口规范和 P-03 的库位方案形成输入输出关系，共同支撑总览表中的履约周期与成本收益。P-02 的状态标为“关注”，原因是其启动时间受 P-01 接口冻结节点约束，这一信息在总览表中无法体现，正是明细表依赖字段的价值。
调整与维护方法
结构图在项目集运行期间需要随实际情况更新，否则会变成一份过时的立项文档。维护的重点是明确触发条件、评审节奏和变更记录方式。
更新触发条件
- 项目增减：新增或退出项目时，同步更新明细表，并检查总览表的共同目标和收益是否仍然成立。
- 依赖变化：交付物范围、接口或时间节点调整导致依赖关系改变时，更新“与其他项目的依赖”和“依赖类型”，并评估对关键里程碑的影响。
- 收益目标调整：市场或业务条件变化导致收益指标修改时，更新预期收益与度量方式，并在变更记录中注明原因。
- 治理节点变化：审批节点或治理机构调整时，更新总览表对应字段。
评审节奏与参与角色
建议在项目集指导委员会例会上固定评审结构图，频率可按项目集周期设为月度或季度。参与角色包括项目集负责人、各项目负责人和治理机构代表。评审输出应包含：依赖关系是否仍然准确、状态是否需要调整、是否有项目应退出或新增。
版本与变更记录
在结构图文档中增加变更记录区，建议包含以下字段：变更日期、变更字段、变更前内容、变更后内容、变更原因、提出人、确认人。每次评审后形成新版本，保留历史版本以便回溯依赖判断的依据。
避免把项目清单当作项目集结构
判断一份结构图是否成立，可以检查三点：各项目是否共享同一个共同目标；明细表中是否存在实质性的输入输出依赖；收益是否只能在项目协同后实现。若三个条件均不满足，这组项目更适合作为并列项目清单管理，而不是项目集。投资选择与优先级排序属于项目组合层面的工作，不在结构图范围内。
结构图进入日常运行后，项目、依赖、里程碑和状态需要在协作工具中持续承载，避免文档与执行脱节。ONES Plan 提供多项目总览与自定义项目属性，可查看多项目数据集合并从多维度掌握进度；其甘特图支持制定项目里程碑、多时间跨度查看进度，并可监控及规划 ONES Project 中的相关项目和迭代。结构图文档本身可放在 ONES Wiki 中，页面组关联项目后，需求与文档互相对应，文档还能嵌入任务进度与报表，使结构图与执行数据保持在同一处。具体版本与部署差异需按实际所购版本核验。
常见问题
项目集结构图和普通项目清单的区别在哪里？
区别在于是否围绕共同收益形成协同关系。项目清单只列出有哪些项目；项目集结构图还要写明这些项目共享的共同目标、预期收益，以及项目之间的输入输出依赖。填写时可以检查：各项目是否服务于同一个可判断是否达成的目标，明细表中是否存在实质性的交付物依赖，收益是否只能在项目协同后实现。三项都成立时，这组项目适合按项目集管理；若只是并列推进、各自交付，按项目清单管理更合适。
初次搭建时字段填不全，应该先补哪些？
先保证结构判断所需的最小字段：总览表的项目集名称、共同目标、预期收益、起止时间、项目集负责人，以及明细表的项目编号、项目名称、项目负责人、所属阶段、交付物、与其他项目的依赖。这组字段能回答“为什么把这些项目放在一起、它们如何相互支撑”。收益度量方式、治理机构、审批节点、依赖类型、关键里程碑和状态可以随后补充，其中收益度量方式建议在进入收益跟踪阶段前补齐，否则收益无法验收。
项目间依赖很多时，明细表怎么填才不混乱？
依赖字段只记录对交付有实质影响的关系，写清依赖的项目编号和具体内容，例如“依赖 P-02 提供接口规范”。依赖类型统一使用输入依赖、输出依赖、双向依赖三种取值，同一行涉及多个对象时分别注明。依赖密集的项目集，建议在评审时按依赖类型筛出关键路径，重点跟踪被多个项目依赖的交付物及其里程碑。日常协作中的一般沟通不必全部记为依赖，否则结构图会失去判断价值。
结构图更新后，历史版本还有必要保留吗？
有必要。依赖判断和收益目标调整往往需要回溯当时的依据，保留历史版本可以说明某次里程碑变更或项目退出的原因。建议在结构图文档中设置变更记录区，记录变更日期、变更字段、变更前后内容、变更原因、提出人和确认人，每次评审后形成新版本。这样在收益验收或治理复盘时，能够对照结构图的演变过程解释决策。
结构图放在文档里，如何避免和执行进度脱节？
关键是让结构图中的项目、依赖、里程碑和状态有持续更新的承载位置。ONES Plan 提供多项目总览与自定义项目属性，可查看多项目数据集合并从多维度掌握进度；其甘特图支持制定项目里程碑、多时间跨度查看进度，并可监控及规划 ONES Project 中的相关项目和迭代。结构图文档可放在 ONES Wiki 中，页面组关联项目后，需求与文档互相对应，文档还能嵌入任务进度与报表。具体版本与部署差异需按实际所购版本核验。
