固定上线日期不能动，功能方向却还在验证，这是许多项目同时面对的现实。把全部工作压进瀑布计划，探索部分会被过早锁定；全部改成迭代，里程碑承诺又缺少稳定的基线。可行的做法是先按不确定性把工作项分成两类，再为两类工作分别设定阶段、节奏、评审和交接规则，用一份混合适配规则表把承诺与探索接起来。
要点总览（TL;DR）
- 先按需求确定性、验收标准可预先定义程度、外部承诺强度三个维度，把项目工作项逐项归入瀑布或迭代，边界模糊项先探索、达到可定义标准后转入瀑布。
- 混合适配规则表要写清瀑布阶段划分与基线设置、迭代长度与评审节奏、接口交付物的接收条件，以及变更是否影响里程碑承诺这一唯一判断口径。
- 项目负责人对里程碑承诺和整体规则负责，瀑布阶段负责人对阶段交付物与评审负责，迭代团队对增量与探索结论负责，接口交付物由提出方和接收方共同确认。
- 规则发布后按分类覆盖、交接记录、变更路径、评审节奏、基线设置逐项检查；接口反复返工、变更频繁穿越闸门、迭代结论无法支撑里程碑决策是需要修订规则的信号。
- 规则表、分类表和职责矩阵作为项目文档与工作项关联存放，交接与变更记录可追溯，便于在里程碑评审中同时查看阶段进展和探索结论。
先做一次工作分类：哪些走瀑布，哪些走迭代
分类的目的不是给团队贴标签，而是决定每一项工作用什么方式管理和验收。判断时看三个维度，三个维度都指向“可预先确定”的，归入瀑布；任一维度存在明显不确定的，归入迭代。
| 判断维度 | 偏瀑布的信号 | 偏迭代的信号 |
|---|---|---|
| 需求确定性 | 需求内容、范围和优先级已确认，短期内预计不变 | 需求方向存在多种可能，需要用户反馈或技术验证才能收敛 |
| 验收标准可预先定义程度 | 验收条件可以逐条写清，测试用例能提前设计 | 验收标准只能给出方向，需要看到可运行结果后再细化 |
| 外部承诺强度 | 与合同、监管、对外发布窗口或客户验收条款直接绑定 | 对外只承诺探索结论或能力方向，不承诺具体功能清单 |
分类的输入包括需求清单、里程碑清单、合同或验收条款，以及技术方案说明。操作上分三步：先把项目全部工作项列全，包括需求、设计、开发、测试、部署和文档；再对每个工作项按上述三个维度逐项判断并写明理由；最后确定方法归属和责任人。输出是一张工作项分类表，至少包含工作项、不确定性判断、方法归属、责任人四列。
边界模糊的工作项不必在分类阶段强行裁决。常见做法是先按迭代方式探索，设定一个明确的转出条件，例如原型通过评审、关键接口验证完成、验收标准可以逐条写出。达到条件后，把剩余工作转入瀑布阶段，按阶段交付物和评审管理。这样既避免过早锁定范围，也保证转入后承诺可追踪。
分类完成的标志是：每个工作项都有明确的方法归属和责任人，没有“待定”项；跨类工作项写明了转出条件和预计转出时点。
混合适配规则表：阶段、节奏与交接怎么定
分类解决“分什么”，规则表解决“分完之后怎么跑”。规则表要写清四件事：瀑布部分怎么分阶段、迭代部分按什么节奏、两类工作在哪里交接、变更从哪条路径进入。
瀑布部分按交付物或项目阶段划分，例如需求确认、方案设计、开发实现、集成测试、上线准备。每个阶段结束时设置阶段评审，评审通过后对计划和里程碑设置基线。基线的作用是形成可对比的承诺版本，后续偏差和变更都能对照基线追溯。里程碑本身标记关键时间点、事件或决策点，与阶段评审时点对齐，避免评审和承诺脱节。
迭代部分确定固定长度，例如两周，每个迭代结束交付可运行的增量并组织评审。迭代评审的产出不只是演示，还要形成探索结论：哪些方向验证通过、哪些需要调整、哪些可以转入瀑布阶段。迭代长度一旦确定，在项目内保持稳定，避免因里程碑压力随意拉长或压缩。
两类工作的衔接靠接口交付物。接口交付物是迭代团队向瀑布阶段移交的、可被后续阶段直接使用的东西，例如通过评审的原型、确认的接口定义、定稿的需求说明、验证报告。规则表要为每个接口交付物写明提出方、接收方、交付格式和接收条件。接收方确认接收，交接才算完成；接收条件不满足时退回迭代继续完善，不进入下游阶段。
| 规则项 | 瀑布部分 | 迭代部分 |
|---|---|---|
| 节奏 | 按阶段推进，阶段末评审 | 固定迭代长度，迭代末评审 |
| 基线 | 阶段评审通过后设置计划与里程碑基线 | 不设范围基线，按迭代目标管理 |
| 评审重点 | 阶段交付物完整性、承诺可达性 | 增量可用性、探索结论是否支撑下一步决策 |
| 交接 | 接收接口交付物并确认 | 按接收条件提交接口交付物 |
| 变更路径 | 影响里程碑承诺的变更走变更控制，更新基线 | 不影响承诺的变更在迭代内消化，记录在迭代结论中 |
变更路径必须唯一。判断标准是看变更是否影响已发布的里程碑承诺：影响承诺的，提交变更申请，评估对阶段、资源和上线日期的影响，批准后更新基线并通知干系人；不影响承诺的，由迭代团队在迭代内处理，在迭代评审中说明。两条路径并存会让责任不清，规则表要明确只有这一个判断口径。
规则表经项目负责人、瀑布阶段负责人、迭代团队代表和关键干系人确认后发布，作为项目内的方法依据。发布时同步说明生效范围和修订方式。
角色与交付物分工
混合模式下最容易出现的问题是两套做法互相推诿：迭代团队说里程碑是项目负责人定的，瀑布阶段负责人说增量质量由迭代团队负责。避免推诿靠职责矩阵，把每个关键交付物的负责人写清楚。
- 项目负责人对里程碑承诺和整体规则负责，包括维护混合适配规则表、组织里程碑评审、裁决变更是否影响承诺、协调两类工作之间的资源冲突。
- 瀑布阶段负责人对阶段交付物和阶段评审通过负责，包括组织阶段内工作、准备评审材料、确认接口交付物接收、维护阶段基线。
- 迭代团队对增量交付和探索结论负责，包括按迭代目标交付可运行增量、在评审中给出明确的探索结论、按接收条件提交接口交付物。
- 接口交付物实行提出方与接收方双责：提出方保证交付物符合约定格式和接收条件，接收方在规定时限内确认接收或提出具体退回意见，双方确认记录留存在项目文档中。
| 关键交付物 | 负责人 | 配合方 |
|---|---|---|
| 工作项分类表 | 项目负责人 | 瀑布阶段负责人、迭代团队 |
| 混合适配规则表 | 项目负责人 | 全体干系人确认 |
| 阶段交付物与评审结论 | 瀑布阶段负责人 | 项目负责人、质量角色 |
| 迭代增量与探索结论 | 迭代团队 | 项目负责人 |
| 接口交付物 | 提出方 | 接收方确认 |
| 变更申请与基线更新 | 项目负责人 | 受影响阶段负责人 |
职责矩阵完成的标志是：规则表中列出的每个关键交付物都能对应到唯一负责人，接口交付物都有提出方和接收方，且没有交付物落在两个角色之间的空白地带。
示例：一个里程碑加探索交付的项目如何跑起来
以下为演示情景。某产品需要在第四季度末完成一次对外版本发布，发布日期已对外承诺；其中智能推荐模块的具体形态尚待验证，其余账户、权限、结算等功能需求已确认。
按分类标准处理：账户、权限、结算、发布部署和合规文档的需求确定、验收标准可预先写出、与对外发布承诺直接绑定，归入瀑布；智能推荐模块的需求方向有多种可能，验收标准需要看到效果后再定，归入迭代，转出条件设为“推荐策略经两轮用户验证，核心指标达到约定阈值，接口定义定稿”。分类表逐项登记后，每个工作项都有责任人和方法归属。
按规则表排节奏：瀑布部分划分为需求确认、方案设计、开发实现、集成测试、上线准备五个阶段，每个阶段末评审，评审通过后设置基线和里程碑标记。迭代部分固定两周一个迭代，共安排四个迭代，每个迭代末评审并输出探索结论。第三个迭代结束时若转出条件达成，推荐模块的工程化开发转入瀑布的开发实现阶段，作为接口交付物移交。
一次接口交接的过程：迭代团队在第二个迭代末提交推荐接口定义文档和验证报告，瀑布阶段负责人按接收条件检查字段完整性、错误码约定和性能指标，确认接收后登记到项目文档，下游开发据此排期。一次变更的处理：业务方在第三个迭代提出增加一种推荐场景，评估后确认不影响对外发布的功能清单和上线日期，由迭代团队在迭代内消化，并在迭代评审中记录；若该变更需要新增外部依赖并推迟上线，则应提交变更申请，走变更控制并更新基线。
示例能对应到规则表每一条：分类有依据，阶段和迭代有节奏，交接有接收确认，变更按是否影响承诺分流。项目负责人据此在里程碑评审中同时看到阶段进展和探索结论，判断发布承诺是否仍然成立。
规则落地后的检查与调整
规则发布后需要定期检查执行情况，检查项可以直接对照规则表逐条核对。
- 分类是否覆盖全部工作项，新增工作项是否及时归类，边界模糊项是否写明了转出条件。
- 每个接口交付物是否都有提出方、接收方和明确的接收条件，交接记录是否完整。
- 变更路径是否唯一，是否存在绕过变更控制直接修改里程碑承诺的情况。
- 里程碑评审与迭代评审是否按既定节奏执行，评审结论是否形成记录并支撑下一步决策。
- 基线是否在阶段评审通过后及时设置，偏差是否能对照基线说明。
出现以下信号时，说明规则需要调整：接口交付物反复返工，通常意味着接收条件写得不具体或交接时点安排不合理；变更频繁穿越闸门，说明变更判断口径不清或承诺范围界定过宽；迭代结论无法支撑里程碑决策，说明迭代目标与里程碑关注点脱节，需要重新对齐评审内容。
调整方式是由项目负责人提出修订，说明触发信号、修改内容和影响范围，经关键干系人确认后发布新版本，保留版本记录和修订说明。规则版本记录与项目文档一并归档，后续复盘以最新版本为准。检查通过并形成规则版本记录，即完成本轮规则建设。
在工具承载上，这类混合规则需要项目计划能同时容纳阶段任务与迭代。ONES 的项目计划支持按阶段或交付物分解工作、设置任务依赖并用里程碑标记关键决策点，也支持在项目计划中关联迭代和研发任务，便于项目负责人把阶段评审时点与迭代节奏放在同一视图里跟踪；设置计划和里程碑基线后，可对比计划与执行的偏差并追溯变更细节。规则表、分类表和职责矩阵可以作为项目文档与工作项关联存放，让每次交接和变更都有对应记录可查。
常见问题
如果探索性工作在里程碑前无法收敛，应该怎么处理？
先看转出条件是否仍然合理。若探索结论显示方向需要调整，由项目负责人组织评估对里程碑承诺的影响：影响承诺的，走变更控制，调整范围或日期并更新基线；不影响承诺的，在迭代内继续探索，同时明确最晚转出时点。关键是提前在规则表中约定转出时点，而不是等到里程碑临近才判断。
同一个工作项在项目中途从迭代转入瀑布，需要补哪些记录？
至少补三项：一是转出条件达成的证据，例如评审结论、验证报告或定稿的验收标准；二是接口交付物的接收确认记录，由接收方确认格式和条件满足；三是方法归属变更的登记，更新工作项分类表并注明变更时点和责任人。这样后续对照基线追溯时，能说明该项工作为何改变管理方式。
迭代团队和瀑布阶段负责人对接口交付物质量有分歧时怎么办？
回到规则表中写明的接收条件逐条核对，把分歧落到具体条款上，例如字段完整性、性能指标或文档格式。接收条件本身不清晰时，由项目负责人组织双方补充明确，并作为规则修订记录。避免用口头判断代替接收条件，否则同类返工会反复出现。
混合规则需要多久检查一次，检查结果记在哪里？
检查节奏可与里程碑评审对齐，在每个阶段评审时顺带核对分类覆盖、交接记录和变更路径执行情况；迭代评审中关注探索结论是否支撑里程碑决策。检查结果和规则修订说明一并归档到项目文档，保留版本记录，后续复盘以最新版本为准。
小团队人手有限，混合规则能否简化？
可以简化形式，保留三项核心内容：工作项的方法归属与责任人、接口交付物的接收条件、变更是否影响里程碑承诺的判断口径。角色可以由同一人兼任，但职责要在规则表中写明，避免交接和变更无人确认。规则表篇幅可以压缩，判断标准仍需逐项可核对。
