项目计划编制需要把“做什么、先后顺序、谁来做、何时验收”放进同一套结构。本文给出一套可直接复制填写的模板框架：活动清单、依赖关系、资源分配、里程碑和基线记录五张表，以活动编号为主键互相引用。ONES 可作为承载工作项、依赖、里程碑与基线的工具方向，下文以模板填写为主。
要点总览（TL;DR）
- 这套模板由活动清单、依赖关系、资源分配、里程碑和基线记录五张表组成，以活动编号为主键互相引用，先填活动清单再依次补其余各表。
- 活动编号建议按“阶段码-序号”编码且不复用；依赖只记录真实约束，提前量与滞后量需在模板中固定正负号含义。
- 资源投入在投入比例与工时之间选一种主口径，人员未定时保留角色、人员列标记待定；里程碑验收标准要写成可判定的条件。
- 必填字段以“缺了就无法排顺序、分配责任或验收”为判定标准，小项目可压缩里程碑数量、简化基线表，但版本号必须对应计划快照。
- 计划变更按先活动、再依赖与资源、后里程碑的顺序更新；范围变更、关键里程碑日期调整或资源结构重大变化时才重设基线，日常进度更新不触发。
可复制的项目计划编制空白模板
这套框架由四张计划表和一张基线记录表组成。活动清单是主表，其余各表通过活动编号引用它；里程碑表通过关联活动编号回指具体工作，基线表则记录整份计划被批准时的版本。复制到表格软件或在线文档后，先填活动清单，再依次补依赖、资源和里程碑，最后在计划获批时登记基线。
表一：活动清单
| 活动编号 | 活动名称 | 负责人 | 工期（天） | 产出物 | 状态 |
|---|---|---|---|---|---|
表二：依赖关系
| 前置活动编号 | 后置活动编号 | 依赖类型 | 提前/滞后量 | 说明 |
|---|---|---|---|---|
表三：资源分配
| 活动编号 | 角色 | 人员 | 投入比例或工时 | 可用时间 |
|---|---|---|---|---|
表四：里程碑
| 里程碑编号 | 名称 | 目标日期 | 验收标准 | 关联活动编号 |
|---|---|---|---|---|
表五：基线记录
| 基线版本 | 批准日期 | 批准人 | 变更说明 |
|---|---|---|---|
表间引用规则只有一条主线：活动编号是主键。依赖表的前置、后置两列都填活动编号；资源表的每一行对应一个活动编号；里程碑表的“关联活动编号”列出该里程碑覆盖的活动，多个编号用逗号分隔；基线表记录的是某一时点整份计划的快照，版本号与批准日期成对出现。填写时先保证活动编号不重复，其余各表的引用才有意义。
每张表的字段说明与填写口径
字段口径决定模板能否长期使用。下面按表逐项说明含义、取值方式和常见错误，填写时可直接对照。
| 字段 | 含义 | 取值示例 | 常见错误 |
|---|---|---|---|
| 活动编号 | 活动的唯一标识，建议“阶段码-序号” | D2-03 | 同一编号出现两次；中途改号导致引用断裂 |
| 活动名称 | 动宾结构描述一项可交付的工作 | 完成接口联调 | 写成部门名或笼统的“推进项目” |
| 工期 | 该活动预计占用的工作日 | 3 | 把自然日与工作日混用 |
| 产出物 | 活动结束时可见的成果 | 联调记录与问题清单 | 只写“完成”，无法核验 |
| 依赖类型 | 前后置活动之间的约束方式 | 完成—开始 | 所有依赖一律写完成—开始，掩盖并行关系 |
| 提前/滞后量 | 相对标准依赖的偏移天数 | 滞后 2 天 | 正负号含义不统一，团队理解相反 |
| 投入比例 | 某人员在该活动上的时间占比 | 50% | 同一人多个活动比例之和超过 100% 未察觉 |
| 工时 | 该活动预计消耗的人时 | 24 人时 | 与工期混为一谈 |
| 验收标准 | 判断里程碑达成的可核对条件 | 评审通过且缺陷清零 | 只写“完成上线” |
| 基线版本 | 计划获批时的版本标识 | V1.0 | 每次小改动都升版本，基线失去对照意义 |
编号、依赖与提前滞后量
活动编号建议按分解维度编码，例如按阶段用 D1、D2 前缀，按交付物用模块缩写，序号从 01 起。编号一经使用不再复用，活动取消时保留编号并标注状态，避免依赖表出现指向空号的引用。
依赖类型常用四种：完成—开始表示前置完成后后置才能开始，适合评审通过再开发这类硬约束；开始—开始表示两项活动可同时启动，适合设计与环境准备并行；完成—完成表示两项活动需同时收尾；开始—完成较少使用，多出现在交接场景。只记录真实存在的约束，把“习惯上先做 A 再做 B”写成依赖，会让计划失去并行空间。
提前量与滞后量用于表达偏移：前置完成后需等待 2 天才能开始，记为滞后 2 天；后置活动可提前 3 天介入，记为提前 3 天。团队需在模板说明中固定正负号含义，并在依赖表“说明”列写清原因，例如“等待环境审批”。
资源口径与里程碑验收
投入比例和工时是两种口径，选择取决于用途。人员相对稳定、需要观察谁在哪些活动上过载时，用投入比例更直观；需要核算人力成本或对外报价时，用工时更便于汇总。同一项目内建议只用一种主口径，另一种作为辅助列，避免两套数字互相矛盾。资源表“可用时间”填写该人员在该活动期间的可用区间，遇到休假或兼职需单独标注。
里程碑验收标准要写成可判定的条件，包含对象、动作和判定方式，例如“需求文档经客户签字确认”“核心接口压测通过且错误率低于约定阈值”。只写日期不写交付物，里程碑就退化为日历标记；关联活动编号则说明这个节点由哪些工作支撑，便于节点延期时快速定位原因。
必填与选填字段的划分
必填字段的判定标准是：缺少它，计划无法排顺序、无法分配责任或无法验收。其余字段可以延后补充，但要在模板中留出位置并标注待定状态。
| 表 | 必填字段 | 可延后或选填 | 精简规则 |
|---|---|---|---|
| 活动清单 | 活动编号、活动名称、负责人、工期 | 产出物、状态 | 启动阶段产出物可先写类型，执行前补具体成果 |
| 依赖关系 | 前置活动编号、后置活动编号、依赖类型 | 提前/滞后量、说明 | 无偏移时提前滞后量填 0；说明列仅对非默认依赖填写 |
| 资源分配 | 活动编号、角色 | 人员、投入比例或工时、可用时间 | 人员未定时角色必填、人员留空并标记“待定” |
| 里程碑 | 里程碑编号、名称、目标日期、验收标准 | 关联活动编号 | 验收标准不可省；关联活动可在活动清单稳定后补 |
| 基线记录 | 基线版本、批准日期 | 批准人、变更说明 | 小项目可只记版本与日期，变更说明在重设基线时补 |
依赖表不必全量记录。跨阶段、跨团队、涉及外部交付的依赖必须记录；同一负责人连续完成的两项活动，若顺序调整不影响交付，可省略依赖行。资源表在人员未定时，保留角色和活动编号，人员列写“待定”，投入比例可先按经验估算并标注“暂估”，待人员确定后替换。里程碑在小项目中可压缩到三至五个，覆盖启动、关键交付和验收即可，数量过多会让节点失去区分度。基线表在小型项目中可简化为版本号加批准日期两列，但版本号必须与计划快照对应，不能只写“最终版”。
完整填写示例：一次小型交付项目的计划框架
以下为演示情景：某团队为内部客户交付一套数据看板，周期约六周，参与人员包括项目经理、两名开发、一名设计。示例用于说明五张表如何联动，数字为示意值。
活动清单填写结果
| 活动编号 | 活动名称 | 负责人 | 工期（天） | 产出物 | 状态 |
|---|---|---|---|---|---|
| D1-01 | 确认指标口径与数据来源 | 项目经理 | 3 | 指标口径确认单 | 已完成 |
| D1-02 | 完成看板原型设计 | 设计 | 4 | 原型稿 | 进行中 |
| D2-01 | 搭建数据接入与清洗流程 | 开发甲 | 6 | 数据接入脚本 | 未开始 |
| D2-02 | 开发看板页面与图表 | 开发乙 | 8 | 看板页面 | 未开始 |
| D3-01 | 联调与数据核对 | 开发甲 | 3 | 联调记录 | 未开始 |
| D3-02 | 客户验收与培训 | 项目经理 | 2 | 验收单与培训记录 | 未开始 |
依赖关系填写结果
| 前置活动编号 | 后置活动编号 | 依赖类型 | 提前/滞后量 | 说明 |
|---|---|---|---|---|
| D1-01 | D1-02 | 完成—开始 | 0 | 口径确认后才能定原型内容 |
| D1-01 | D2-01 | 完成—开始 | 0 | 数据来源确定后接入 |
| D1-02 | D2-02 | 完成—开始 | 0 | 原型确认后开发页面 |
| D2-01 | D3-01 | 完成—开始 | 0 | 数据流程就绪后联调 |
| D2-02 | D3-01 | 完成—开始 | 0 | 页面完成后联调 |
| D3-01 | D3-02 | 完成—开始 | 滞后 1 天 | 留出问题修复时间 |
按上述依赖串联，D1-01 → D1-02 → D2-02 → D3-01 → D3-02 构成一条较长的路径，D2-01 与 D2-02 可并行，联调需两者都完成。这条路径即示例中的关键路径，任何一环延期都会推迟验收节点。
资源分配填写结果
| 活动编号 | 角色 | 人员 | 投入比例或工时 | 可用时间 |
|---|---|---|---|---|
| D1-01 | 项目经理 | 张敏 | 50% | 第 1 周 |
| D1-02 | 设计 | 李然 | 80% | 第 1–2 周 |
| D2-01 | 开发 | 王凯 | 100% | 第 2–3 周 |
| D2-02 | 开发 | 陈雨 | 100% | 第 2–4 周 |
| D3-01 | 开发 | 王凯、陈雨 | 各 50% | 第 4 周 |
| D3-02 | 项目经理 | 张敏 | 30% | 第 5 周 |
里程碑与基线填写结果
| 里程碑编号 | 名称 | 目标日期 | 验收标准 | 关联活动编号 |
|---|---|---|---|---|
| M1 | 方案确认 | 第 2 周末 | 指标口径确认单与原型稿经客户签字 | D1-01, D1-02 |
| M2 | 功能就绪 | 第 4 周末 | 数据接入与页面开发完成，自测通过 | D2-01, D2-02 |
| M3 | 验收交付 | 第 5 周末 | 联调问题关闭，客户签署验收单 | D3-01, D3-02 |
| 基线版本 | 批准日期 | 批准人 | 变更说明 |
|---|---|---|---|
| V1.0 | 项目启动后第 3 个工作日 | 项目发起人 | 初始计划获批，含上述四表内容 |
五张表的联动关系在示例中很直接：M1 的达成依赖 D1-01 和 D1-02 完成，这两项活动的负责人和投入来自资源表；D3-02 的滞后量解释了 M3 为何排在第 5 周末；V1.0 基线保存的是这一整套安排，后续任何调整都与它对照。
模板的调整与维护方法
计划建立后，模板的价值在于持续可用。维护的核心是保持引用完整、基线可信，并让字段随项目实际需要增减。
变更时的更新顺序
计划调整按“先活动、再依赖与资源、后里程碑”的顺序处理。新增或取消活动时先改活动清单并分配编号，再检查依赖表中是否有指向该编号的行需要增删，然后同步资源分配，最后确认里程碑的关联活动与目标日期是否仍成立。顺序颠倒容易出现依赖指向已删除活动、资源挂在空活动上的情况。
基线重设的触发条件
基线在计划首次获批时建立。出现范围变更、关键里程碑日期调整、资源结构重大变化时，才需要重设基线；日常的任务进度更新不触发重设。重设时登记新版本号、批准日期、批准人和变更说明，旧版本保留可查，便于对比差异。审批动作由项目发起人或约定的决策人完成，避免执行者自行改基线导致对照失效。
字段增删与跨项目复用
字段增删遵循两条原则：新增字段先确认有明确使用场景和填写人，避免字段堆积后无人维护；删除字段前检查是否被其他表引用或用于报表统计。跨项目复用时，保留活动编号规则、依赖类型取值、里程碑验收标准格式和基线版本规则，替换项目名称、具体活动、人员与日期。行业或交付类型差异较大时，可保留框架、替换示例行。
维护责任与检查节奏
模板维护建议指定一名责任人，通常由项目管理办公室成员或资深项目经理担任。检查节奏可设为每周核对一次引用完整性，包括依赖表是否存在空引用、资源表是否有未分配人员的活动、里程碑关联活动是否仍有效；每个阶段结束时复核一次字段适用性，把长期空置的字段标记为选填或移出模板。
当计划要素需要在团队内共享并持续跟踪时，可考虑用 ONES 承载：其项目计划支持按目标、交付物或阶段分解工作，任务可设置前后置依赖，里程碑用于标记重要时间点与决策点，计划与里程碑基线支持对比执行偏差并追溯版本变更；资源侧可通过工时日历与饱和度报表观察投入情况。是否采用工具承载，取决于团队规模与协作频率，模板本身在表格中同样可以运行。
常见问题
活动编号中途需要调整时，依赖表和资源表怎么跟着改？
活动编号是各表引用的主键，改号会牵动依赖表的前置、后置两列，资源表的每一行，以及里程碑表的关联活动编号。较稳妥的做法是编号一经使用不再变更：活动取消时保留编号并标注状态，新增活动另起新号。确实需要调整编码规则时，按活动清单、依赖表、资源表、里程碑表的顺序逐表替换，改完后核对依赖表是否存在指向空号的引用、资源表是否有挂在旧编号上的行。
团队习惯用自然日沟通工期，模板里应该填哪种？
模板中的工期按工作日填写，并在模板说明中写明这一口径，避免自然日与工作日混用导致排期偏差。如果团队对外沟通使用自然日，可在活动清单中增加一列自然日估算作为辅助，但排顺序和算关键路径仍以工作日为准。遇到法定假日或团队统一休假期，在资源表的“可用时间”列单独标注，比直接改工期更便于追溯。
里程碑和基线都涉及时间点，两者在模板里如何区分？
里程碑是计划中的目标节点，描述某个时点应达成的交付物和验收标准，属于计划内容本身；基线是整份计划被批准时的版本快照，记录版本号、批准日期和批准人。里程碑会随计划调整而变化，基线则用于对照变化前后的差异。填写时里程碑表放在计划部分，基线表单独记录，重设基线时在变更说明中写清哪些里程碑日期发生了调整。
小项目人手少，五张表能否合并或省略？
可以精简，但引用关系要保留。活动清单和里程碑表建议保留，前者是主键来源，后者承载验收节点；依赖表在活动少于十项、顺序基本线性时可只记录跨阶段依赖；资源表在人员固定且全职投入时，可只保留活动编号、角色、人员三列；基线表可简化为版本号加批准日期两列。合并表格时，活动编号仍需唯一，否则后续追加依赖或资源时无法对应。
计划执行一段时间后出现延期，应该先改模板还是先重设基线？
先判断延期是否改变了计划本身。若只是某项活动实际进度落后于原计划，属于执行偏差，按项目进度管理的做法跟踪和纠偏，模板中的活动状态照常更新，基线保持不变。若延期导致范围变更、关键里程碑日期调整或资源结构重大变化，才按先活动、再依赖与资源、后里程碑的顺序修改计划，然后由约定的决策人批准重设基线并登记变更说明。两类情况的处理路径不同，混在一起会让基线失去对照意义。
