项目计划表的设计，起点是明确这张表要支持哪些决策，再据此确定字段、层级和更新规则。本文按“用途—字段—步骤—角色—示例—检查”的顺序，给出一套可直接落地的设计方法，适用于项目启动阶段从零建立计划表，也适用于改造现有表格。计划表落地后往往需要在协作工具中维护任务状态和变更记录，ONES可作为这类协作承载的一个方向。
要点总览（TL;DR）
- 先明确计划表要支持的决策和读者，再决定颗粒度：管理层汇报用里程碑级或阶段级，执行跟踪用任务级。
- 采用“项目—阶段—任务”三层行结构，必备字段包括任务名称、负责人、起止时间、前置依赖、交付物、完成标准和状态。
- 按五步推进：收集交付物清单、拆分阶段与任务、填字段排依赖、试填评审、发布基线并约定变更规则。
- 项目负责人定结构与基线，任务负责人填行内容并更新状态，计划管理员维护模板与变更台账，评审角色在基线发布前检查依赖与资源冲突。
- 发布前用检查清单核对字段完整性、依赖逻辑、完成标准可验证性和变更规则，任一阻断项未通过即返工。
先定用途：计划表要回答哪些问题
计划表的价值取决于它能否支撑具体判断。设计前先列出三类读者各自要用它回答的问题，字段和颗粒度由此推导，避免做成一张“什么都有、什么都看不清”的大表。
项目负责人关注整体节奏与风险：哪些阶段即将到期、哪些任务卡在依赖上、关键交付物是否有人负责。执行成员关注自己这一周做什么、前置条件是否具备、完成到什么程度算交付。干系人关注里程碑是否按期、范围有无变化、需要协调的资源在哪里。三类读者的关注点不同，同一张表需要通过筛选视图或分层展示来满足，而不是把所有信息压进一行。
颗粒度按用途选择。面向管理层汇报的计划表做到里程碑级或阶段级即可，行数控制在可一屏浏览的范围；面向执行跟踪的计划表需要到任务级，单个任务的工期建议以天或周为单位，避免细到小时导致维护成本过高。同一项目可以保留一张任务级主表，再按读者生成阶段汇总视图。
更新频率与计划表生命周期绑定。启动阶段确定基线后，计划表进入维护期：执行成员按固定节奏（如每周）更新任务状态，负责人按阶段节点复核整体偏差，干系人按汇报周期查看汇总。计划表在项目收尾时归档，变更历史随表保留，作为后续复盘依据。
需要区分边界：计划表负责把“做什么、谁做、何时做、依赖什么、交付什么”写清楚，属于计划建立；执行过程中偏差如何分析、如何纠偏，属于进度管理；具体任务的排期算法与依赖链调整，属于任务排期与依赖管理。本文只覆盖计划表的设计与建立，后两类问题在相应主题中展开。
计划表的核心字段与层级结构
推荐采用“项目—阶段—任务”三层行结构。项目行承载整体目标与起止时间；阶段行对应可交付的阶段成果，通常与里程碑对齐；任务行是最小执行单元，落到具体负责人。编号规则建议为“项目代号-阶段序号-任务序号”，例如 PRJ01-02-03，便于在会议、文档和工具中互相引用。
必备字段及其填写口径如下表。填写口径一栏用于消除歧义，建议随模板一起下发。
| 字段 | 含义 | 填写口径 | 必填/选填 |
|---|---|---|---|
| 任务名称 | 该行要完成的工作 | 用“动词+对象+结果”描述，如“完成接口联调并输出测试报告”；避免“跟进”“推进”等无法判断完成状态的写法 | 必填 |
| 负责人 | 对该行结果负责的人 | 填一个人，不填团队或多人并列；协作人写入备注 | 必填 |
| 开始时间 | 计划开始日期 | 填写可执行的日期，不写“待定”；未确定时标注“待确认”并列入风险 | 必填 |
| 结束时间 | 计划完成日期 | 与完成标准的验收时点一致，不把缓冲时间隐含在日期里 | 必填 |
| 前置依赖 | 本行开始前必须完成的事项 | 填写被依赖行的编号；无依赖填“无”，不留空 | 必填 |
| 交付物 | 本行完成后产出的具体成果 | 写可指认的对象，如文档、评审记录、可运行版本；避免写“相关材料” | 必填 |
| 完成标准 | 判断本行完成的依据 | 写成可验证的条件，如“评审通过且意见闭环”“测试用例通过率达到约定值” | 必填 |
| 状态 | 当前进展 | 统一取值，如未开始、进行中、已完成、阻塞；不使用自由文本 | 必填 |
辅助字段按项目复杂度选配。优先级用于在资源冲突时排序，建议用高、中、低三档；工作量估算用于判断排期是否可行，单位在模板中统一为人天或人周；备注用于记录协作人、外部依赖和假设条件；变更记录记录基线之后的每次调整，包含变更内容、原因、提出人和确认时间。
常见歧义需要提前约定。负责人与执行人分离时，负责人字段填对结果负责的人；跨阶段任务只在一行中体现，通过依赖关系关联到其他阶段，避免重复建行；状态为“阻塞”时必须同时在备注中写明阻塞原因和解除条件，否则视为填写不合格。
设计步骤：从空白表到可用的计划表
以下五步按顺序执行，每步都有明确的输入、动作、输出和完成标志，便于判断是否可以进入下一步。
步骤一：收集范围与交付物清单
输入是项目立项材料、需求清单和合同或任务书。动作是列出项目需要交付的全部成果，区分对外交付物和内部过程产物，并标注每项交付物的验收方。输出是一份交付物清单。完成标志是清单中的每项交付物都有明确的验收方和大致时间窗口。
步骤二：拆分阶段与任务并设定层级
输入是交付物清单。动作是按交付节奏划分阶段，每个阶段对应一组可验收的成果；再将阶段拆解为任务，单个任务的工期建议控制在一个汇报周期内，超出时继续拆分。输出是带编号的三层行结构。完成标志是每个任务都能落到一个负责人，且不存在跨阶段重复建行。
步骤三：填字段、排依赖、定完成标准
输入是行结构。动作是逐行填写必备字段，先排依赖再核对时间：前置任务结束时间应早于或等于本行开始时间；完成标准逐条写成可验证条件。输出是字段完整的计划表初稿。完成标志是所有必填字段无空缺，依赖关系无循环引用。
步骤四：试填样例并组织评审
输入是初稿。动作是选取一个真实阶段完整试填，检查字段口径是否够用、颗粒度是否合适；组织负责人、执行成员和干系人代表评审，重点核对依赖合理性和资源冲突。输出是评审意见和修订后的计划表。完成标志是评审意见逐条有处理结论，字段口径的争议已写入模板说明。
步骤五：发布基线并约定变更规则
输入是修订后的计划表。动作是确认基线版本，明确变更触发条件（如范围调整、关键依赖失效、里程碑偏移超过约定阈值）、审批人和记录方式。输出是基线版计划表和变更规则说明。完成标志是全体执行成员确认收到基线，变更规则在项目例会上完成宣贯。
角色分工与交付物
计划表的可用性依赖职责清晰。下表列出四类角色的职责、交付物和关键时点，避免出现“表有人建、没人维护”的情况。
| 角色 | 职责 | 交付物 | 关键时点 |
|---|---|---|---|
| 项目负责人 | 确定表结构与颗粒度，确认基线和变更规则 | 基线版计划表、变更规则说明 | 项目启动阶段 |
| 任务负责人 | 填写本人负责任务的字段，尤其是完成标准和交付物；按节奏更新状态 | 任务行内容、状态更新记录 | 计划编制期与每个汇报周期 |
| PMO或计划管理员 | 维护模板与字段口径，汇总变更记录，检查填写质量 | 模板及填写说明、变更台账 | 模板发布时与每次变更后 |
| 评审角色（负责人、执行代表、干系人代表） | 检查依赖逻辑、资源冲突和完成标准可验证性 | 评审意见及处理结论 | 基线发布前 |
分工的关键在于把“填写”和“维护”分开：任务负责人对行内容负责，计划管理员对整体一致性和变更记录负责，项目负责人对基线和规则负责。评审角色不承担日常维护，只在基线发布和重大变更时介入。
计划表进入执行期后，状态更新和变更记录需要在团队共用的协作环境中持续维护。ONES支持以工作项承载任务、以文档承载计划说明和变更记录，使字段、状态与评审结论在同一处对应，减少表格多版本并存带来的口径不一致。具体使用方式按团队现有流程配置即可。
示例：一个迭代项目的计划表片段
以下为演示情景，用于说明字段与层级的填写方式，不代表真实项目数据。背景：某团队开展一个为期六周的版本迭代，范围包括需求确认、开发、测试和发布准备。
| 编号 | 任务名称 | 负责人 | 开始 | 结束 | 前置依赖 | 交付物 | 完成标准 | 状态 |
|---|---|---|---|---|---|---|---|---|
| PRJ01-01 | 阶段一：需求确认 | 项目负责人 | 第1周 | 第2周 | 无 | 需求确认记录 | 需求清单经评审通过 | 已完成 |
| PRJ01-01-01 | 整理需求清单并标注优先级 | 需求负责人 | 第1周一 | 第1周三 | 无 | 需求清单 | 清单覆盖本期全部范围，优先级无空缺 | 已完成 |
| PRJ01-01-02 | 组织需求评审并闭环意见 | 项目负责人 | 第1周四 | 第2周二 | PRJ01-01-01 | 评审记录 | 评审意见逐条有处理结论 | 已完成 |
| PRJ01-02 | 阶段二：开发与自测 | 开发负责人 | 第2周 | 第4周 | PRJ01-01 | 可运行版本 | 自测用例全部执行完毕 | 进行中 |
| PRJ01-02-01 | 完成核心模块开发并提交自测 | 开发负责人 | 第2周三 | 第4周二 | PRJ01-01-02 | 模块代码与自测记录 | 自测用例通过率达到约定值 | 进行中 |
依赖写法上，任务行引用被依赖行的编号，阶段行引用前一阶段编号，形成可追溯的链条。完成标准写成可验证条件，例如“评审意见逐条有处理结论”，而不是“评审完成”。变更记录单独维护，示例如下：变更内容为“PRJ01-02-01 结束时间由第4周一调整为第4周二”，原因为“上游接口文档延迟提供”，提出人为开发负责人，确认时间为第3周三，确认人为项目负责人。该记录保留在变更台账中，不覆盖基线原值。
完成检查：计划表是否可用
发布前按下表逐项核对。任一阻断项未通过，计划表应返工后再发布。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 结构与字段完整性 | 三层结构清晰，必备字段无空缺，编号唯一且可引用 | 存在无负责人的任务行，或必填字段留空 |
| 依赖与时间逻辑 | 前置任务结束时间不晚于本行开始时间，无循环依赖 | 存在循环依赖或时间倒挂 |
| 完成标准可验证 | 每条完成标准可由第三方判断是否达成 | 完成标准为“推进完成”“跟进到位”等无法判断的表述 |
| 更新与变更规则 | 更新频率、变更触发条件、审批人和记录方式已明确并宣贯 | 基线已发布但无变更规则 |
| 读者适配 | 负责人、执行成员、干系人均能通过视图或汇总获取所需信息 | 关键读者无法从表中得到其决策所需信息 |
返工条件同样需要明确：出现任一阻断项即返工；非阻断问题（如个别备注缺失、优先级未填）可限期补齐，不影响基线发布。检查通过后，计划表进入维护期，后续调整按变更规则执行，检查清单本身也随模板一并归档，供下一个项目复用。
常见问题
计划表做到任务级后行数很多，怎么保证不同读者都能用？
保留一张任务级主表作为唯一数据源，再按读者生成视图：项目负责人和干系人看阶段汇总或里程碑视图，执行成员看本人负责任务的筛选视图。关键是字段口径统一，视图只做筛选和汇总，不另建一份平行表格，否则容易出现多版本口径不一致。
任务开始时间暂时无法确定，计划表里应该怎么填？
填写口径中建议不写“待定”了事。可以标注“待确认”，同时把该时间的不确定性列入风险，并写明需要谁在什么时点前确认。若该任务处于关键路径上，还应评估它对后续依赖任务的影响，避免基线发布后才发现时间无法落地。
计划表发布基线后，什么情况下需要走变更流程？
在发布基线时就把触发条件写清楚，常见的有范围调整、关键依赖失效、里程碑偏移超过约定阈值。触发后由约定审批人确认，变更内容、原因、提出人和确认时间记入变更台账，保留基线原值，不直接覆盖。日常状态更新按固定节奏进行，不属于变更。
计划表设计和项目进度管理是什么关系？
计划表负责把“做什么、谁做、何时做、依赖什么、交付什么”写清楚，属于计划建立阶段。执行过程中出现偏差后如何分析原因、如何纠偏，属于进度管理的范围；具体任务的排期算法和依赖链调整，属于任务排期与依赖管理。本文只覆盖计划表的设计与建立，后两类问题在相应主题中展开。
团队已有旧版计划表，改造时从哪里入手？
先按用途和读者清单核对旧表是否支撑关键决策，再检查字段口径是否存在歧义，例如负责人是否填了多人、完成标准是否可验证。改造时优先统一字段口径和状态取值，再调整层级结构，最后补上变更规则。改造后的表同样需要试填和评审，避免只改格式不改用法。
