任务排期与依赖管理要落到可核对的字段和动作上：先把任务拆到一个人能独立交付的粒度，写清开始时间、截止日期、负责人、交付物和完成标准；再识别前后置依赖，记录依赖类型与等待条件；然后按依赖排出执行顺序，把时间冲突逐条处理；最后用固定节奏检查依赖状态和排期变化。本文聚焦工作项层面的排期与依赖，项目整体进度和人员容量冲突另作讨论。
要点总览（TL;DR）
- 排期的最小单位是“一名负责人能独立交付成果”的任务，每项任务写清开始时间、截止日期、负责人、交付物和完成标准。
- 依赖从交付物、审批、外部输入、环境准备四类来源排查，登记前置任务、后置任务、依赖类型、等待条件、约定时间和责任人。
- 执行顺序按“前置完成才可开始”逐层推导，同层任务并行安排，冲突通过调整顺序、拆分任务、调整时间或设置等待点处理。
- 任务负责人、排期维护人和依赖双方各有明确职责，依赖变更由提出方通知、接收方确认、维护人更新记录。
- 按日或按周检查即将到期任务的依赖状态，排期变化及时回写，排期表与依赖登记表保持一致即视为管理到位。
先定排期的最小单位与字段
排期做不准，常见原因在任务粒度：一项任务里藏着多人接力、多次外部确认，依赖关系就被包在任务内部，排期表上看不出来。适合排期的粒度是“一名负责人在一段可预期的时间内能独立完成并交付成果”。如果一项任务需要两个人先后动手，或需要等外部回复才能继续，就继续拆，直到每项任务只有一个主要负责人、一个明确交付物。
每项可排期任务至少写清五个字段，缺一项都会影响后续依赖判断：
| 字段 | 填写要求 | 在依赖管理中的作用 |
|---|---|---|
| 开始时间 | 前置条件就绪后可以动手的日期 | 判断前置任务是否来得及交付 |
| 截止日期 | 交付物必须完成的时间点 | 约束后置任务的最早开始时间 |
| 负责人 | 一名对交付结果负责的人 | 依赖确认和变更通知的对接人 |
| 交付物 | 可被下游直接使用的具体产物 | 判断依赖是否真正解除的依据 |
| 完成标准 | 交付物达到什么状态算完成 | 避免“做完了但下游不能用” |
填写示例：任务“完成订单接口联调”，开始时间3月4日，截止日期3月8日，负责人为后端开发A，交付物为联调通过的接口清单与问题记录，完成标准为清单内接口全部通过、遗留问题已登记并分派。常见错误包括：交付物写成“接口相关工作”这类无法验收的表述；开始时间直接填立项日期，忽略前置条件；一项任务挂多个负责人，导致依赖确认时找不到对接人。
识别并记录任务之间的依赖
依赖可以从四个来源逐一排查：后置任务需要谁的产出，对应交付物依赖；需要谁签字或评审通过，对应审批依赖；需要外部提供数据、账号或接口，对应外部输入依赖；需要某套环境、设备或权限就绪，对应环境准备依赖。对每项任务问一遍这四个问题，大部分隐藏依赖都能浮出来。
识别出的依赖要登记成条目，而不是停留在口头约定。登记表建议包含以下字段：
| 字段 | 说明 |
|---|---|
| 前置任务 | 提供交付物或完成动作的一方 |
| 后置任务 | 等待该条件才能开始或继续的一方 |
| 依赖类型 | 硬依赖或软依赖 |
| 等待条件 | 具体等到什么状态算满足，如“评审纪要发出” |
| 约定时间 | 前置方承诺满足条件的时间 |
| 当前状态 | 未开始、进行中、已满足、已逾期 |
| 责任人 | 负责跟进该依赖状态的人 |
硬依赖与软依赖的区分决定处理方式。硬依赖指条件不满足后置任务就无法开展，例如没有接口文档就无法联调、没有审批通过就不能上线，这类依赖只能等待或提前协调，不能绕过。软依赖指存在替代路径，例如设计稿未定稿时可以先按草图搭页面结构，或先用测试数据代替真实数据，这类依赖可以通过替代方案或并行安排来缓解。把软依赖误判为硬依赖，会让排期不必要地串行；把硬依赖当成软依赖，则会在执行中卡住。
在工具层面，ONES 的工作项可以承载开始时间、截止日期、负责人等排期字段，并通过工作项之间的关联记录前后置关系，使依赖条目与任务本身放在同一处维护，减少排期表和依赖表各记一份造成的偏差。
按依赖排出执行顺序与时间安排
有了任务字段和依赖登记，排期按以下步骤推导：
- 先找出没有前置依赖的任务，把它们放在序列最前，按截止日期和负责人可用时间安排时间窗口。
- 按“前置完成才可开始”逐层展开：每项任务的最早开始时间，取所有前置任务截止日期中最晚的一个，再加上必要的交接时间。
- 同一层内没有相互依赖的任务并行安排，检查同一负责人的任务是否时间重叠。
- 把推导结果写回排期表，逐条核对排期表与依赖登记表是否一致。
排期冲突主要有四种表现：同一负责人的两项任务时间重叠；后置任务的开始时间早于前置任务的截止日期；外部输入的约定时间晚于内部计划；关键路径上任务集中导致缓冲不足。对应处理方式包括：调整任务顺序，把不受前置约束的任务提前；拆分任务，让可并行的部分先走；调整时间窗口，与依赖方重新约定交付时间；设置明确等待点，约定检查日期，到期再决定是否升级协调。每种处理结果都要回写到排期表和依赖登记表，只口头说一声，下次检查时就会重新出现。
角色分工与交付物约定
依赖无人跟进，往往不是态度问题，而是职责没有落到具体动作上。排期与依赖管理涉及三类角色：
| 角色 | 核心职责 | 维护的交付物 |
|---|---|---|
| 任务负责人 | 按完成标准交付成果；前置条件不满足时及时提出 | 任务字段、交付物、完成状态 |
| 排期维护人 | 汇总排期表与依赖登记表，识别冲突并推动处理 | 排期表、依赖登记表、冲突处理记录 |
| 依赖双方 | 确认等待条件与约定时间；变更时发起通知并确认 | 依赖条目的状态与约定时间 |
依赖变更时，由提出变更的一方发起通知，说明变更原因、新的约定时间和对后置任务的影响；接收方确认后，由排期维护人更新依赖登记表和排期表。任务负责人负责自己任务字段的准确性，排期维护人对两张表的一致性负责，依赖双方对约定时间的兑现负责。三者的维护边界写清楚，检查时才能找到该问谁。
一个跨角色任务的排期示例
以下为演示情景，用于说明填写方法，不代表真实项目数据。某团队要在两周内上线一个活动报名页，涉及产品、设计、前端、后端和测试五个角色。
任务拆分结果为：T1 需求确认与报名规则定稿（产品，3月3日至3月4日）；T2 页面视觉设计（设计，3月5日至3月7日）；T3 报名接口开发（后端，3月5日至3月10日）；T4 页面开发（前端，3月8日至3月12日）；T5 联调（前端与后端，3月11日至3月12日）；T6 测试与修复（测试，3月13日至3月14日）。
依赖识别结果：T4 依赖 T2 的设计稿，属硬依赖，等待条件为设计稿评审通过；T5 依赖 T3 的接口和 T4 的页面，属硬依赖；T6 依赖 T5 联调完成；T3 需要外部短信服务账号开通，属外部输入依赖，约定3月6日前到位。登记后逐条填入依赖登记表，标明前置任务、后置任务、类型、等待条件、约定时间和责任人。
排期时发现一处冲突：T4 原计划3月8日开始，但 T2 设计稿3月7日才完成，评审还需要半天，前端在3月8日上午会空等。处理方式是拆分 T4，把不依赖设计稿的页面框架和数据请求逻辑提前到3月7日，视觉部分等评审通过后再做，并在依赖登记表中把 T2 到 T4 的约定时间明确为3月8日中午。另一处冲突是 T3 的外部账号约定3月6日到位，晚于接口开发开始时间，处理方式是把 T3 中不依赖短信服务的部分先做，短信发送环节设置3月7日为等待点，到期未到位则升级协调。
最终排期表中，每项任务都有完整的五个字段，依赖登记表中每条依赖都有状态和责任人，两处冲突的处理结果均已回写。
排期与依赖的日常检查与完成标准
排期不是排完就结束，需要固定节奏核对。每日或每周检查以下项目：
- 未来三天内开始的任务，其前置依赖是否已满足；
- 已到约定时间的依赖是否已解除，状态是否更新；
- 任务实际开始或完成时间与排期是否出现偏差；
- 同一负责人的任务是否出现新的时间重叠；
- 依赖登记表中是否有长期停留在“进行中”的条目。
依赖到期未满足时，先确认阻塞原因：是前置方进度延后、等待条件定义不清，还是外部输入未到位。原因明确后，再决定调整后置任务时间、启用替代方案，或升级协调。处理结论要写进依赖登记表和排期表，并通知受影响的任务负责人。
排期更新的触发条件包括：任务实际开始或完成时间变化、依赖条件变化、交付物范围变化、外部输入时间变化。每次更新记录变更原因和受影响的后置任务，便于下次检查时追溯。
判断排期与依赖管理是否到位，可对照以下完成标准：每项可排期任务都有完整字段；每条关键依赖都有登记、等待条件和责任人；执行顺序与依赖关系一致；排期冲突有处理记录；检查按固定节奏运行；排期表与依赖登记表保持一致。达到这些标准，排期就能随实际进展持续更新，依赖也不会在交接处断掉。
常见问题
任务拆到多细才适合排期？拆得太细会不会增加管理成本？
判断标准是“一名负责人能否独立完成并交付”。如果一项任务需要两人先后动手，或需要等外部回复才能继续，就继续拆，直到每项任务只有一个主要负责人和一个可验收的交付物。
拆得过细确实会增加维护量，可以用一个简单规则控制：单项任务的周期大致在半天到一周之间。短于半天的任务可以合并到同一交付物下，长于一周且中间有明显等待点的任务则应拆开，让依赖关系显性化。
软依赖和硬依赖判断错了会有什么后果？怎么复核？
把软依赖当成硬依赖，排期会被不必要地串行，后置任务空等；把硬依赖当成软依赖，执行中会卡住，甚至到交付前才发现前置条件没满足。
复核时可以问两个问题：这个条件不满足时，后置任务是否完全无法开展？是否存在可接受的替代方案或临时输入？两个答案都是“是”才归为硬依赖。判断不确定时，先按硬依赖登记并约定检查时间，到期再评估能否转为并行安排。
依赖方一直不按约定时间交付，排期维护人应该怎么处理？
先确认阻塞原因，区分是前置方进度延后、等待条件定义不清，还是外部输入未到位。原因明确后再选择动作：调整后置任务时间、启用替代方案，或升级协调。
处理结论要写进依赖登记表和排期表，并通知受影响的任务负责人。如果同一依赖反复逾期，说明约定时间本身缺乏约束力，需要在下次排期时把等待条件写得更具体，例如明确到“评审纪要发出”而非“评审完成”。
排期表需要多久更新一次？每次都全量重排吗？
更新由触发条件决定，不必按固定周期全量重排。触发条件包括任务实际开始或完成时间变化、依赖条件变化、交付物范围变化、外部输入时间变化。
日常检查按日或按周核对即将到期任务的依赖状态即可，只有触发条件出现时才调整相关任务的时间窗口。每次更新记录变更原因和受影响的后置任务，便于追溯，也避免同一冲突反复出现。
跨团队协作时，依赖登记表由谁维护？
建议由排期维护人统一维护依赖登记表和排期表，依赖双方负责确认等待条件与约定时间，并在变更时发起通知。任务负责人对自己任务字段的准确性负责。
跨团队场景下，关键是每个依赖条目都有明确的责任人，而不是由某一方团队整体承担。责任人可以是前置方的对接人，也可以是后置方负责跟进状态的人，但需要在登记时就写清，检查时才能找到该问谁。
