项目主计划要把约束当作计划输入来处理：先按范围、时间、资源、成本、质量、依赖、合规与组织八类盘点，再判断每条约束是硬约束还是可协商约束，然后把硬约束转成里程碑、缓冲、资源承诺和审批节点写入主计划，最后用约束清单与基线评审确认计划可执行。下文给出可直接套用的分类框架、登记表字段、映射方法与检查清单。
要点总览（TL;DR）
- 主计划编制前先按范围、时间、资源、成本、质量、依赖、合规、组织八类盘点约束，每类记录内容、提出方与影响对象。
- 用硬约束与可协商约束区分处理方式：法规、合同、外部节点、不可替代资源属于硬约束，内部偏好、可调整人力、可裁剪范围属于可协商约束。
- 硬约束转成里程碑、强制节点与审批关口，资源约束转成资源承诺，依赖约束转成交付时间与交接责任，不确定性转成缓冲与备选路径。
- 约束收集由各专业口负责、项目经理维护登记表、治理层批准基线；基线发布后影响里程碑或资源承诺的变更需重新评审。
- 基线发布前用检查清单核对八类约束记录、硬约束对应安排、来源可追溯、冲突取舍与变更规则，缺口补齐后再发布。
主计划先盘清哪几类约束
主计划只盯工期，往往在排期阶段才发现范围没定、验收标准含糊、关键角色不到位。约束盘点的目标是在编制计划之前，把影响计划成立的条件全部摆到桌面上。建议按以下八类逐项收集，每类至少回答“这条约束是什么、由谁提出、影响哪个计划要素”。
| 约束类别 | 需要收集的内容 | 典型来源 |
|---|---|---|
| 范围与交付物边界 | 交付物清单、明确不做的内容、验收颗粒度、变更受理范围 | 合同、需求文档、业务方确认记录 |
| 时间与里程碑 | 外部强制节点（上线窗口、监管报送日、客户验收日）、内部关键节点 | 合同条款、市场活动排期、上级计划 |
| 资源与技能 | 关键角色数量、稀缺技能、外部供应商人力、到位时间 | 职能负责人承诺、资源池排期 |
| 成本与预算 | 预算上限、采购周期、外包费用口径、付款节点 | 财务批复、采购制度 |
| 质量与验收标准 | 验收指标、测试覆盖要求、评审层级、缺陷关闭标准 | 质量规范、客户验收条款 |
| 内外部依赖 | 接口交付时间、上下游团队交接物、第三方系统就绪条件 | 接口协议、依赖方计划 |
| 合规、安全与审批 | 必须通过的审批、数据安全要求、审计留痕要求 | 法务、安全、合规部门 |
| 组织与治理 | 决策权归属、汇报节奏、变更审批层级、跨部门协调机制 | 项目章程、治理制度 |
这张表可以直接作为收集清单使用：每格填“有约束/无约束/待确认”，填“有约束”的进入下一步登记。标注“待确认”的条目要在基线评审前关闭，否则会以隐性假设的形式留在计划里。
把约束分成硬约束与可协商约束
约束性质决定它在计划中的处理方式。硬约束必须满足，计划围绕它倒排；可协商约束可以与范围、时间、资源交换。判断标准要写进登记表，避免评审时各说各话。
判定标准
- 硬约束：由法规或合同规定、外部节点不可移动、资源不可替代且无法增补、验收标准由客户单方确定。这类约束一旦违反，计划即判定失败。
- 可协商约束：内部管理偏好、可调整的人力投入量、可裁剪或分期交付的范围、可优化的流程环节。这类约束可以作为交换筹码，但交换需要记录。
约束登记表字段
| 字段 | 填写要求 |
|---|---|
| 约束描述 | 一句话写清约束内容，避免“资源紧张”这类无法验证的表述 |
| 类别 | 对应八类中的一类 |
| 性质 | 硬约束 / 可协商约束 |
| 来源 | 提出方与依据文件，如合同第几条、某部门书面确认 |
| 影响对象 | 受影响的里程碑、交付物、角色或预算项 |
| 验证方式 | 如何确认约束真实成立，如查阅合同、与依赖方书面确认 |
| 优先级 | 冲突时的取舍顺序，用高/中/低或数字排序 |
登记过程中要主动找冲突：两个硬约束可能互相排斥，例如外部上线日与合规审批周期重叠；可协商约束之间也可能争夺同一批人力。发现冲突时当场标注优先级，并写明取舍理由，留待评审确认，不要留到排期阶段临时处理。
约束如何转成主计划中的具体安排
约束只有落到计划要素上才生效。映射的基本原则是：硬约束变成不可移动的节点，可协商约束变成可调整的安排，不确定性变成缓冲。
| 约束类型 | 计划要素 | 落地动作 |
|---|---|---|
| 硬性时间节点 | 里程碑、强制节点 | 在计划中设为里程碑，倒排前置工作，节点前留出评审与整改时间 |
| 合规与审批要求 | 审批关口 | 在对应阶段设置审批节点，明确提交材料与审批人，审批周期计入工期 |
| 资源与技能约束 | 资源承诺 | 写明关键角色、投入比例与到位时间，由职能负责人确认后写入计划 |
| 依赖约束 | 接口交付时间、交接责任 | 为每个依赖设定交付日期与接收人，交接物清单随计划发布 |
| 不确定性与风险 | 缓冲、备选路径 | 在关键路径末端或高风险节点前设置时间缓冲，对不可替代资源准备备选方案 |
缓冲要写明归属：是项目级缓冲还是某阶段缓冲，由谁决定动用。备选路径要写清触发条件，例如“若接口方在约定日期未交付，则启用本地模拟数据先行联调”。
约束变更需要规则。建议约定：硬约束变更必须经发起方书面确认并重新评审基线；可协商约束的调整由项目经理评估影响后报批。基线发布后，任何影响里程碑或资源承诺的变更都要走评审，更新后的计划重新设基线，保留变更前后的对比记录，便于追溯。在工具层面，ONES 支持为项目任务设置前后置依赖、用里程碑标记重要时间点，并支持设置计划和里程碑基线、对比计划与执行的偏差、追溯变更细节，可作为承载约束节点与基线更新的协作环境；资源饱和度可借助工时数据查看，用于核对资源承诺是否兑现。
角色分工与各阶段交付物
约束管理不是项目经理一个人的事。收集靠各专业口，确认靠有决策权的人，批准靠治理层。下表给出常见分工，组织可按实际治理结构调整。
| 角色 | 主要职责 |
|---|---|
| 项目经理 | 组织约束盘点、维护约束登记表、编制映射结果、发起基线评审与变更 |
| 职能负责人 | 确认资源与技能约束，给出人力承诺与到位时间 |
| 技术负责人 | 确认技术依赖、接口交付时间与技术可行性约束 |
| 业务方 | 确认范围边界、验收标准与业务时间节点 |
| 合规/安全/法务 | 确认合规审批要求、安全标准与合同条款约束 |
四个环节的输入输出如下：
- 约束收集：输入为合同、需求文档、制度文件与各方访谈；输出为填好的八类盘点表。
- 约束确认：输入为盘点表；输出为约束登记表，每条约束有来源、性质与验证方式。
- 约束评审：输入为登记表与映射草案；输出为评审记录，冲突取舍与优先级经确认。
- 基线发布：输入为评审通过的主计划；输出为发布版主计划与基线，约束登记表作为附件归档。
变更路径建议统一为：提出人填写变更说明与影响分析，项目经理评估对里程碑、资源和缓冲的影响，按约束性质提交对应层级批准，批准后更新计划并重设基线。约束登记表与主计划文档可以放在同一协作空间维护，ONES Wiki 支持页面组关联项目、文档嵌入任务进度和报表，便于把登记表、评审记录与计划放在一处供团队查阅。
示例：一个交付项目的主计划约束处理
以下为演示情景，用于说明方法，不代表真实客户案例。某团队负责为客户交付一套业务系统，计划周期四个月。
约束清单
| 约束描述 | 类别 | 性质 | 来源 | 优先级 |
|---|---|---|---|---|
| 客户要求第16周完成上线验收 | 时间 | 硬约束 | 合同条款 | 高 |
| 数据迁移须通过客户安全审批 | 合规 | 硬约束 | 客户安全规范 | 高 |
| 核心开发仅2人，第3周才能到位 | 资源 | 可协商 | 职能负责人确认 | 中 |
| 报表模块可分期交付 | 范围 | 可协商 | 业务方口头同意，待书面确认 | 中 |
| 依赖第三方支付接口第10周就绪 | 依赖 | 硬约束 | 接口协议 | 高 |
冲突识别与取舍
安全审批通常需要两到三周，若安排在上线前两周启动，将与第16周验收节点冲突。评审确认的取舍是：审批材料在第12周提交，审批周期计入计划；报表模块分期交付作为交换条件，为审批整改留出时间。核心开发晚到位与前期设计工作量冲突，处理方式是把部分设计工作前置给技术负责人承担，并在计划中标注该安排依赖技术负责人投入。
转成计划安排
- 第16周验收设为里程碑，第12周安全审批提交设为强制节点，两者之间设一周整改缓冲。
- 第10周支付接口就绪设为依赖交付节点，接收人与交接物写入计划。
- 核心开发第3周到位写入资源承诺，由职能负责人确认；到位前的工作安排标注责任人。
- 报表模块二期范围写入计划附注，作为范围交换的记录。
评审确认方式
评审会上逐条核对登记表，冲突取舍由业务方与合规方当场确认，会议记录附在计划文档后。基线发布后，上述节点与承诺进入跟踪；后续如需调整验收日或审批范围，按变更路径重新评审并更新基线。
主计划约束的完成检查
基线发布前，用以下清单逐项核对，全部通过才视为约束已被完整纳入主计划。
| 检查项 | 通过标准 |
|---|---|
| 八类约束是否都有记录 | 每类均有条目，或明确标注“不适用”并写明理由 |
| 硬约束是否有对应安排 | 每条硬约束在主计划中有里程碑、强制节点、审批关口或资源承诺 |
| 来源与验证方式是否可追溯 | 登记表中每条约束可查到依据文件或确认人 |
| 冲突与优先级是否经评审 | 存在冲突的约束有取舍记录，优先级经相关方确认 |
| 变更规则与责任人是否明确 | 变更提出、评估、批准路径清晰，各环节责任人有名有岗 |
| 缓冲与备选路径是否写明 | 关键路径上的不确定性有对应缓冲，触发条件可判断 |
检查中发现缺口，回到对应环节补齐后再发布基线。约束登记表、映射结果与评审记录随基线一并归档，作为后续变更评审和计划复盘的依据。
常见问题
约束登记表应该在项目哪个阶段建立，和主计划编制是什么关系？
约束登记表应在主计划编制启动时同步建立，作为计划的输入材料，而不是计划编完后的补充说明。实际操作中，项目经理在编制前组织各专业口完成八类盘点，把有约束的条目登记来源、性质与验证方式，再据此编制里程碑、资源承诺与缓冲。登记表与主计划一起提交基线评审，评审通过后作为附件归档，后续变更评审以它为对照依据。
两个硬约束互相冲突、都无法调整时怎么办？
硬约束冲突说明原定计划条件不成立，需要在评审层面做取舍，而不是在排期时硬塞。常见处理有三条路径：一是调整项目范围或分期交付，把冲突部分移出本期；二是由发起方书面确认放宽其中一条约束，并记录放宽依据；三是增加资源或引入外部支持，改变约束成立的前提。无论选哪条，都要在登记表中标注取舍理由与批准人，并同步更新主计划中的对应节点。
可协商约束在计划执行中被单方面改动，如何处理？
可协商约束的调整也需要走记录和评估，不能默认它可以随时变动。建议约定：调整由提出人填写变更说明，项目经理评估对里程碑、资源和缓冲的影响，按约束性质提交对应层级批准。若调整影响已发布的里程碑或资源承诺，需要重新评审并更新基线，保留变更前后的对比记录。把可协商约束的调整纳入同一变更路径，可以避免它逐步侵蚀硬约束留下的缓冲。
约束清单和里程碑在协作工具中如何承载，便于后续追溯？
常见做法是把约束登记表作为文档维护，把硬约束对应的节点建成里程碑，两者放在同一项目空间内互相引用。ONES 支持为项目任务设置前后置依赖、用里程碑标记重要时间点，并支持设置计划和里程碑基线、对比计划与执行的偏差、追溯变更细节；ONES Wiki 支持页面组关联项目、文档嵌入任务进度和报表，可用于承载登记表与评审记录。具体字段和权限按团队实际配置。
约束盘点做到什么程度算完整，有没有可以量化的标准？
可以用检查清单作为通过标准：八类约束每类都有条目或明确标注不适用并写明理由；每条硬约束在主计划中有里程碑、强制节点、审批关口或资源承诺；每条约束可查到依据文件或确认人；存在冲突的约束有取舍记录且优先级经相关方确认；变更路径与各环节责任人明确；关键路径上的不确定性有对应缓冲和可判断的触发条件。全部满足后再发布基线。
