任务排期表按工作项逐行记录，用来安排时间、责任人和前后依赖。本文提供一张可直接复制到表格工具中的空白模板，并说明每个字段怎么填、哪些列不能空、依赖和日期如何联动，最后给出维护规则。最小可用版本包含工作项名称、负责人、开始日期、结束日期、状态、前置依赖六列，适用于单个项目或阶段性工作的排期。
要点总览（TL;DR）
- 最小可用任务排期表包含六列：工作项名称、负责人、开始日期、结束日期、状态、前置依赖；优先级、交付物、里程碑、备注按管理需要追加。
- 六项必填字段缺一不可：名称用于识别与依赖引用，负责人用于跟进，起止日期用于排期，状态用于同步进展，无依赖时填“无”而非留空。
- 填写顺序是先列全工作项、再填依赖、最后排日期，日期按依赖顺序顺延，避免先定死日期导致依赖冲突。
- 依赖通过填写其他行的工作项名称建立，名称改动时需同步修改所有引用；日期顺延要逐行检查下游任务。
- 模板按项目类型增减列，控制总列数在十列左右；每周复核状态与依赖，阶段结束后另存归档版本。
可复制空白任务排期表模板
下面这张表可以直接选中复制到 Excel、在线表格或文档中。列的顺序对应填写顺序：先写清工作项和负责人，再标状态与依赖，最后填日期。空白行保留两行，方便先试填再扩展。
| 工作项名称 | 负责人 | 开始日期 | 结束日期 | 状态 | 前置依赖 | 优先级 | 交付物 | 里程碑 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
前六列构成最小可用模板，后四列为扩展列。复制时如果只需要最小版本，删除“优先级”到“备注”四列即可，其余列的顺序保持不变，后续补充字段时直接追加在右侧，避免打乱已有填写习惯。
每个字段记录什么：排期表字段说明
字段口径统一，排期表才能在多人填写后仍然可读。以下逐列说明含义和常见写法，模板、示例与维护规则都以此为准。
| 字段 | 记录内容 | 填写口径与常见写法 |
|---|---|---|
| 工作项名称 | 这一行代表的具体任务 | 用“动词+对象”写法，如“完成登录页接口联调”；一行只放一个可交付的任务，避免把多个动作塞进同一行 |
| 负责人 | 对该工作项结果负责的人 | 填一个人名或岗位名，不填团队名；协作成员写进备注，保证每行有唯一责任人 |
| 开始日期 | 计划开始执行的日期 | 统一用“YYYY-MM-DD”，如 2025-03-10；全表只用一种格式，不混用“3月10日” |
| 结束日期 | 计划完成的日期 | 与开始日期同格式；结束日期不早于开始日期，跨天任务按实际占用填写 |
| 状态 | 工作项当前进展 | 固定几个取值，如“未开始 / 进行中 / 待评审 / 已完成 / 阻塞”；不临时造新词 |
| 前置依赖 | 本行开始前必须先完成的工作项 | 填写其他行的工作项名称，多个依赖用分号隔开；没有依赖填“无”，不留空 |
| 优先级 | 相对重要和紧急程度 | 用“高 / 中 / 低”三档即可；档位过多会让排序失去区分度 |
| 交付物 | 完成时产出的具体成果 | 写可检查的对象，如“接口文档 v1”“测试报告”，便于验收时对照 |
| 里程碑 | 该工作项归属的阶段节点 | 填阶段名称，如“第一阶段上线”；同一阶段的多行使用完全相同的写法，方便筛选 |
| 备注 | 补充说明 | 放协作人、风险提示、外部等待事项等不适合进固定列的信息 |
依赖引用采用“按名称指向其他行”的方式，被依赖的工作项名称必须与表中某一行完全一致。名称改动时，所有引用它的依赖列要同步修改，否则依赖关系会断开。日期格式和状态取值同样需要在表头或表格说明中固定下来，新增填写人按同一口径录入。
必填与选填：哪些列不能空
六项必填字段承担排期表的核心判断：做什么、谁做、什么时候做、做到哪、受谁制约。缺任何一项，表格都会失去一类判断能力。
| 字段 | 必填/选填 | 缺失后的影响 |
|---|---|---|
| 工作项名称 | 必填 | 无法识别这一行代表什么，依赖列也无从引用 |
| 负责人 | 必填 | 任务无人认领，进度无法追责和跟进 |
| 开始日期 | 必填 | 无法判断任务何时启动，依赖排期失去起点 |
| 结束日期 | 必填 | 无法判断完成时点，后续任务无法据此排期 |
| 状态 | 必填 | 无法区分未开始与进行中，例会同步只能靠口头询问 |
| 前置依赖 | 必填 | 看不出任务之间的先后约束，容易出现并行冲突；无依赖时填“无”而非留空 |
| 优先级 | 选填 | 工作项较多、需要排序取舍时启用 |
| 交付物 | 选填 | 需要按成果验收、或交付物需要评审时启用 |
| 里程碑 | 选填 | 工作项需要归入阶段节点、按阶段汇总时启用 |
| 备注 | 选填 | 存在协作人、外部等待或风险说明时启用 |
选填列的启用条件是“有对应管理动作”。团队需要每周排序决定先做什么，就加优先级；需要按阶段向上汇报，就加里程碑；只是几个人短期执行的小项目，保留六列即可。选填列一旦启用，就按同一口径填完整，部分行留空会让筛选和汇总出现偏差。
填写示例：一张填好的任务排期表
以下示例为一个“会员功能上线”的小型项目，演示从空白表到可用排期的填写过程。填写顺序是：先列全工作项，再填依赖，最后排日期。
| 工作项名称 | 负责人 | 开始日期 | 结束日期 | 状态 | 前置依赖 | 优先级 | 交付物 | 里程碑 | 备注 |
|---|---|---|---|---|---|---|---|---|---|
| 确认会员权益规则 | 李敏 | 2025-03-03 | 2025-03-05 | 已完成 | 无 | 高 | 权益规则说明 v1 | 需求阶段 | 需运营确认 |
| 会员接口开发 | 王磊 | 2025-03-06 | 2025-03-14 | 进行中 | 确认会员权益规则 | 高 | 接口文档与联调环境 | 开发阶段 | 前端张倩配合联调 |
| 会员页面开发 | 张倩 | 2025-03-10 | 2025-03-18 | 进行中 | 确认会员权益规则 | 中 | 会员中心页面 | 开发阶段 | |
| 会员功能测试 | 陈涛 | 2025-03-19 | 2025-03-24 | 未开始 | 会员接口开发；会员页面开发 | 高 | 测试报告 | 测试阶段 | 依赖两项开发完成 |
| 上线发布 | 王磊 | 2025-03-25 | 2025-03-25 | 未开始 | 会员功能测试 | 高 | 上线记录 | 发布阶段 | 需提前一天通知客服 |
依赖列指向表中其他行的名称：“会员接口开发”依赖第一行，“会员功能测试”同时依赖接口开发和页面开发两项，用分号分隔。日期按依赖顺序排：测试的开始日期晚于两项开发的最晚结束日期，上线排在测试结束之后。如果接口开发延期到 3 月 17 日，测试的开始和结束日期要整体顺延，上线日期随之调整，状态列同步更新。
状态随进展更新，而不是等全部完成再改。任务启动当天把“未开始”改为“进行中”，进入评审或测试改为“待评审”，遇到外部阻塞改为“阻塞”并在备注写明原因。这样每周查看排期表时，状态列能直接反映真实进展。
当排期表从个人表格转为团队共同维护时，工作项名称、负责人、日期、状态和依赖关系需要多人同时查看和修改。ONES 的工作项支持设置负责人、计划起止时间、状态与前后置依赖，依赖关系建立后可在工作项之间查看关联，状态流转记录变更过程。把表格中的六项必填字段对应到工作项属性上，团队在同一个工作项列表里更新排期，减少多份表格版本不一致的情况。
模板的调整与日常维护方法
模板用一段时间后，需要按项目类型增减列，并对依赖和日期变更设定更新规则，否则表格会越填越乱。
按项目类型增删列
判断依据是“这一列是否支撑一个实际管理动作”。研发类项目通常保留交付物和里程碑，便于按阶段验收；市场活动类项目可以增加“渠道”列，但应替换掉使用频率低的列，控制总列数在十列左右，避免横向滚动影响阅读。跨团队协作项目建议保留备注列记录外部等待事项；单人短期任务可以只保留六列必填字段。增列时追加在右侧，删列前确认没有依赖该列做筛选或汇总。
依赖变更与日期顺延规则
依赖关系变化时，按以下顺序处理：
- 先改前置依赖列，确认被引用工作项的名称仍然存在且拼写一致。
- 再调整受影响工作项的开始日期，使其不早于所有前置依赖的结束日期。
- 然后顺延结束日期，并检查后续依赖该工作项的行是否需要同步调整。
- 最后更新状态和备注，记录变更原因和调整日期。
日期顺延时逐行检查下游任务，避免只改了一行、后续行仍停留在旧日期。若某个工作项被取消，先在依赖列中删除对它的引用，再决定是删除该行还是标记为“已取消”，保留下历史记录便于追溯。
定期复核与归档
建议每周固定一次复核：对照状态列检查是否有长期停留在“进行中”的工作项，核对依赖列是否仍指向有效行，确认结束日期已过但状态未更新的行。项目阶段结束后，把已完成的排期表另存为归档版本，文件名带上项目名和结束日期；新阶段使用新的空白模板，避免在旧表上不断追加导致历史信息混杂。归档表保留只读，作为后续复盘和类似项目排期的参考。
常见问题
任务排期表和项目进度计划有什么区别，什么时候该用哪一个？
任务排期表按工作项逐行记录，回答的是“每件事谁做、什么时候做、受谁制约”，粒度到单个任务。项目进度计划关注阶段划分、里程碑节点和整体交付节奏，粒度到阶段或项目层。两者可以配合使用：用排期表安排具体工作项，再把关键工作项归入里程碑列，向上汇总为进度视图。如果当前要解决的是任务之间的先后顺序和日期安排，用排期表；如果要回答整个项目何时交付、各阶段如何衔接，则需要项目进度计划。
前置依赖填了名称，但被依赖的工作项后来改名或拆分了，怎么处理？
依赖按名称引用，名称一变引用就会断开。处理顺序是：先确认被依赖工作项的新名称或拆分后的多个工作项，再修改所有引用它的依赖列，然后检查这些行的开始日期是否仍晚于依赖项的结束日期，最后在备注中记录变更原因。如果原工作项被拆成两项，依赖列需要同时写上两个新名称并用分号分隔。建议在改名或拆分前先搜索表中有哪些行引用了它，一次性改完，避免遗漏。
团队多人同时维护排期表，怎么避免版本混乱？
表格工具多人编辑时，常见问题是同一行被不同人改成不同日期，或者依赖列指向了已被删除的行。可以约定三条规则：一是每行只由负责人更新自己的状态和日期，其他人只读；二是依赖变更由排期维护人统一处理，避免各自改动；三是每周复核时对照状态列和依赖列做一次一致性检查。当排期需要频繁协作、依赖关系较多时，也可以把工作项放到支持负责人、计划起止时间、状态和前后置依赖的管理工具中维护，让变更记录可追溯。
小团队只有几个人、任务不到二十条，还需要完整填六列吗？
六列仍然建议填全，因为它们是排期表能自我解释的最小集合。任务少的时候，负责人和日期可以口头同步，但状态和前置依赖一旦省略，例会时就容易回到“谁在做、做到哪、卡在谁那里”的逐条询问。如果确实想简化，可以只保留六列、删掉全部扩展列，而不是从六列里再删。等任务数量增加或出现跨团队协作时，再按需追加优先级、交付物和里程碑列。
排期表里的日期应该按理想情况排，还是留出缓冲？
建议按可执行的时间排，并在备注中标注已知的外部等待和风险，而不是把缓冲直接摊进每个工作项的日期里。缓冲摊进每一行会让排期看起来宽松，实际执行时又会被逐项消耗掉，最终仍要整体顺延。更稳妥的做法是：单个工作项按实际工作量排日期，在里程碑或阶段层面留出集中缓冲，并在备注列写明需要等待的外部事项。这样日期变更时，能清楚判断是工作量估计偏差还是外部依赖延迟。
