研发团队落地瀑布模型，关键动作是把项目切成需求、设计、开发、测试、发布五个阶段，为每个阶段定清输入、交付物和评审通过条件，并规定阶段间变更的审批路径。本文面向研发团队负责人和项目经理，讨论单项目层面的落地方法：先划适用边界，再设计阶段门禁与角色分工，用一个真实项目试点跑通，最后用评审记录和返工数据检验效果。
要点总览（TL;DR）
- 先按需求变更频率和验收方式判断项目是否适合瀑布：需求立项时已确认、有固定验收节点、以文档化交付为主的项目适合；需求边做边变、以持续可用版本验收的项目不必套用五阶段。
- 阶段划分采用需求、设计、开发、测试、发布五段，每段定清输入、动作、输出、评审人和通过标志，未通过不进入下一阶段，返工超出原阶段边界时回退到受影响的上游阶段重走门禁。
- 角色分工用 RACI 形式落到阶段：项目经理组织评审与跟踪，需求、开发、测试负责人各自承担本阶段交付物，评审人由不直接承担该阶段交付的角色担任，评审与变更记录集中留存。
- 用一个真实项目试点跑通全流程，重点验证变更审批和评审不通过时的回退处理；首轮运行后用阶段返工率、门禁一次通过率、变更审批覆盖率三项指标检查落地效果。
- 流程文档与团队实际做法不一致时，以实际做法为准修订文档或补上缺失动作，二者选其一，避免长期两张皮。
先判断哪些研发项目适合用瀑布模型
瀑布模型对需求稳定性和交付确定性要求较高，落地第一步是判断项目是否具备这两个前提。把瀑布套到需求边做边变的产品研发上，阶段门禁会频繁被突破，评审流于形式，流程本身反而成为负担。
适合瀑布的项目通常具备三个特征：需求在立项时已相对明确，验收标准和交付物清单可以提前写清；存在外部合规、招投标或客户验收等固定节点，进度计划需要按节点倒排；变更频率低，或变更必须经过正式审批才能进入开发。需求探索性强、需要频繁试错验证的产品研发，更适合迭代方式推进，不必强行套用五阶段。
单项目范围内的判断可以按两个维度分类：需求变更频率和验收方式。变更频率低、以文档化验收为主的项目适合瀑布；变更频率高、以可用版本持续验收为主的项目不适合。下表给出常见项目特征的判断参考。
| 项目特征 | 是否适合瀑布 | 理由 |
|---|---|---|
| 需求在立项时已确认，变更需走审批 | 适合 | 阶段门禁有稳定的评审依据 |
| 有外部合规、招投标或客户验收固定节点 | 适合 | 可按节点倒排阶段计划与里程碑 |
| 交付物以文档、规格说明书、验收报告为主 | 适合 | 每阶段输出可被正式评审和签字确认 |
| 需求边做边变，产品方向需要试错验证 | 不适合 | 阶段门禁会被频繁突破，评审失去意义 |
| 交付以持续可用的版本为主，验收标准随迭代调整 | 不适合 | 固定阶段划分与验收方式冲突 |
| 项目周期短、范围小、参与角色少 | 可简化使用 | 可合并部分阶段，保留关键门禁即可 |
判断结论应写入立项材料，说明本项目采用瀑布方式的依据。同一团队可以同时存在瀑布项目和迭代项目，按项目类型分别管理，不必在团队层面二选一。
阶段怎么划分：五阶段与阶段门禁设计
五阶段划分的价值在于每阶段有明确的输入、动作和输出，阶段之间设门禁，未通过不进入下一阶段。阶段门禁的评审人、评审材料和通过标准需要在项目启动时一次性定清，避免每次评审临时约定。
需求阶段输入是立项材料、业务方原始诉求和初步范围说明，动作是需求调研、需求规格编写和优先级确认，输出是需求规格说明书和需求确认记录。设计阶段输入是已通过评审的需求规格，动作是概要设计、详细设计和接口设计，输出是设计文档和设计评审结论。开发阶段输入是设计文档，动作是按任务分解编码、自测和代码评审，输出是可测试的构建版本和开发完成报告。测试阶段输入是构建版本和测试方案，动作是执行测试用例、缺陷跟踪和回归，输出是测试报告和缺陷关闭记录。发布阶段输入是测试通过结论和发布方案，动作是发布准备、上线和验收，输出是发布记录和验收确认单。
阶段门禁表可按以下结构填写，评审人建议由不直接承担该阶段交付的角色担任，以保证评审独立性。
| 阶段 | 输入 | 主要动作 | 输出 | 评审人 | 通过标志 |
|---|---|---|---|---|---|
| 需求 | 立项材料、业务诉求 | 需求调研、规格编写、优先级确认 | 需求规格说明书 | 项目经理、业务方代表、开发与测试负责人 | 需求评审记录签字，遗留问题有明确处理结论 |
| 设计 | 已评审需求规格 | 概要设计、详细设计、接口设计 | 设计文档、设计评审结论 | 技术负责人、开发负责人、测试负责人 | 设计评审通过，关键接口与数据方案无未决项 |
| 开发 | 设计文档 | 任务分解、编码、自测、代码评审 | 可测试构建版本、开发完成报告 | 开发负责人、技术负责人 | 代码评审完成，自测用例通过，提测单已提交 |
| 测试 | 构建版本、测试方案 | 用例执行、缺陷跟踪、回归 | 测试报告、缺陷关闭记录 | 测试负责人、项目经理 | 严重缺陷清零，测试报告结论为通过 |
| 发布 | 测试通过结论、发布方案 | 发布准备、上线、验收 | 发布记录、验收确认单 | 项目经理、业务方代表 | 验收确认签字，发布记录归档 |
阶段未通过时，评审人应给出具体的不通过原因和整改项，由该阶段负责人组织返工，返工完成后重新提交评审。返工范围超出原阶段边界时，回退到受影响的上游阶段重新走门禁，不能带着未关闭的问题进入下一阶段。
阶段间变更需要走申请与审批路径：变更提出人填写变更申请，说明变更内容、影响阶段和交付物；项目经理评估对进度和范围的影响；涉及需求或设计的变更由对应评审人审批；审批通过后更新需求规格或设计文档，并在变更记录中登记。未经审批的变更不进入开发，避免阶段交付物与实际情况脱节。
在工具层面，阶段计划、交付物和评审节点需要有统一的承载位置。ONES 支持用「项目计划」创建工作分解结构，按目标、交付物或项目阶段等维度分解计划和工作，并可为任务设置前后置依赖、用里程碑标记重要决策点；其瀑布项目管理方案覆盖从立项到收尾的全过程，将需求、研发、测试和资源管理流程连接起来。团队可据此把阶段门禁的评审任务和交付物挂在对应阶段下，使计划与评审记录保持在同一处。
角色与交付物怎么分工
瀑布流程中每个阶段都有明确的负责人和签字确认点，角色职责不清是门禁失效的常见原因。建议用 RACI 形式明确谁负责执行、谁负责审批、谁需要被咨询、谁需要被知会。
| 角色 | 需求阶段 | 设计阶段 | 开发阶段 | 测试阶段 | 发布阶段 |
|---|---|---|---|---|---|
| 项目经理 | 组织需求评审，确认范围 | 协调设计评审排期 | 跟踪进度与依赖 | 跟踪缺陷关闭与测试结论 | 组织发布与验收 |
| 需求负责人 | 负责规格编写与需求确认 | 咨询，解释需求背景 | 知会，处理需求澄清 | 知会，确认验收口径 | 参与验收 |
| 开发负责人 | 参与需求评审，评估可行性 | 负责设计文档与设计评审 | 负责编码、自测与提测 | 支持缺陷修复 | 负责发布实施 |
| 测试负责人 | 参与需求评审，识别可测性 | 参与设计评审，编写测试方案 | 准备测试用例与环境 | 负责测试执行与测试报告 | 参与发布验证 |
| 评审人 | 审批需求规格 | 审批设计文档 | 审批提测结论 | 审批测试报告 | 审批验收确认 |
交付物责任清单与上表对应：需求规格说明书由需求负责人编写、评审人审批；设计文档由开发负责人编写、技术负责人审批；开发完成报告由开发负责人提交、开发负责人与技术负责人确认；测试报告由测试负责人编写、项目经理审批；发布记录与验收确认单由项目经理归档、业务方代表签字。
跨角色交接时需要传递三类信息：交付物当前版本及其存放位置、未关闭问题的清单及责任人、下一阶段的输入要求。交接以书面记录为准，口头沟通结论需要回写到对应交付物或评审记录中。
评审记录和变更记录应集中留存，按项目、阶段和日期可检索。记录内容包括评审时间、参与人、评审结论、遗留问题及处理结果；变更记录包括变更内容、影响范围、审批人和生效时间。这些记录既是阶段门禁执行的证据，也是后续复盘和检查的依据。
用一个真实项目跑通：示例流程
以下为演示情景，用于说明瀑布流程从立项到发布的完整执行方式，不作为真实案例引用。假设某团队承接一个客户管理系统升级项目，需求在合同附件中已明确，客户要求三个月后完成验收。
项目按五阶段排期：需求阶段第1至3周，设计阶段第4至5周，开发阶段第6至10周，测试阶段第11至12周，发布阶段第13周。每个阶段结束设一个里程碑作为门禁节点，里程碑与阶段评审会绑定。
需求阶段产出需求规格说明书，第3周末召开需求评审会，项目经理、业务方代表、开发负责人和测试负责人参加。评审发现报表导出需求描述不完整，结论为有条件通过，遗留问题由需求负责人在一周内补充，补充内容经评审人确认后关闭。设计阶段据此完成概要设计与接口设计，设计评审通过后进入开发。
开发阶段进行到第8周时，客户提出增加审批流节点配置的需求。需求负责人提交变更申请，说明该变更影响设计文档中的流程模块和测试用例范围。项目经理评估后认为增加约5个工作日工作量，测试阶段需相应压缩回归范围。变更经评审人审批通过，设计文档更新版本，测试负责人同步调整测试方案，变更记录登记了申请时间、审批人和生效范围。未走审批的临时口头需求不进入开发排期。
测试阶段第12周发现两个严重缺陷，测试报告结论为不通过，项目回退到开发阶段修复。开发负责人组织修复并重新提测，回归通过后测试报告更新为通过，发布阶段按原计划顺延三个工作日执行。发布阶段完成上线和客户验收，验收确认单签字归档。
这个示例说明两点：变更走审批后，影响评估和交付物更新可以同步完成；评审不通过时按回退规则处理，比带着问题推进更能控制后期风险。阶段延期应在周报中记录原因和调整后的计划，由项目经理统一对外沟通。
落地完成检查：怎么判断跑通了
流程是否真正落地，看的是门禁是否按标准执行、记录是否可追溯，而不是流程文档写得多完整。首轮运行结束后，可按以下清单逐项核对。
- 每个阶段是否都召开了门禁评审，评审人是否符合事先约定，评审材料是否在评审前发出。
- 评审记录是否齐全，是否包含评审结论、遗留问题和处理结果，遗留问题是否全部关闭或有明确处理计划。
- 阶段间变更是否全部走申请与审批，变更记录是否包含影响评估和审批人，是否存在未登记的变更进入开发。
- 阶段返工情况是否可统计，包括返工次数、返工原因和返工耗时占比。
- 进度偏差是否可量化，各阶段实际完成时间与计划的偏差是否记录并说明原因。
- 流程文档与团队实际做法是否一致，是否存在文档规定评审而实际跳过、或实际执行了文档未写的步骤。
观察指标建议首轮运行后统计三项：阶段返工率，即发生返工的阶段数占阶段总数的比例；门禁一次通过率，即首次评审即通过的阶段占比；变更审批覆盖率，即走完审批的变更数占全部变更数的比例。三项指标没有统一合格线，团队可结合项目类型设定基线，在后续项目中对比变化。
未达标项的整改方向按问题类型区分：评审记录缺失的，补齐记录模板并把评审材料提交设为门禁前置条件；变更未走审批的，在变更入口处增加审批节点并明确未经审批不予排期；返工率偏高的，回看返工集中的阶段，检查该阶段输入是否充分、评审标准是否过松；文档与实际做法不一致的，以实际做法为准修订文档，或补上缺失的执行动作，二者选其一，避免长期两张皮。
首轮运行评估结论应形成书面记录，列出达标项、未达标项和整改责任人及完成时间，作为下一轮流程优化的输入。流程在项目中持续按此方式检查和修订，瀑布模型才算在团队中真正运转起来。
常见问题
团队里既有瀑布项目又有迭代项目，流程会不会互相干扰？
可以在同一团队内按项目类型分别管理，不必在团队层面二选一。判断依据是项目本身的需求稳定性和验收方式：需求立项时已确认、有固定验收节点的项目走瀑布五阶段；需求探索性强、以持续可用版本验收的项目走迭代方式。两类项目共用角色和记录规范即可，阶段门禁只对瀑布项目生效，避免把门禁要求套到迭代项目上造成额外负担。
阶段评审不通过，但项目进度已经很紧，能不能先进入下一阶段再补？
不建议带着未关闭的问题进入下一阶段。评审不通过时应由评审人给出具体的不通过原因和整改项，由该阶段负责人组织返工后重新提交评审；返工范围超出原阶段边界时，回退到受影响的上游阶段重新走门禁。进度紧张时可以在评审会上明确遗留问题的关闭时间和责任人，把“有条件通过”作为正式结论记录，但遗留问题必须有明确处理计划，不能只做口头约定。
变更审批由谁把关，项目经理一个人签字够不够？
审批人应与变更影响的交付物对应。涉及需求或设计的变更，由对应阶段的评审人审批；只影响排期、不影响交付物内容的变更，可由项目经理评估后审批。审批前需要完成影响评估，说明变更影响哪些阶段、哪些交付物和多少工作量。审批通过后同步更新需求规格或设计文档，并在变更记录中登记申请时间、审批人和生效范围，避免交付物与实际情况脱节。
首轮运行后三项指标都不理想，应该先改哪里？
按问题类型定位整改方向，不必同时改所有环节。评审记录缺失的，先补齐记录模板，把评审材料提交设为门禁前置条件；变更未走审批的，在变更入口增加审批节点，明确未经审批不予排期；返工率偏高的，回看返工集中的阶段，检查该阶段输入是否充分、评审标准是否过松。三项指标没有统一合格线，团队可结合项目类型设定基线，在后续项目中对比变化，优先处理影响门禁有效性的问题。
小项目也要走完整的五阶段和五次评审吗？
周期短、范围小、参与角色少的项目可以简化使用，合并部分阶段，保留关键门禁即可。例如把设计与开发合并评审、把测试与发布合并验收，但需求确认和最终验收两个节点建议保留，因为它们决定了项目范围和交付是否成立。简化方案应在立项材料中写明，说明合并了哪些阶段、保留了哪些门禁，避免执行时随意跳过评审。
