瀑布项目计划的约束需要先分类识别，再逐条落到可验证的计划条目上。本文按范围、时间、成本、质量、资源、外部依赖、合规与合同、风险八类展开，说明如何建立约束登记表、把硬约束与软约束转成里程碑和缓冲、明确角色分工，并用一次约束评审确认计划基线。约束登记与评审记录可以在ONES中借助项目计划、里程碑和文档承载，本文只在与流程相关的环节提及。
要点总览（TL;DR）
- 瀑布项目计划的约束按范围、时间、成本、质量、资源、外部依赖、合规与合同、风险八类识别，逐条记录来源、影响阶段、刚性程度和验证方式，形成可追溯的约束登记表。
- 判断约束刚性的依据是可谈判性、可延期性和违约后果；硬约束转成里程碑、前置条件或验收标准，软约束转成时间缓冲、资源备份或备选方案。
- 约束管理按来源归属责任：项目经理统筹登记与评审，业务、技术、资源采购、质量合规角色分别提供对应输入和交付物，交接时点与计划编制节奏对齐。
- 计划编制完成后用一次约束评审核对完整性、计划一致性、缓冲合理性和角色确认，通过后确认基线；合同变更、资源调整或里程碑偏差时触发复查。
先建立约束清单：八类约束与识别方法
约束识别的目标是在编制计划前把影响计划成立的条件找全，并记录到一张可追溯的登记表里。做法是按八类逐项过一遍项目阶段，每类都写明来源和影响阶段，避免只凭经验口头传递。
八类约束的定义与典型例子
| 类别 | 定义 | 典型例子 | 常见识别输入 |
|---|---|---|---|
| 范围 | 必须交付与明确不交付的内容边界 | 合同约定的功能清单、验收范围、变更审批规则 | 合同、需求文档、范围说明书 |
| 时间 | 不可移动的节点与可用工期 | 上线窗口、监管申报截止日、客户验收日期 | 合同里程碑、项目章程、业务日历 |
| 成本 | 预算上限与付款节奏 | 总预算、分阶段付款条件、采购额度 | 预算批复、采购协议、财务口径 |
| 质量 | 必须达到的标准与验收方式 | 性能指标、缺陷密度要求、评审与测试标准 | 质量计划、行业标准、验收准则 |
| 资源 | 人力、设备、环境的可用条件 | 关键角色到位时间、专用测试环境、稀缺设备档期 | 资源台账、排班表、设备清单 |
| 外部依赖 | 由外部方提供或配合的事项 | 供应商交付、第三方接口开放、客户提供数据 | 供应商协议、接口文档、往来函件 |
| 合规与合同 | 法规、标准与合同条款带来的强制要求 | 数据安全要求、审计留痕、违约与验收条款 | 法规清单、合同条款、审计要求 |
| 风险 | 可能发生并影响计划目标的不确定事件 | 关键技术验证失败、关键人员流失、需求集中变更 | 风险登记册、历史项目复盘、专家判断 |
识别动作与输出
识别按阶段推进：对每个阶段列出该阶段会触碰的约束，逐条追问“来源是什么、影响哪个阶段、能否调整、如何验证”。识别完成后形成约束登记表，字段建议如下。
| 字段 | 填写要求 |
|---|---|
| 编号 | 唯一标识，便于在计划条目中引用 |
| 类别 | 八类之一，便于检查覆盖 |
| 描述 | 一句话写清约束内容与边界 |
| 来源 | 合同条款、需求文档、资源台账、法规清单、供应商协议等具体出处 |
| 影响阶段 | 设计、开发、测试、上线等受影响的阶段 |
| 刚性程度 | 硬约束或软约束，附判断依据 |
| 验证方式 | 评审、测试、对账、审计等可核验手段 |
完成标志是八类均有覆盖或明确标注“本项目不涉及”，且每条约束都能追溯到具体来源文件。
把约束转成计划条目：硬约束、软约束与缓冲设置
约束停留在清单层面无法指导执行，需要转成计划中的里程碑、前置条件、验收标准或缓冲。转化的前提是先判断刚性程度。
硬约束与软约束的区分标准
判断依据有三条：是否可谈判、是否可延期、违约后果是否严重。三者都指向不可调整的，归为硬约束；存在谈判空间或可通过资源投入化解的，归为软约束。同一类约束在不同项目中可能归属不同，例如客户验收日期在合同固定时是硬约束，在内部试点中可能只是软约束。
两类约束的处理方式
| 约束类型 | 处理方式 | 计划中的体现 |
|---|---|---|
| 硬约束 | 转为里程碑、前置条件、验收标准或合同条款对应项 | 固定日期里程碑、阶段准入条件、验收检查项 |
| 软约束 | 转为时间缓冲、资源备份、备选供应商或范围裁剪预案 | 缓冲工期、替补人员、备选方案说明、裁剪清单 |
缓冲设置需要给出规则而非拍脑袋：时间缓冲按关键路径上软约束集中程度分配，资源备份明确替补角色与启用条件，备选供应商写明切换触发点。缓冲本身也要标注来源约束编号，便于后续追溯。
约束冲突与优先级排序
约束之间常出现冲突，例如压缩工期会挤压质量验证时间，追加范围会突破成本上限。处理方法是列出冲突双方，按“合同与合规优先、硬约束优先于软约束、影响验收的优先于内部优化”的顺序排序，并把决策结果写入计划说明。排序结论需要相关角色确认，不能由编制者单方决定。
输出是一份带约束标注的阶段计划：每个里程碑和关键任务旁标注对应约束编号，缓冲设置单独成表。ONES的项目计划支持按阶段分解任务、设置前后置依赖并用里程碑标记关键时间点，适合把这类标注落到可跟踪的计划结构中。
角色分工与交付物：谁负责哪类约束
约束管理要落到人，否则登记表会变成一次性文档。分工原则是按约束来源归属责任，项目经理负责统筹与评审组织。
| 角色 | 负责的约束类别 | 交付物 | 交接时点 |
|---|---|---|---|
| 项目经理 | 统筹全部类别，重点维护时间、成本与整体缓冲 | 约束登记表、评审记录、缓冲设置表 | 计划编制前启动，评审后更新 |
| 需求或业务负责人 | 范围约束与验收标准 | 范围边界说明、验收准则 | 计划编制前提交，变更时更新 |
| 技术负责人 | 技术依赖、质量约束与实现可行性 | 技术依赖清单、质量指标与验证方案 | 设计阶段前提交 |
| 资源与采购角色 | 人力、设备、供应商约束 | 资源可用性确认、供应商交付承诺 | 计划编制前确认，排期调整时同步 |
| 质量与合规角色 | 法规、标准与审计要求 | 合规要求清单、审计留痕要求 | 计划编制前提供，评审时核对 |
交接时点与计划编制节奏对齐：识别阶段收集输入，编制阶段确认可行性，评审阶段逐项核对。每个角色的交付物都应能对应到登记表中的具体条目，避免出现无人认领的约束。
示例：一个瀑布项目的约束登记与计划调整
以下为演示情景，用于说明填写与调整过程，不作为真实案例引用。某企业分阶段交付一套内部管理系统，合同约定三个阶段验收，客户指定上线窗口，测试环境由第三方提供。
约束登记表填写示例
| 编号 | 类别 | 描述 | 来源 | 影响阶段 | 刚性程度 | 验证方式 |
|---|---|---|---|---|---|---|
| C-01 | 时间 | 第三阶段须在合同约定日期前上线 | 合同第 5 条 | 上线 | 硬约束 | 验收会议确认 |
| C-02 | 合规与合同 | 用户数据须留存操作日志备查 | 数据安全要求 | 开发、测试 | 硬约束 | 审计抽查 |
| C-03 | 外部依赖 | 测试环境由第三方在开发中期提供 | 供应商协议 | 测试 | 软约束 | 环境交付确认单 |
| C-04 | 资源 | 关键开发角色同期承担另一项目 | 资源台账 | 开发 | 软约束 | 工时记录核对 |
| C-05 | 质量 | 核心流程缺陷密度须低于约定阈值 | 验收准则 | 测试 | 硬约束 | 测试报告 |
由约束推导的计划调整
C-01 转为上线里程碑并前置验收准备任务；C-02 转为开发阶段的前置条件与测试用例检查项；C-03 设置两周环境缓冲并约定备选环境方案；C-04 安排替补开发角色并标注启用条件；C-05 转为测试阶段准出标准。调整后的阶段计划在每个关键任务旁标注对应编号。
冲突处理与决策记录
编制中发现 C-01 的上线日期与 C-05 的测试周期存在冲突：按原排期测试时间不足。处理过程为：先确认 C-01 不可调整，再评估压缩非关键路径任务腾出测试时间，同时保留 C-05 的准出标准。决策记录写明“压缩集成联调两天，测试周期不变，风险由技术负责人跟踪”，并同步更新缓冲设置表。这类决策记录与计划基线一起保存，便于后续追溯变更依据。
完成检查：约束评审与计划基线确认
计划编制完成后，用一次约束评审确认约束已完整纳入计划，再确认基线。评审由项目经理组织，相关角色参与，检查项如下。
| 检查项 | 核对内容 | 通过标准 |
|---|---|---|
| 约束完整性 | 八类是否均有覆盖，来源是否可追溯 | 每类有记录或明确标注不涉及，来源文件可查 |
| 约束与计划一致性 | 每条硬约束是否有对应里程碑、前置条件或验收标准 | 登记表编号能在计划条目中找到对应项 |
| 缓冲合理性 | 软约束是否留有可执行的缓冲或备选方案 | 缓冲有数值、有来源编号、有启用条件 |
| 角色确认 | 各角色交付物是否齐全并完成交接 | 交接记录完整，无无人认领的约束 |
评审通过后确认计划基线，评审记录与约束登记表一并归档。基线确认后，出现以下情况需触发复查：合同或范围发生变更、关键资源或供应商调整、里程碑出现明显偏差、新增法规或审计要求。复查时更新登记表并重新核对一致性，必要时调整基线并记录变更原因。
在ONES中，项目计划和里程碑可以设置基线，实时对比计划与执行的偏差，并通过版本对比追溯变更细节；约束登记表与评审记录可作为项目文档随计划一起维护，使约束、计划条目和变更记录保持在同一处可查。
常见问题
约束登记表应该在项目哪个时点开始建立，后续如何维护？
约束登记表在计划编制前启动，识别阶段先收集合同、需求文档、资源台账、法规清单和供应商协议等输入，按八类逐项登记。计划编制阶段补充刚性程度和验证方式，评审阶段逐条核对是否已落到计划条目。
基线确认后，登记表随变更同步更新：合同或范围变更、关键资源或供应商调整、新增法规要求时，先更新登记表，再核对计划一致性，必要时调整基线并记录变更原因。登记表与评审记录、缓冲设置表一起归档，保持同一版本可查。
硬约束和软约束的判断出现分歧时怎么处理？
分歧通常来自对谈判空间和违约后果的判断不同。处理时把三个判断依据摆出来逐条确认：该约束是否可以谈判、是否可以延期、违约后果是否严重。判断结论需要约束来源方确认，例如时间约束由合同或业务负责人确认，合规约束由质量合规角色确认。
暂时无法确认的，先按硬约束处理并标注待确认，在计划中预留对应里程碑或前置条件；确认可以调整后，再转为软约束并设置缓冲。这样处理可以避免因判断未定而让约束在计划中落空。
软约束的缓冲设置多少合适，有没有可参考的规则？
缓冲没有统一数值，可以按约束集中程度和影响范围确定规则：时间缓冲优先分配给关键路径上软约束集中的阶段，资源备份明确替补角色和启用条件，备选供应商写明切换触发点。每条缓冲都标注来源约束编号，便于追溯。
缓冲设置后需要在评审中检查是否可执行：有数值、有来源、有启用条件。缓冲过大可能掩盖进度问题，过小则起不到保护作用，可以结合历史项目偏差数据和本项目的谈判空间调整，并在基线变更时同步复核。
约束之间冲突时，优先级排序由谁决定？
排序建议由项目经理组织，相关角色共同确认，编制者单方决定容易在执行阶段被推翻。排序可参考的顺序是：合同与合规要求优先，硬约束优先于软约束，影响验收的优先于内部优化。
决策结果写入计划说明或决策记录，写明冲突双方、取舍理由和后续跟踪责任人。示例中上线日期与测试周期的冲突，就是先确认上线日期不可调整，再压缩非关键路径任务腾出测试时间，并把风险跟踪责任落到技术负责人。
计划基线确认后，哪些情况需要重新做约束评审？
常见触发条件包括：合同或范围发生变更、关键资源或供应商调整、里程碑出现明显偏差、新增法规或审计要求。出现这些情况时，先更新约束登记表，再核对约束与计划条目的一致性，检查缓冲是否仍然有效。
复查结论可能需要调整基线，调整时记录变更原因和决策依据。把复查触发条件写进项目计划说明，可以让团队在变化发生时按同一套动作处理，减少临时口头调整带来的遗漏。
