瀑布项目计划的质量，很大程度上取决于约束是否被提前识别并正确对待。需要盘点的约束通常包括范围、时间、成本与资源、质量与合规、依赖与外部条件等类别；识别之后，还要判断每条约束是硬约束还是可协商项，再把它转成里程碑、缓冲、前置条件和责任人。本文按“列全—排序—转换—分工—示例—检查”的顺序说明具体做法。
要点总览（TL;DR）
- 瀑布项目计划要盘点的约束包括范围、时间、成本、资源、质量、合规、依赖与外部条件七类，每类记录来源、影响对象、可调整幅度和验证方式。
- 判断约束刚性看四条依据：是否写入合同、是否来自法规、是否已对外承诺、资源是否可替换；再用影响度和可调整空间两个维度排序。
- 约束要落到计划条目上：硬性时间节点倒排为里程碑，不确定因素转为缓冲，外部依赖转为前置条件和交接检查点，资源约束转为角色排期与替补安排。
- 约束清单由项目经理汇总维护版本，领域负责人提供条目，干系人确认硬约束等级，变更按约定流程评估和批准。
- 计划发布前逐项核对约束是否可回溯到里程碑、依赖和前置条件，执行期间在阶段评审时复核约束清单。
先列全约束：瀑布计划要盘点的七类条件
瀑布项目的特点是阶段顺序推进、后期返工成本高，因此约束识别要在基线计划确定之前完成。建议项目经理组织各领域负责人开一次约束盘点会，按下面七类逐项过一遍，每类至少回答三个问题：这条约束来自哪里、影响哪些交付物或节点、允许调整的幅度有多大。
| 约束类别 | 要盘点的具体内容 | 常见来源 | 可调整幅度记录方式 |
|---|---|---|---|
| 范围约束 | 交付物清单、验收标准、需求冻结时点、明确不做的内容 | 合同、需求规格说明书、客户确认邮件 | 可增删的交付物范围、验收口径能否协商 |
| 时间约束 | 合同交付节点、外部审批周期、业务窗口期、法定时限 | 合同条款、监管要求、客户业务日历 | 节点可否前移或后移、最多浮动几天 |
| 成本约束 | 预算上限、付款节奏、采购额度 | 项目立项批复、财务制度 | 预算是否可追加、追加需谁批准 |
| 资源约束 | 关键角色可用性、稀缺技能人员、外部供应商产能 | 资源排期表、供应商合同 | 人员可否替换、供应商能否加急 |
| 质量约束 | 评审轮次、测试覆盖要求、缺陷收敛标准 | 质量计划、历史项目数据 | 评审和测试能否裁剪、裁剪需谁同意 |
| 合规约束 | 行业规范、审计要求、数据与安全规定、文档留存要求 | 法规、监管机构、内部审计部门 | 通常不可调整，只记录执行方式 |
| 依赖与外部条件 | 上下游系统接口、客户配合事项、采购到货时间、第三方交付 | 接口文档、采购合同、客户接口人 | 依赖时间能否提前锁定、备选方案是否存在 |
每类约束在清单中至少记录五个字段：约束描述、来源依据、影响的对象（哪个阶段、哪个交付物）、可调整幅度、验证方式。验证方式指用什么证据确认这条约束已被满足，例如验收签字、测试报告、到货单或审批回执。字段填不出来的条目，说明约束还没有被真正理解，应回到来源方确认，而不是先写进计划再说。
区分硬约束与可协商项，排出优先级
约束清单建好后，下一步是判断刚性。判断依据主要有四条：是否写入合同条款、是否来自法规或监管要求、是否已对外做出承诺、相关资源是否可替换。满足其中一条且无法绕开的，按硬约束处理；来源是内部惯例、可替换资源或可协商口径的，归为可协商项。
排序建议用两个维度：影响度指约束被突破后对交付、成本或合规的后果严重程度；可调整空间指在不改变目标的前提下还能浮动多少。影响度高、可调整空间小的排在最前，计划排定时优先保障；影响度低、可调整空间大的放在后面，作为调节余量。两个维度都高的约束要单独标注，因为它们往往是后续冲突的来源。
约束之间经常互相冲突，例如客户要求提前交付与关键测试资源到位时间之间的矛盾。处理方式是逐条记录冲突双方、可选方案、取舍理由和批准人，形成书面的冲突取舍记录。取舍结论要与干系人确认，确认方式可以是评审会纪要或邮件回复，重点是让硬约束等级成为各方共同认可的口径，而不是项目经理单方面的判断。
把约束转成计划要素：里程碑、缓冲与前置条件
约束只有落到计划的具体条目上才有管理意义。转换的基本规则是：硬性时间节点倒排为里程碑，不确定因素转为缓冲或应急储备，外部依赖转为前置条件和交接检查点，资源约束转为角色排期与替补安排。
- 硬性时间节点：从合同交付日或审批截止日向前倒排各阶段完成时间，把不可移动的节点设为里程碑，并明确每个里程碑的完成标志，例如“需求基线评审通过并签字”。
- 不确定约束：对到货时间、审批周期、第三方交付等存在波动的条件，在对应阶段后设置缓冲，并写明缓冲的触发条件和使用审批人，避免缓冲被随意消耗。
- 外部依赖：把客户配合、接口联调、采购到货写成前置条件，挂到具体任务上，并设置交接检查点，检查点未通过则不进入下一阶段。
- 资源约束：关键角色在排期中标注可用时段，同时准备替补人选或外部支援方案，替补安排要写清启用条件和交接内容。
每条约束还应写明验证方式和触发条件。验证方式是计划执行中用来确认约束被满足的证据；触发条件是约束发生变化时需要启动的动作，例如“供应商到货延迟超过五天，启动备选供应商评估”。把这些内容整理成约束—计划要素映射表，计划中的每个里程碑、缓冲和前置条件都能回溯到清单中的某条约束，反之清单中的硬约束也都能在计划中找到落点。
在协作工具中承载这套内容时，可以用项目计划建立工作分解结构，按交付物或阶段分解任务，并为任务设置前后置依赖和里程碑标记，使约束对应的节点和依赖关系在计划中可见。计划与里程碑设置基线后，执行中可对比计划与执行的偏差，并通过版本对比追溯变更细节。资源约束方面，工时日历和饱和度报表可用于查看关键角色的负荷，据此调整节点负责人。以上能力在 ONES 瀑布项目管理解决方案中有对应说明，具体可用范围以实际版本和套餐为准。
角色分工与交付物：谁维护约束清单
约束清单建完无人维护，是计划失效的常见原因。需要明确四类角色及其产出，并在项目启动时写进项目章程或计划说明。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 项目经理 | 汇总各类约束，维护清单版本，组织约束盘点和冲突取舍评审 | 约束清单、冲突取舍记录、基线计划 |
| 各领域负责人 | 提供本领域约束及变化信息，确认约束的验证方式 | 领域约束条目、验证证据 |
| 干系人（客户、发起人、合规方） | 确认硬约束等级和验收口径，批准可协商项的调整 | 确认纪要、审批记录 |
| 变更评估人（可由项目经理或指定技术负责人担任） | 评估约束变化对范围、进度、成本的影响，提出调整方案 | 变更影响评估、调整后的计划版本 |
变更时的流程要事先约定：谁提出、谁评估影响、谁批准、批准后由谁更新清单和计划。硬约束的变更通常需要干系人层面批准，可协商项在授权范围内可由项目经理决定。每次变更后同步更新约束清单版本和计划基线，保留变更前后的对比记录，便于后续追溯。
示例：一个交付型瀑布项目的约束落地
以下为演示情景，用于串联前述方法，不代表任何真实项目数据。
背景：某企业为客户实施一套业务系统，合同约定六个月内完成上线，上线时间与客户年度业务切换窗口绑定；项目需通过客户方信息安全审计；核心开发人员同时支持另一个项目；部分硬件由第三方供应商供货。
约束识别与优先级：时间约束中，上线窗口为硬约束，不可后移；合规约束中，安全审计为硬约束，审计未通过不得上线；资源约束中，核心开发人员可用性为可协商项，可通过调整排期或引入替补缓解；依赖约束中，硬件到货时间为可协商项，但存在延迟风险，影响度高。冲突出现在测试阶段：客户要求增加一轮验收测试，与上线窗口形成挤压，取舍结论是压缩非关键模块的测试范围并增加并行测试资源，理由和批准人记入冲突取舍记录。
计划要素设置：上线日和审计通过日设为里程碑并倒排；硬件到货后设置十天缓冲，触发条件为延迟超过五天时启动备选供应商；客户配合的系统对接列为前置条件，设置交接检查点；核心开发人员按阶段排期，并指定一名替补人员，明确启用条件。
执行中的调整：项目中期硬件供应商通知延迟两周，触发缓冲使用流程，项目经理评估影响后调整联调阶段排期，将部分不依赖硬件的测试提前，变更经干系人确认后更新计划基线，约束清单同步记录本次变化及处理结果。
完成检查：计划发布前要确认的约束项
计划发布前，用下面的检查表逐项核对，全部通过再确定基线。
- 七类约束是否都已盘点，每条约束是否记录了来源、影响对象、可调整幅度和验证方式。
- 每条约束是否已判定硬约束或可协商项，判定依据是否写明。
- 硬约束是否已转为里程碑或前置条件，里程碑是否有明确的完成标志。
- 可协商项是否记录了调整幅度和批准人，冲突取舍是否有书面记录。
- 缓冲和应急储备是否设置了触发条件和使用审批人。
- 每条约束是否有明确的责任人，领域负责人是否确认了本领域条目。
- 约束变更的提出、评估、批准和更新流程是否已写入计划说明。
- 约束清单与计划中的里程碑、依赖、前置条件是否能相互回溯。
检查中发现缺项的，回到对应环节补齐后再发布计划。计划执行期间，约束清单随变更持续更新，并在阶段评审时复核一次，确保计划始终反映当前真实的约束条件。
常见问题
客户在项目中期提出新增需求，原定的需求冻结时点还算硬约束吗？
需求冻结时点是否仍按硬约束处理，取决于它当初的来源。如果冻结时点写进了合同或已作为对外承诺，新增需求就属于范围变更，需要走变更流程：评估对进度、成本和测试范围的影响，由有权批准的干系人确认后再调整计划。如果冻结时点只是团队内部约定，可以按可协商项处理，在授权范围内由项目经理决定，同时更新约束清单中的可调整幅度记录。
无论哪种情况，都建议把新增需求与原交付物分开记录，明确哪些进入本期、哪些排到后续，避免范围在无记录的情况下持续扩大。
关键人员被抽调，资源约束从可协商变成硬约束，计划要怎么调？
先确认抽调的时间范围和是否可替换。如果该角色具备可替换人选，按替补安排启用，交接内容写清当前任务状态、待决事项和接口人。如果短期内无法替换，这条资源约束就升级为硬约束，需要重新评估受影响阶段的排期：把不依赖该角色的任务前移，把强依赖任务后移或增加外部支援，并同步检查是否影响已设定的里程碑。
调整后更新约束清单和计划基线，保留变更前后的对比记录，并在下一次阶段评审时复核资源负荷。
缓冲设多少合适，怎么防止被提前用完？
缓冲大小取决于对应约束的波动范围，可以参考历史同类项目的到货延迟、审批周期或第三方交付记录来估算，没有历史数据时先按经验值设置并在执行中修正。防止提前消耗的关键是给缓冲写明触发条件和使用审批人，例如“延迟超过五天方可启用，由项目经理评估、干系人确认”。
缓冲使用后要在约束清单中记录原因和剩余量，阶段评审时检查消耗速度是否异常，异常时回到约束本身重新评估，而不是继续追加缓冲。
约束清单和风险登记是什么关系，需要分开维护吗？
两者关注点不同。约束清单记录的是计划必须满足的条件，包括已经确定的硬约束和可协商项；风险登记记录的是可能发生、尚未确定的不利事件。一条约束如果存在兑现的不确定性，例如供应商到货时间可能延迟，可以同时在风险登记中跟踪，并注明它对应约束清单中的哪一条。
规模较小的项目可以把两者放在同一份文档的不同分区，规模较大或合规要求高的项目建议分开维护，通过编号相互引用，避免同一事项在两处出现不一致的描述。
计划发布后，约束清单多久复核一次？
建议至少在每个阶段结束时复核一次，因为瀑布项目的阶段评审本身就是检查前置条件和里程碑完成情况的节点。出现以下情况时应立即复核：合同或验收口径发生变化、外部依赖方通知延期、关键资源发生变动、监管或审计要求更新。
复核的输出是更新后的约束清单版本和必要的计划调整，变更按事先约定的提出、评估、批准流程处理，硬约束的变更通常需要干系人层面确认。
