项目计划模板的填写顺序可以按“目标—范围—里程碑—任务—责任—时间—依赖—验收—风险”推进：先写清项目要交付什么，再把交付物拆成里程碑，把里程碑拆成可分配的任务，为每项任务补齐负责人、起止时间、前置依赖和验收标准，最后记录风险与变更。下面给出一套可直接复制的空白表格，并逐字段说明填写口径、必填取舍和完整示例。
要点总览（TL;DR）
- 模板由项目基本信息区、里程碑表、任务计划表、风险与变更记录表组成，填写顺序按目标、里程碑、任务、责任、时间、依赖、验收、风险推进。
- 负责人、起止时间、验收标准三项不建议删除：缺负责人无人主责，缺时间无法判断进度，缺验收标准完成状态易起争议。
- 里程碑是检查点，任务是可分配的工作；任务的前置依赖用任务编号引用，开始时间早于前置任务结束时间即说明计划存在冲突。
- 小型项目可精简为基本信息加任务计划表，跨部门项目建议保留全部字段并补充交接确认人。
- 计划基线确定后，调整通过变更记录体现，不直接覆盖原计划；状态按项目例会节奏更新，验收标准调整走变更流程。
可复制空白项目计划模板
这套模板由项目基本信息区加三张表组成：里程碑表用于把控关键节点，任务计划表用于日常跟踪，风险与变更记录表用于留痕。复制到表格工具后，先填基本信息区，再自上而下填写三张表。
项目基本信息区
| 字段 | 填写内容 |
|---|---|
| 项目名称 | |
| 项目目标 | |
| 项目负责人 | |
| 计划周期 | 开始日期： 结束日期： |
| 模板版本 |
里程碑表
| 里程碑 | 交付物 | 计划完成时间 | 负责人 | 状态 |
|---|---|---|---|---|
任务计划表
| 任务编号 | 任务名称 | 所属里程碑 | 负责人 | 开始时间 | 结束时间 | 前置依赖 | 验收标准 | 状态 |
|---|---|---|---|---|---|---|---|---|
风险与变更记录表
| 编号 | 描述 | 影响 | 应对措施 | 责任人 | 状态 |
|---|---|---|---|---|---|
每个字段填什么：字段说明与填写口径
模板能否用起来，取决于每一格写到什么颗粒度。字段说明的核心原则是：让没有参与讨论的人读一遍，也能判断这项工作由谁做、何时完成、做到什么程度算完成。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 项目目标 | 项目结束时要达成的结果 | 写成可判断完成的结果，包含对象和完成条件，例如“上线订单审批功能，覆盖3类审批场景并通过验收测试” | 写成“提升效率”“做好系统建设”等口号 |
| 里程碑 | 项目中的检查点或决策点 | 对应一个可交付成果的完成时点，数量控制在能覆盖关键阶段的范围内 | 把日常任务当里程碑，导致节点过多 |
| 任务名称 | 可分配给个人的工作单元 | 用“动词+对象”描述，一项任务通常由一名负责人主责 | 任务过大无法估算，或细到无法跟踪 |
| 负责人 | 对该项结果负责的人 | 填具体人名，不填部门或“相关同事” | 多人并列负责，实际无人负责 |
| 开始/结束时间 | 任务的计划起止日期 | 按工作日填写，结束时间指完成并通过验收的日期 | 只填截止日，不填开始日，无法判断排期冲突 |
| 前置依赖 | 本任务开始前必须完成的事项 | 填任务编号或明确的外部条件，无依赖时写“无” | 留空，导致依赖关系无法识别 |
| 验收标准 | 判断任务完成的条件 | 写成可核对的结果，如“文档通过评审并归档”“接口联调通过并留存测试记录” | 写“完成即可”“质量达标”等无法核对的表述 |
| 状态 | 任务或里程碑当前进展 | 统一取值：未开始、进行中、已完成、阻塞、已取消 | 各人自造状态词，统计口径不一致 |
里程碑与任务的区别需要在填写时反复确认：里程碑是检查点，回答“到了这个时间点应该交付什么”；任务是可分配的工作，回答“谁在什么时间做什么”。一个里程碑下通常对应若干任务，任务全部完成并通过验收，里程碑才可标记完成。
起止时间与前置依赖要配合填写。前置依赖决定了任务最早可以开始的时间，结束时间则应留出评审和返工余量。若某项任务的开始时间早于其前置任务的结束时间，说明计划本身存在冲突，需要在填写阶段就调整。
必填与选填：哪些字段不能空
模板字段并非越多越好。必填字段保证计划可跟踪、可追责；选填字段按项目复杂度和协作范围决定是否启用。判断标准是：缺少该字段，是否会导致无法判断谁做、何时做、做到什么程度。
| 字段 | 建议 | 缺失后果 | 适用场景 |
|---|---|---|---|
| 项目名称、项目目标、负责人、计划周期 | 必填 | 无法界定项目边界和责任主体 | 所有项目 |
| 里程碑、交付物、计划完成时间 | 必填 | 无法把控关键节点 | 所有项目 |
| 任务名称、负责人、起止时间、状态 | 必填 | 任务无法分配和跟踪 | 所有项目 |
| 验收标准 | 必填 | 完成与否依赖主观判断 | 所有项目；小型项目可简化为一句可核对条件 |
| 前置依赖 | 建议必填 | 排期冲突和等待环节被隐藏 | 存在跨任务、跨团队交接的项目 |
| 任务编号 | 选填 | 依赖引用不便，但不影响跟踪 | 任务数量较多、需要互相引用时启用 |
| 风险与变更记录 | 建议必填 | 风险和变更无留痕，复盘缺依据 | 周期超过一个月或涉及多方协作的项目 |
| 模板版本 | 选填 | 多版本并行时不易区分 | 模板被多个项目复用时启用 |
小型项目可以精简为“基本信息+任务计划表”两张表，里程碑合并进任务表的阶段分组，风险记录只在出现风险时补填。跨部门项目则建议保留全部字段，并额外明确交接点和双方确认人，因为跨团队的信息不对称更容易造成延误。
精简的边界在于：负责人、起止时间、验收标准三项不建议删除。删掉负责人，任务无人主责；删掉时间，进度无法判断；删掉验收标准，完成状态容易产生争议。扩展字段时也应遵循同一原则，新增字段必须对应一个实际的管理动作，否则只会增加填表负担。
填写示例：一个完整项目计划表
以下为演示情景，用于说明字段之间如何配合，项目背景为虚构。某公司计划在两个月内上线内部报销系统的审批模块，项目负责人为项目经理，参与方包括开发、测试和财务部门。
基本信息区填写为：项目名称“报销系统审批模块上线”，项目目标“上线报销审批功能，覆盖差旅、采购、日常报销3类场景，通过财务部门验收”，负责人“项目经理”，计划周期“3月1日至4月30日”，模板版本“v1.0”。
填好的里程碑表
| 里程碑 | 交付物 | 计划完成时间 | 负责人 | 状态 |
|---|---|---|---|---|
| 需求确认 | 审批流程需求说明书（评审通过版） | 3月10日 | 产品负责人 | 已完成 |
| 开发完成 | 审批模块可测试版本 | 4月10日 | 开发负责人 | 进行中 |
| 验收上线 | 验收报告与上线记录 | 4月30日 | 项目经理 | 未开始 |
填好的任务计划表
| 任务编号 | 任务名称 | 所属里程碑 | 负责人 | 开始时间 | 结束时间 | 前置依赖 | 验收标准 | 状态 |
|---|---|---|---|---|---|---|---|---|
| T01 | 梳理三类报销审批流程 | 需求确认 | 产品负责人 | 3月1日 | 3月6日 | 无 | 输出流程图，财务部门确认签字 | 已完成 |
| T02 | 编写需求说明书并组织评审 | 需求确认 | 产品负责人 | 3月7日 | 3月10日 | T01 | 评审会通过，遗留问题闭环 | 已完成 |
| T03 | 开发审批流配置与表单 | 开发完成 | 开发负责人 | 3月11日 | 3月28日 | T02 | 三类场景可走通，提交自测记录 | 进行中 |
| T04 | 接口联调与缺陷修复 | 开发完成 | 开发负责人 | 3月29日 | 4月10日 | T03 | 联调通过，遗留缺陷不超过约定等级 | 未开始 |
| T05 | 编写测试用例并执行验收测试 | 验收上线 | 测试负责人 | 4月11日 | 4月22日 | T04 | 测试报告通过，关键用例全部通过 | 未开始 |
| T06 | 组织财务部门验收并上线 | 验收上线 | 项目经理 | 4月23日 | 4月30日 | T05 | 验收报告签字，上线记录归档 | 未开始 |
填好的风险与变更记录
| 编号 | 描述 | 影响 | 应对措施 | 责任人 | 状态 |
|---|---|---|---|---|---|
| R01 | 财务部门在评审后提出新增一类补贴报销场景 | 开发工作量增加约3个工作日 | 评估后纳入本期范围，T03结束时间顺延，同步更新里程碑 | 项目经理 | 处理中 |
| R02 | 测试环境资源紧张，可能影响联调进度 | T04可能延迟 | 提前一周申请环境，准备备用环境 | 测试负责人 | 已缓解 |
对照字段说明可以看出：T02的验收标准写成了可核对的条件，因此状态可以明确标记为已完成；T04的前置依赖指向T03，排期上不会出现提前开工；R01作为变更记录，同时说明了影响和应对措施，并关联到任务时间的调整。示例中的每个字段都能在字段说明表中找到对应口径。
模板的调整与维护方法
计划表填完只是起点。项目进行中，模板需要承担两件事：记录计划与实际的差异，以及让后续项目能复用一套经过验证的字段结构。
计划基线确定后，原定的里程碑时间和任务排期应作为基线保留，后续调整通过变更记录体现，而不是直接覆盖原计划。每次变更在风险与变更记录表中登记编号、原因、影响范围和调整后的时间，任务表中同步更新状态和日期。这样复盘时可以看清计划偏差来自哪里。
状态与进度的更新节奏建议与项目例会对齐：任务负责人每周更新一次任务状态和实际完成情况，里程碑负责人在节点到期前确认交付物是否通过验收。更新时只改状态和日期，不改验收标准；验收标准需要调整时，按变更流程处理。
模板字段的增删遵循两条原则：新增字段必须对应一个实际的管理动作，例如增加“交接确认人”是因为存在跨团队交接；删除字段前确认该字段没有承担追责或验收依据的作用。字段调整后更新模板版本号，并在版本说明中记录改了什么、为什么改。
模板复用时，建议保留一份标准版作为母版，各项目复制后按复杂度裁剪，避免每个项目各自演化出互不兼容的表格。当计划表需要在多人之间同步任务状态、依赖关系和里程碑进度时，可以把任务、前置依赖和里程碑迁移到协作工具中承载。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段分解计划，为任务设置前后置依赖并用里程碑标记关键时间点；设置计划和里程碑基线后，可以对比计划与执行的偏差并追溯变更细节。表格适合作为填写和评审的载体，工具则适合承担持续的更新与跟踪，两者可以配合使用。
常见问题
项目计划模板里的里程碑和任务应该怎么区分？
里程碑回答“到了这个时间点应该交付什么”，对应一个可交付成果的完成时点或决策点；任务回答“谁在什么时间做什么”，是可以分配给个人的工作单元。填写时先列里程碑，再把每个里程碑拆成若干任务，任务全部完成并通过验收后，里程碑才标记为完成。如果发现某个“里程碑”下面拆不出任务，或者它本身需要某人投入几天时间完成，它更可能是一项任务。
项目规模不大，模板可以删掉哪些字段？
小型项目可以把模板精简为“基本信息+任务计划表”两张表，里程碑合并进任务表的阶段分组，风险记录只在出现风险时补填，任务编号和模板版本也可以暂不启用。负责人、起止时间、验收标准三项建议保留：删掉负责人任务无人主责，删掉时间进度无法判断，删掉验收标准完成与否容易产生争议。精简的判断标准是，缺少该字段是否会导致无法判断谁做、何时做、做到什么程度。
前置依赖填不出来或者暂时不确定怎么办？
没有依赖的任务明确写“无”，不要留空，留空会让读者无法区分“没有依赖”和“还没想清楚”。暂时不确定的依赖，可以先填已知的外部条件，例如“等待财务部门确认口径”，并在风险与变更记录表中登记一条待确认事项，指定跟进人。依赖关系在排期评审时集中核对一遍，比逐条追问效率更高。
计划表填好之后，原定的时间还能改吗？
可以改，建议保留原计划作为基线，调整通过变更记录体现。每次变更在风险与变更记录表中登记编号、原因、影响范围和调整后的时间，任务表中同步更新状态和日期。直接覆盖原计划会让复盘时看不清偏差来自哪里。状态更新建议与项目例会对齐，任务负责人定期更新状态和实际完成情况，里程碑负责人在节点到期前确认交付物是否通过验收。
表格形式的计划表如何支持多人持续更新？
表格适合作为填写和评审的载体，多人持续更新时容易出现版本分散、状态不同步的问题。当计划表需要在多人之间同步任务状态、依赖关系和里程碑进度时，可以把任务、前置依赖和里程碑迁移到协作工具中承载。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段分解计划，为任务设置前后置依赖并用里程碑标记关键时间点；设置计划和里程碑基线后，可以对比计划与执行的偏差并追溯变更细节。表格与工具可以配合使用，前者用于填写和评审，后者承担持续跟踪。
