项目计划模板的核心是一张可填写的计划表：以工作项为行，覆盖阶段、负责人、起止时间、依赖、交付物、验收标准和状态等字段，并配套字段说明、必填与选填规则和一份完整填写示例。先复制空白表，再按字段说明逐项填写，最后用示例对照检查，即可形成一份可执行、可交接的项目计划。本文交付空白表、字段口径、必填规则、填写范例与维护方法，示例中的项目信息均为演示情景。
要点总览（TL;DR）
- 项目计划模板由基本信息区和工作项明细表两部分组成，明细表以工作项为行，覆盖阶段、负责人、起止日期、前置依赖、交付物、验收标准等字段。
- 工作项、负责人、起止日期、交付物、验收标准为必填；工期、前置依赖、状态、备注为选填，字段暂缺时用“待定”等标注，避免留白被误读。
- 填写时统一日期格式，前置依赖只指向表中已有序号，验收标准写成可核对的条件；文中的六周审批系统示例可逐行对照。
- 模板按项目规模裁剪字段，计划变更时更新受影响行并保留已完成项的历史记录，通过版本号管理复用。
可复制空白项目计划模板
下面这张表分两部分：计划基本信息区用于交代项目背景和版本，工作项明细表用于逐行拆解任务。复制到文档或表格工具后，先填基本信息，再从明细表第一行开始填写。阶段分组行只写阶段名称，用于呈现工作分解结构（WBS）的层级；其下的工作项行填写具体任务。
一、计划基本信息区
| 项目名称 | 项目目标 | 计划周期 | 模板版本 | 编制人 | 编制日期 |
|---|---|---|---|---|---|
二、工作项明细表
| 序号 | 阶段 | 工作项 | 负责人 | 开始日期 | 结束日期 | 工期（天） | 前置依赖 | 交付物 | 验收标准 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | |||||||||||
| 2 | |||||||||||
| 3 | |||||||||||
| 4 | |||||||||||
| 5 |
行数按项目实际需要增减。阶段分组行可以写成“阶段一：需求与方案”“阶段二：开发与联调”等，也可以单独用一列“阶段”标注，两种方式选一种并全表统一。工作项拆到“一个人能在一段连续时间内完成、结果可检查”的粒度即可，过粗难以跟踪，过细会增加维护成本。
模板字段说明：每个字段填什么
字段说明的作用是让不同人填出的表口径一致。下表逐字段给出含义和填写口径，填写时遇到拿不准的格子，回到这张表对照。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 序号 | 工作项在表中的唯一编号 | 从1连续编号；插入新行时顺延，不复用已删除的编号 |
| 阶段 | 工作项所属的计划阶段或交付物分组 | 与基本信息区的计划周期对应，阶段名称全表统一 |
| 工作项 | 一项可分配、可完成的具体任务 | 用“动词+对象+结果”描述，如“完成接口联调并输出联调记录” |
| 负责人 | 对该工作项结果负责的人 | 填一个人名或岗位，不填多人；协作人写入备注 |
| 开始日期 | 计划开始执行的日期 | 统一格式，如2025-03-03；全表使用同一格式 |
| 结束日期 | 计划完成的日期 | 格式同开始日期；结束日期不早于开始日期 |
| 工期（天） | 该工作项占用的计划天数 | 按工作日或自然日计算需在表头注明；与起止日期保持自洽 |
| 前置依赖 | 必须先完成才能开始本项的工作 | 填写被依赖工作项的序号，如“3”；多个依赖用逗号分隔，如“3,4” |
| 交付物 | 本项完成后产出的可交接成果 | 写具体物件或文件，如“接口文档v1”“测试报告”，不写“完成开发”这类动作 |
| 验收标准 | 判断本项是否完成的依据 | 写成可判断的条件，如“接口文档覆盖全部12个接口并通过评审” |
| 状态 | 工作项当前所处的计划状态 | 统一取值，如未开始、进行中、已完成、已阻塞；计划阶段默认“未开始” |
| 备注 | 补充说明 | 写协作人、风险提示、待确认事项等，不重复其他字段内容 |
时间与依赖字段最容易填乱，把握两条口径即可：日期全表统一格式，工期与起止日期互相校验；前置依赖只指向表中已有序号的工作项，指向表外或指向自己都视为填写错误。验收标准要写成“谁看都能判断是否达成”的条件，避免“基本完成”“效果良好”这类无法核对的表述。
当计划表进入协作工具承载时，这些字段会对应到工作项属性。以ONES为例，其瀑布项目管理方案支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点或决策点。这意味着表中的“阶段”“前置依赖”等字段可以在工具中变成可联动的工作项关系，减少手工维护依赖序号的工作量。
必填与选填：哪些字段不能空
必填字段决定这张表能否被他人接手执行。判断标准是：缺了它，负责人无法开始工作，或验收人无法判断结果。按此标准，工作项、负责人、开始日期、结束日期、交付物、验收标准为必填；序号作为行标识也应始终填写。
| 字段 | 必填/选填 | 理由或适用场景 |
|---|---|---|
| 序号 | 必填 | 依赖字段靠序号指向，缺失会导致依赖无法表达 |
| 阶段 | 必填 | 用于分组和汇总进度；单阶段小项目可统一填同一阶段名 |
| 工作项 | 必填 | 表的主体，缺失则整行无意义 |
| 负责人 | 必填 | 无人负责的工作项无法推进和交接 |
| 开始日期、结束日期 | 必填 | 排期与依赖判断的基础；确未定档时按下方规则标注 |
| 交付物 | 必填 | 交接和验收的对象 |
| 验收标准 | 必填 | 没有判断条件，完成与否只能靠口头确认 |
| 工期（天） | 选填 | 起止日期已能推算工期时可不填；需要按工时排布资源时填写 |
| 前置依赖 | 选填 | 无前置工作的工作项留空或写“无”；有依赖时必须填写 |
| 状态 | 选填 | 计划编制阶段可统一默认“未开始”，执行开始后再更新 |
| 备注 | 选填 | 有协作人、风险或待确认事项时填写 |
字段暂缺时不要留白。留白会被读成“没有要求”，而不是“还没确定”。推荐三种标注：日期未定写“待定（预计X月确认）”；验收标准未定写“待评审后补充”；依赖未确认写“待确认，暂按序号X”。标注本身也是待办，计划评审时逐条清零。选填字段留空则表示“本项目不适用”，与“待定”区分开。
填写示例：一份完整的项目计划表
以下为演示情景：某团队计划在六周内上线一个内部审批系统的第一个可用版本。示例中的名称、日期、人名均为虚构，仅用于示范字段写法。
基本信息区
| 项目名称 | 项目目标 | 计划周期 | 模板版本 | 编制人 | 编制日期 |
|---|---|---|---|---|---|
| 内部审批系统一期 | 上线请假与报销两类审批流程，覆盖50人试用 | 2025-03-03至2025-04-11 | v1.0 | 李敏 | 2025-02-28 |
工作项明细表
| 序号 | 阶段 | 工作项 | 负责人 | 开始日期 | 结束日期 | 工期（天） | 前置依赖 | 交付物 | 验收标准 | 状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 需求与方案 | 梳理请假与报销审批规则并形成需求说明 | 王磊 | 2025-03-03 | 2025-03-07 | 5 | 无 | 需求说明书v1 | 两类流程的节点、审批人、驳回规则全部写明，经业务方签字确认 | 未开始 | 业务方接口人：行政部张宁 |
| 2 | 需求与方案 | 完成系统方案设计与评审 | 陈卓 | 2025-03-10 | 2025-03-12 | 3 | 1 | 方案设计文档v1、评审记录 | 评审会通过，遗留问题不超过3项且均有责任人和期限 | 未开始 | |
| 3 | 开发与联调 | 完成审批流程引擎开发 | 赵凯 | 2025-03-13 | 2025-03-26 | 10 | 2 | 流程引擎代码、单元测试报告 | 两类流程可配置跑通，单元测试通过率100% | 未开始 | |
| 4 | 开发与联调 | 完成前端页面开发并与后端联调 | 周琳 | 2025-03-17 | 2025-03-28 | 10 | 2 | 前端页面、联调记录 | 请假与报销各主流程页面可操作，联调问题清单全部关闭 | 未开始 | 与序号3并行，联调需等接口就绪 |
| 5 | 测试与上线 | 执行系统测试并输出测试报告 | 孙倩 | 2025-03-31 | 2025-04-04 | 5 | 3,4 | 测试用例、测试报告 | 用例执行率100%，严重及以上缺陷清零 | 未开始 | |
| 6 | 测试与上线 | 完成50人试用上线与培训 | 李敏 | 2025-04-07 | 2025-04-11 | 5 | 5 | 上线通知、操作手册 | 50人账号开通并完成一次真实审批，操作手册发放到人 | 未开始 | 上线决策点：4月7日评审 |
对照检查这份示例：序号4的前置依赖写“2”而非“3”，因为前端开发在方案评审后即可启动，与后端开发并行；序号5依赖“3,4”两项，体现测试必须等前后端都完成。验收标准均写成可核对的条件，如“严重及以上缺陷清零”“50人账号开通并完成一次真实审批”。工期与起止日期按工作日计算，表头已注明口径。
模板的调整与维护方法
模板不是一次定稿就固定不变。项目类型不同，字段取舍不同；计划一旦变更，表也要同步更新，否则它很快会变成一份没人看的旧文档。
按项目规模与类型裁剪字段
- 两周以内的小项目：保留必填字段即可，阶段可合并为一列，工期与状态可省略。
- 跨团队、多依赖的项目：保留全部字段，并增加“里程碑”标记行，用于标注关键决策点。
- 研究探索类项目：交付物和验收标准可能前期不确定，可先写“待第X周评审后确定”，评审后补齐，不留白。
- 裁剪原则：删字段前确认没有下游用途；被删字段的信息如果仍需交接，移入备注，不直接丢弃。
计划变更时的更新规则
- 更新：受影响工作项的起止日期、工期、前置依赖、状态；新增工作项顺延编号。
- 保留：已完成工作项的原计划日期与验收标准不改写，实际完成情况记入备注或另设实际日期列。
- 留痕：每次整体调整提升模板版本号（如v1.0→v1.1），并在基本信息区或变更记录中写明调整原因和日期。
模板的版本与复用
把空白表存为团队的标准模板文件，命名包含版本号和适用范围，例如“项目计划模板_v1.1_通用”。新项目从最新版本复制，不直接改原模板；项目结束后回收填写中的问题，汇总后发布下一版。若团队使用ONES Wiki，可利用页面模板库一键创建制式化文档模板，让计划表以统一格式沉淀；文档还可关联项目任务、嵌入任务进度与报表，使计划表与执行数据保持在同一处。计划与执行的偏差对比、基线管理等属于项目进度管理的范围，可在计划定稿后另行处理。
常见问题
项目计划模板里的“前置依赖”应该填序号还是工作项名称？
填被依赖工作项的序号，例如“3”；有多个依赖时用逗号分隔，如“3,4”。用序号的好处是唯一、简短，工作项名称调整后依赖关系仍然成立。前提是全表序号连续且不复用已删除的编号，否则依赖会指向错误行。若某项没有前置工作，留空或写“无”，不要指向自己或表外任务。
计划周期还没定下来，起止日期可以先空着吗？
不建议直接空着。起止日期属于必填字段，留白容易被读成“没有时间要求”。确未定档时写“待定（预计X月确认）”，并在计划评审时逐条落实。如果只有结束日期确定、开始日期待定，同样标注待定原因和确认时间。这样表格既保留了排期位置，也把不确定性变成了可见的待办事项。
小项目用这张模板会不会字段太多？
可以裁剪。两周以内、单人为主的小项目保留必填字段即可，阶段合并为一列，工期和状态可以省略。跨团队、多依赖的项目则建议保留全部字段，并增加里程碑标记行。裁剪前确认被删字段的信息没有下游用途；如果仍需交接，把内容移入备注，不直接丢弃。
计划执行中发生变更，模板里的历史数据要改吗？
已完成工作项的原计划日期和验收标准保留不改，实际完成情况记入备注或另设实际日期列；受影响但未完成的工作项更新起止日期、工期、前置依赖和状态。整体调整时提升模板版本号并写明调整原因和日期，便于后续追溯。计划与执行的偏差对比、基线管理属于项目进度管理的范围，可在计划定稿后另行处理。
把这张计划表放进协作工具管理，有什么实际好处？
表格进入协作工具后，字段可以变成工作项属性，依赖关系由工具联动，减少手工维护序号的工作量。以ONES为例，其瀑布项目管理方案支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要时间点或决策点。若团队使用ONES Wiki，还可通过页面模板库一键创建制式化文档模板，并让文档关联项目任务、嵌入任务进度与报表。
