任务排程需要同时处理四类约束：时间、依赖、能力，以及范围与变更。排程难往往不是任务本身复杂，而是约束没有被完整记录、没有区分硬软，导致先后顺序和缓冲都缺少依据。下面给出一套可直接套用的做法：先列约束清单，再排依赖顺序，把软约束转成缓冲，明确角色分工，最后用试排和检查清单验证排程能否执行。
要点总览（TL;DR）
- 任务排程要同时处理四类约束：时间、依赖、能力、范围与变更，每条约束记录内容、硬软属性、来源、负责人和可调整空间。
- 硬约束按违反后果与调整权限判断，违反后任务无法执行或必须升级的记为硬约束；内部评审时间、非关键人员参与方式等可调整项记为软约束。
- 依赖排序先识别前置任务与交付物交接，再区分内部依赖与外部输入依赖，沿依赖链找出关键路径和最长等待链，外部依赖设置确认时点与责任人。
- 软约束按被突破的概率和影响时长量化成缓冲，优先覆盖关键路径与最长等待链，并写明缓冲消耗阈值和补充规则。
- 排程发布前逐项核对硬约束、依赖责任人、缓冲覆盖、变更规则和依据可追溯性，全部通过或已升级处理才进入执行。
先列出排程约束清单：四类约束与硬软区分
排程的第一步是把“这个时间不能动”“这个人只能做这个”之类的口头判断，转成一条条可记录、可核对的约束条目。建议按四类归集，每类都落到具体字段，避免遗漏后再返工。
| 约束类型 | 具体内容 | 硬/软 | 来源 | 负责人 | 可调整空间 |
|---|---|---|---|---|---|
| 时间约束 | 对外交付截止日期 | 硬 | 合同或客户约定 | 任务负责人 | 无，逾期需升级 |
| 时间约束 | 内部里程碑评审 | 软 | 项目惯例 | 排程协调人 | 可前后浮动若干天 |
| 时间约束 | 工作日历与冻结期 | 硬 | 组织制度 | 排程协调人 | 冻结期内不安排变更 |
| 依赖约束 | 前置任务完成 | 硬 | 任务拆分关系 | 前置任务负责人 | 无，未完成则后续无法开始 |
| 依赖约束 | 交付物交接 | 硬或软 | 上下游约定 | 交付方负责人 | 交接标准可协商，时点视情况 |
| 依赖约束 | 外部输入与审批 | 硬 | 外部单位或审批流程 | 对接人 | 无，需提前确认时点 |
| 能力约束 | 执行角色与技能匹配 | 硬 | 任务性质 | 任务负责人 | 可换人但需满足技能要求 |
| 能力约束 | 可用工时 | 软 | 人员排班 | 排程协调人 | 可通过调整投入比例变化 |
| 能力约束 | 关键人员 | 硬 | 唯一技能持有者 | 排程协调人 | 无替代时不可并行安排 |
| 范围与变更约束 | 验收标准 | 硬 | 需求文档 | 任务负责人 | 变更需走审批 |
| 范围与变更约束 | 变更窗口 | 软 | 团队约定 | 排程协调人 | 可提前或延后，需记录 |
| 范围与变更约束 | 审批与冻结规则 | 硬 | 管理制度 | 审批人 | 冻结期内不接受变更 |
硬约束与软约束的区分标准是违反后果和调整权限：违反后任务无法执行、必须升级处理的，记为硬约束，例如法定截止日期、外部合同交付时点、唯一技能人员；在可控范围内可以调整、调整后不影响最终交付的，记为软约束，例如内部评审时间、非关键人员的参与方式。判断依据是后果与权限，与约束由谁提出无关。
填写时每条约束至少记录五项：内容、硬软属性、来源、负责人、可调整空间。来源写清依据（合同、制度、任务拆分关系），负责人写清谁能在需要时确认或调整。这张表是后续排序和设缓冲的输入，字段缺失的条目应在试排前补齐。
按依赖排出顺序：从约束清单到任务先后关系
约束清单回答“有哪些限制”，依赖排序回答“谁先谁后”。做法是从清单中抽出所有前置任务与交付物交接关系，形成任务依赖关系表，再据此排出顺序并标出关键路径。
先识别内部依赖：任务A的产出是任务B的输入，A即为B的前置任务；交付物交接要写清交接物、交接标准和接收方。再识别外部输入依赖：来自其他团队、供应商或审批环节的输入，单独标注，不与内部依赖混在一起，因为外部依赖的等待时间通常更长、可控性更低。
| 任务 | 前置任务 | 依赖类型 | 交接物/输入 | 确认时点 | 责任人 | 是否在关键路径 |
|---|---|---|---|---|---|---|
| 需求确认 | 无 | — | 需求文档 | 启动后第3个工作日 | 需求负责人 | 是 |
| 方案设计 | 需求确认 | 内部 | 确认后的需求 | 需求确认当日 | 设计负责人 | 是 |
| 外部接口联调 | 方案设计、外部接口就绪 | 内部+外部 | 接口文档与测试环境 | 设计完成后第2个工作日 | 对接人 | 是 |
| 功能开发 | 方案设计 | 内部 | 设计说明 | 设计评审通过后 | 开发负责人 | 是 |
| 内部文档整理 | 功能开发 | 内部 | 开发完成说明 | 开发完成后 | 文档负责人 | 否 |
排完依赖后，沿依赖链计算各路径的累计时长，最长的一条即关键路径，它决定整体完成时间；链上等待时间最长的外部输入构成最长等待链，应优先安排确认动作。外部依赖必须设置确认时点和责任人，确认时点要早于需要该输入的任务开始时间，留出跟进余地。
依赖关系发生变化时，同步更新依赖表，记录变更原因、变更前后关系和影响范围，并通知受影响的上下游负责人。只改排程日期而不改依赖表，会让下一次排程继续沿用错误关系。
把软约束转成缓冲：排程中的时间与能力留量
软约束意味着存在调整空间，但空间大小需要量化，否则排程仍会被单点延误击穿。换算思路是：估算该约束被突破的概率和影响时长，再按任务在关键路径上的位置分配缓冲。
关键路径上的任务一旦延误，整体完成时间直接顺延，因此缓冲应优先覆盖关键路径，尤其是最长等待链上的外部输入。普通任务可用时间余量或资源替代来吸收波动，不必单独设置大块缓冲。缓冲不是统一按固定比例加在每项任务上，而是按风险集中投放。
| 任务 | 缓冲类型 | 缓冲量 | 触发补充的条件 |
|---|---|---|---|
| 外部接口联调 | 时间缓冲 | 2个工作日 | 外部确认晚于约定时点1天以上 |
| 功能开发 | 能力缓冲 | 1名可调配开发人员 | 关键人员请假或任务量超出预估20% |
| 方案设计 | 时间缓冲 | 1个工作日 | 评审意见需要返工时 |
| 内部文档整理 | 无单独缓冲 | — | 由时间余量吸收 |
关键人员与稀缺技能需要提前安排替代：确认是否有人具备同等技能、替代人需要多少准备时间、替代期间哪些任务可以并行。若确实没有替代，该人员承担的任务应尽量不并行安排，并在缓冲表中标注为单点风险。
缓冲要有消耗与补充规则：消耗到设定阈值（例如剩余不足一半）时触发补充评估或升级；补充来源可以是压缩非关键任务、调配人员或调整软约束。规则写进缓冲表，避免缓冲被无声耗尽后才发现排程已不可行。
角色与交付物分工：谁维护约束、谁确认排程
约束信息如果无人维护，清单会在几周内失效。排程过程通常涉及三类角色，各自对应明确的交付物。
| 角色 | 主要职责 | 对应交付物 |
|---|---|---|
| 任务负责人 | 维护本任务的约束条目与进度，确认前置任务完成情况，提出变更申请 | 任务约束条目、进度更新、变更申请 |
| 排程协调人 | 汇总约束清单，组织试排，维护依赖关系表与缓冲表，发起排程确认 | 约束清单、依赖关系表、缓冲设置表、排程版本 |
| 依赖提供方 | 确认外部输入或交接物的可用时点，对延迟提前告知 | 依赖确认记录、交接物 |
维护频率按变化程度定：约束清单在每次试排前整体核对一次，任务负责人有变化时随时更新；依赖关系表在任务拆分调整或外部输入时点变化时更新；缓冲表在缓冲消耗触发阈值时更新。排程确认由排程协调人发起，任务负责人与依赖提供方共同确认，变更审批按变更规则执行，冻结期内的变更需走升级流程。
当约束条目和依赖关系记录在工作项上时，维护动作可以跟着任务状态走。ONES 支持在工作项中设置字段记录约束属性、建立任务间依赖关系，并在状态流转中保留变更记录，排程协调人据此汇总清单和依赖表，减少在多份表格之间对不齐的情况。具体字段配置可按团队实际约束类型调整。
试排一次：用示例走完约束到排程的全过程
以下为演示情景，用于说明方法链路，不代表真实项目数据。
示例背景与任务集合：某团队需在四周内完成一个功能模块交付，任务包括需求确认、方案设计、外部接口联调、功能开发、内部文档整理五项，涉及需求负责人、设计负责人、开发负责人、对接人和文档负责人。
约束清单填写示例：对外交付日期为硬约束，来源为合同；内部设计评审为软约束，可浮动2天；外部接口就绪为硬约束，来源为外部单位；开发负责人为唯一技能持有者，记为硬约束；验收标准为硬约束，变更需审批；变更窗口为软约束，每周固定两天受理。
依赖排序与关键路径结果：需求确认→方案设计→功能开发→内部文档整理构成内部主链；方案设计→外部接口联调为另一分支，外部接口就绪是外部输入。累计时长最长的路径为需求确认→方案设计→外部接口联调，关键路径落在外部接口联调上，最长等待链来自外部单位确认。
试排中发现的冲突及处理方式：试排发现外部接口联调与功能开发都需要开发负责人参与，形成能力冲突。处理方式是将功能开发中不依赖接口的部分提前，接口联调安排在设计评审通过后立即启动，并为外部确认设置提前2个工作日的跟进时点；同时在缓冲表中为接口联调设置2个工作日时间缓冲。
试排后的排程版本与记录：形成排程版本V1，附约束清单、依赖关系表、缓冲设置表和冲突处理记录，注明关键路径、外部确认时点与责任人。后续任何依赖或约束变化，都在V1基础上更新并记录变更原因。
完成检查：排程可执行前的核对项
排程发布前逐项核对，全部通过或已明确升级处理，才具备执行条件。
| 核对项 | 通过标准 |
|---|---|
| 硬约束是否全部满足或已升级 | 每条硬约束都有满足方案，无法满足的已记录升级对象和处理时限 |
| 依赖关系是否都有责任人与确认时点 | 依赖表中无空白责任人，外部依赖的确认时点早于需要该输入的任务开始时间 |
| 缓冲是否覆盖关键路径风险 | 关键路径和最长等待链均有对应缓冲，单点风险已标注替代方案或明确无替代 |
| 变更规则是否明确 | 变更窗口、审批人、冻结期规则已写入排程说明，相关角色已知悉 |
| 排程依据是否可追溯 | 约束清单、依赖表、缓冲表和试排记录版本一致，变更均有原因记录 |
五项全部通过即可发布排程；存在未通过项时，先补齐或升级，再进入执行。排程发布后，按角色分工维护约束与依赖，缓冲消耗触发阈值时按规则补充，使排程在执行过程中保持可核对、可调整。
常见问题
硬约束和软约束判断不一致时，怎么处理？
先回到判断标准：违反后任务是否无法执行、是否必须升级处理，以及谁有权调整。两个角色判断不一致时，由排程协调人组织任务负责人和约束来源方一起确认，把结论和依据写进约束清单的“可调整空间”字段。暂时无法达成一致的，先按硬约束处理并设置升级时限，避免试排被卡住。
外部依赖迟迟没有确认时点，排程还能往下做吗？
可以继续排，但要把这条外部依赖单独标注为未确认，并在依赖表中写明对接人和最晚确认时间。排程时按最保守的可用时点估算，同时准备一条不依赖该输入的替代路径，例如先做不涉及接口的部分。确认时点晚于约定后，按缓冲规则触发补充评估或升级，不要用调整日期的方式掩盖依赖未确认的事实。
缓冲设多少合适，有没有统一比例？
没有通用比例。做法是估算该约束被突破的概率和影响时长，再按任务在关键路径上的位置分配。关键路径和最长等待链上的任务优先获得缓冲，普通任务用时间余量或人员替代吸收波动。缓冲量写进缓冲表，同时写明消耗到多少触发补充、补充来源是什么，避免缓冲被无声耗尽。
任务拆分调整后，之前的排程要全部重做吗？
不必全部重做，但要同步更新依赖关系表并记录变更原因、变更前后关系和影响范围，再检查关键路径是否发生变化。只改排程日期而不改依赖表，下一次排程会继续沿用错误关系。若拆分影响到外部依赖的确认时点，还需通知对接人重新确认。
小团队也需要设排程协调人这个角色吗？
角色可以合并，职责不能空缺。小团队里任务负责人可以同时承担汇总约束清单和发起试排的工作，但需要明确谁负责维护依赖表、谁确认外部输入时点。合并角色时建议在排程说明中写清每项维护动作的承担人，避免约束信息无人更新。
