瀑布模型在研发团队落地，核心是把项目切成需求、设计、开发、测试、发布等顺序阶段，为每个阶段定义输入、评审和交付物，上一阶段通过评审后再进入下一阶段。落地时先确定阶段划分与准入准出标准，再明确各角色职责和签字确认方式，最后用变更控制和阶段评审保证顺序推进不失控。研发团队不必全流程照搬，可在需求变化频繁的部分引入迭代，形成以瀑布为主干的混合模式。
要点总览（TL;DR）
- 瀑布落地的第一步是写出一份团队认可的阶段定义：按需求、设计、开发、测试、发布划分阶段，为每段写清输入、活动、交付物和可核验的准出标准。
- 用 RACI 矩阵把每个阶段的任务落到具体角色，每个交付物只设一个最终签字人，交付物编写人与审核人分离，评审结论分为通过、有条件通过、不通过。
- 按启动、需求、设计、开发、测试、发布的顺序推进，每步明确输入、动作、输出和完成标志；设计与开发之间安排交接会，测试进入前检查提测条件。
- 变更必须登记、评估影响、分级审批并同步更新基线版本和受影响的已完成阶段交付物；阶段回退要明确触发条件并重新评审。
- 落地是否到位用检查清单判断：阶段定义书面化、交付物可追溯、职责到人、变更与回退机制完整运行过一次、评审记录完整。
落地前先定：阶段怎么切、每段交什么
瀑布落地的第一步是写出一份团队认可的阶段定义，明确每个阶段做什么、交什么、什么条件下算完成。阶段定义不清楚，后续的评审、签字和变更管理都会失去参照。常见做法是按需求、设计、开发、测试、发布五段划分，再根据项目类型调整名称和数量。
阶段数量是否合适，可以用两个标准判断：每个阶段能否独立组织一次评审，以及每个阶段结束时能否产出一份可交接的交付物。如果某个阶段既无法单独评审、也没有明确产物，说明切得过细，应合并到相邻阶段；如果一个阶段跨越多个月、包含多种性质不同的工作，说明切得过粗，应拆分。嵌入式或涉及硬件交付的项目，通常需要在设计后增加样机验证阶段；纯软件内部系统可以合并设计与开发评审，但测试与发布仍应分开。
每个阶段需要写清三件事：输入是什么、主要活动有哪些、输出交付物是什么。准入标准回答“能不能开始”，准出标准回答“能不能结束”。准出标准建议包含三项可核验内容：交付物齐备、评审通过、责任人签字确认。评审记录要能追溯到具体版本，避免口头通过。
| 阶段 | 主要输入 | 核心活动 | 输出交付物 | 准出标准 |
|---|---|---|---|---|
| 需求 | 项目立项说明、业务方诉求 | 需求收集、分析、优先级排序、评审 | 需求规格说明书、需求基线、验收标准 | 需求评审通过，业务方与需求负责人签字，基线版本归档 |
| 设计 | 已基线化的需求文档 | 概要设计、详细设计、接口与数据设计、设计评审 | 设计说明书、接口文档、数据库设计 | 设计评审通过，开发与测试负责人确认可实现、可测试 |
| 开发 | 设计文档、开发计划 | 编码、单元测试、代码评审、自测 | 可运行的构建版本、单元测试记录、代码评审记录 | 构建通过、单元测试达标、代码评审完成 |
| 测试 | 测试版本、需求与设计文档 | 测试用例编写与评审、系统测试、缺陷修复与回归 | 测试报告、缺陷清单、回归记录 | 测试用例执行完成，遗留缺陷达到约定标准，测试负责人签字 |
| 发布 | 测试通过版本、发布方案 | 验收测试、发布准备、上线、归档 | 验收记录、发布说明、项目归档包 | 验收通过，发布评审完成，文档与代码归档 |
这张表是落地起点，团队应结合项目实际增删行，但每一行都要有可核验的准出标准。阶段定义确定后，再进入角色分工。
角色与职责：谁在哪个阶段签字、谁负责交付
瀑布按顺序推进，责任归属必须落到具体角色，否则阶段交接容易变成“文档转手、无人负责”。建议用 RACI 矩阵把每个阶段的任务与角色对应起来：R 表示负责执行，A 表示最终签字确认，C 表示需要征询意见，I 表示需要知会。每个交付物只设一个 A，避免多头签字导致决策拖延。
| 角色 | 需求阶段 | 设计阶段 | 开发阶段 | 测试阶段 | 发布阶段 |
|---|---|---|---|---|---|
| 项目经理 | A：阶段计划与评审组织 | A：阶段进度与风险 | A：进度与依赖协调 | A：测试计划与资源 | A：发布评审与验收组织 |
| 需求负责人 | R：需求文档编写；A：需求基线 | C：需求澄清 | I：需求变更知会 | C：验收标准确认 | C：验收结果确认 |
| 设计负责人 | C：可行性评估 | R：设计文档；A：设计评审 | C：设计问题解答 | I：设计说明 | I：发布范围 |
| 开发负责人 | C：工作量评估 | C：可实现性评审 | R：编码与自测；A：构建质量 | R：缺陷修复 | R：发布包准备 |
| 测试负责人 | C：可测试性评审 | C：测试方案输入 | I：提测计划 | R：测试执行；A：测试报告 | C：验收支持 |
| 发布负责人 | I：发布约束 | I：部署要求 | I：环境准备 | C：发布验证 | R：上线执行；A：发布完成确认 |
矩阵之外还有三条规则需要明确。第一，交付物编写人与审核人分离：需求文档由需求负责人编写，由项目经理或业务方代表审核；设计文档由设计负责人编写，由开发与测试负责人共同审核。第二，阶段评审采用“评审会加结论记录”的方式，参与角色至少包括本阶段交付物编写人、下游阶段负责人和项目经理，结论分为通过、有条件通过、不通过三种，有条件通过需列出整改项和复查时间。第三，变更请求由提出人登记，项目经理组织影响评估，需求变更由需求负责人与业务方共同批准，涉及设计或进度调整时需设计负责人和项目经理会签。
当团队使用 ONES 承载项目时，可以用项目计划按阶段分解工作项，为任务设置前后置依赖，用里程碑标记评审和签字节点；阶段交付物可放在 ONES Wiki 中并与对应任务关联，使文档版本与工作项状态对应。这样角色分工和签字记录就有了统一的承载位置，具体配置以团队实际使用的产品版本为准。
按阶段推进的操作步骤
阶段定义和角色确定后，项目按以下步骤顺序推进。每一步都写清输入、动作、输出和完成标志，便于项目经理逐项检查。
启动与阶段计划
输入是立项说明和初步范围。动作包括组建项目组、确认各阶段负责人、编制阶段计划并标注里程碑。输出是项目计划与角色清单。完成标志是计划经过项目组确认，各阶段负责人明确。
需求阶段
输入是业务诉求和立项材料。动作包括需求收集、需求分析、编写需求规格说明书、组织需求评审、修订后基线化。输出是需求基线文档和验收标准。完成标志是评审结论为通过，业务方与需求负责人完成签字，基线版本归档。
设计阶段
输入是基线化需求。动作包括概要设计与详细设计、接口和数据设计、设计评审。输出是设计说明书和接口文档。完成标志是设计评审通过，开发负责人确认可实现，测试负责人确认可测试。
设计与开发的交接
交接不是把文档发过去就结束。建议安排一次交接会，由设计负责人讲解关键设计决策和约束，开发负责人确认理解并列出待澄清问题，问题闭环后开发阶段才正式启动。交接记录作为阶段评审的附件保存。
开发阶段
输入是设计文档和开发计划。动作包括编码、单元测试、代码评审和自测。输出是可运行的构建版本和自测记录。完成标志是构建通过、单元测试达到约定标准、代码评审完成。
测试阶段
进入测试需要满足条件：构建版本可部署、需求与设计文档齐备、测试用例已评审。动作包括系统测试、缺陷登记与修复、回归测试。输出是测试报告和缺陷清单。完成标志是测试用例执行完成、遗留缺陷达到约定标准、测试负责人签字。缺陷处理按严重程度分级，阻断级缺陷必须修复后才能进入发布评审。
发布阶段
输入是测试通过的版本和发布方案。动作包括验收测试、发布评审、上线执行和归档。输出是验收记录、发布说明和归档包。完成标志是验收通过、发布评审结论为通过、代码与文档完成归档。
评审不通过时的回退
阶段评审不通过时，项目经理组织整改，明确整改项、责任人和复查时间。整改完成后重新评审，评审记录保留两次结论。若问题涉及上游阶段交付物，按下一节的回退机制处理，不在本阶段内部消化。
示例：一个研发项目的瀑布推进过程
以下为一个演示情景，用于说明阶段推进的实际发生方式，不代表特定行业或团队的真实项目。
某研发团队承接一个内部业务系统的版本升级，计划周期十六周。阶段安排为：需求四周、设计三周、开发五周、测试三周、发布一周，各阶段之间预留评审缓冲。
需求阶段第一周完成业务访谈，第二周产出需求规格说明书初稿，第三周组织评审，业务方提出两项验收标准需要补充，评审结论为有条件通过。第四周完成修订并基线化，业务方与需求负责人签字，基线版本归档。
设计阶段产出概要设计和接口文档，评审时测试负责人指出两处验收标准缺少对应的可测试描述，设计负责人补充后复审通过。设计与开发交接会上，开发负责人提出三个待澄清问题，两天内闭环，开发阶段启动。
开发阶段按计划完成编码和自测，提测前项目经理检查提测条件：构建可部署、自测记录完整、测试用例已评审，确认后进入测试。测试阶段发现一个阻断级缺陷和若干一般缺陷，阻断级缺陷修复并回归通过后，测试负责人签字，进入发布评审。
发布评审中，发布负责人确认上线方案和回滚方案，项目经理确认验收记录齐备，评审通过后上线。上线后一周完成文档归档。这个示例中出现的两次“有条件通过”和一次提测条件检查，正是瀑布落地中最容易被省略、也最需要保留的环节。
变更与阶段回退怎么管
瀑布落地最容易失控的环节是需求变更和阶段回退。处理原则是：变更必须登记和评估，回退必须重新评审，两者都要与基线版本对应。
变更请求的流程分四步。第一步登记：提出人填写变更内容、原因和期望时间，项目经理统一编号。第二步影响评估：由需求负责人评估需求影响，设计、开发、测试负责人分别评估本阶段工作量与交付物影响，项目经理汇总进度和资源影响。第三步审批：根据影响范围确定审批层级，影响验收标准或发布范围的变更由业务方与项目经理共同批准，仅影响实现细节的变更由技术负责人批准。第四步执行与记录：批准后更新需求基线，同步修改受影响的已完成阶段交付物，并在变更记录中注明对应的基线版本号。
变更对已完成阶段交付物的影响需要专门处理。例如需求基线变更后，已通过评审的设计文档需要标注受影响章节并重新评审相关部分，不能只改需求文档而让设计文档停留在旧版本。建议在变更记录中列出受影响的交付物清单，逐项确认更新状态。
阶段回退的触发条件通常有三类：下游阶段发现上游交付物存在实质性错误、评审结论为不通过且无法在本阶段整改、变更导致上游交付物需要重做。回退时由项目经理发起，明确回退到哪个阶段、需要重新评审的范围，回退完成后重新组织该阶段评审，评审通过才能再次进入下游。回退记录与变更记录相互关联，形成完整的版本演进链条。
在 ONES 中，变更请求可以作为独立工作项登记并关联原需求，阶段交付物在 Wiki 中保留版本记录，评审结论和签字信息随任务状态留存，便于回溯某次变更影响了哪些交付物。团队应把变更登记和回退评审作为固定动作执行，工具只是承载这些动作的载体。
落地完成检查
以下清单用于判断瀑布落地是否达到可运行状态，建议由项目经理组织逐项核对，每项给出“已具备、部分具备、未具备”的结论。
- 阶段划分与准出标准已书面化，每个阶段都有可核验的完成条件，团队成员能说清自己所在阶段的准出要求。
- 各阶段交付物齐备，文档、记录与工作项能够相互追溯，任一交付物可以找到对应的评审记录和版本。
- 角色职责明确到人，每个阶段的签字人有名有姓，交付物编写人与审核人分离。
- 变更与回退机制至少完整运行过一次，包括登记、评估、审批、基线更新和回退重评审，记录可查。
- 阶段评审记录完整，包含参与角色、评审结论、整改项和复查结果，结论类型使用统一口径。
- 项目计划中的里程碑与阶段评审节点对应，进度偏差能够定位到具体阶段而非笼统的“项目延期”。
清单中若有超过两项为“未具备”，说明落地仍停留在文档层面，应先补齐阶段定义和角色分工，再推进实际项目。研发团队在需求变化频繁的部分引入迭代时，保持瀑布主干阶段的评审和基线机制不变，混合模式同样适用这份检查清单。
常见问题
瀑布模型要求上一阶段完全冻结才能进入下一阶段吗？
不必做到完全冻结。瀑布的核心特征是顺序推进和阶段评审，上一阶段通过评审、交付物基线化之后即可进入下一阶段，后续变更通过变更控制流程处理。团队可以在阶段内保留小幅修订空间，但涉及验收标准或发布范围的调整应走正式变更审批，并同步更新受影响的已完成阶段交付物。
需求变化频繁的研发团队还适合用瀑布模型吗？
可以以瀑布为主干、在局部引入迭代。做法是保留需求基线、阶段评审和发布验收这些主干机制，把需求变化频繁的模块拆成短周期迭代，在迭代内完成设计、开发和测试，再汇入整体发布评审。这样既保留顺序交付的可追溯性，也减少变更对已完成阶段的反复冲击。是否采用混合模式，取决于需求波动程度和交付约束，团队可按项目分别判断。
阶段评审不通过时，项目应该退回上一阶段还是在本阶段整改？
先判断问题来源。如果问题出在本阶段交付物本身，例如文档缺项、测试未执行完，由项目经理组织在本阶段整改，明确整改项、责任人和复查时间，整改后重新评审。如果问题源于上游交付物的实质性错误，或者变更导致上游需要重做，则触发阶段回退，回到对应阶段重新评审，通过后再进入下游。两次评审结论都要保留记录。
小团队落地瀑布，角色可以一人兼任吗？
可以兼任，但要保留职责分离的关键点。小团队中项目经理可能同时承担需求负责人或发布负责人的工作，此时应确保交付物的编写人与审核人不为同一人，例如需求文档由一人编写、另一人或业务方代表审核。签字确认的意义在于留下明确的责任记录，兼任不改变这一点。团队规模扩大后，再逐步把角色拆开。
变更记录和基线版本怎么对应，才能事后查得清？
建议每次变更批准后做三件事：更新需求或其他受影响交付物的基线版本号，在变更记录中写明本次变更对应的新基线版本，列出受影响的已完成阶段交付物清单并逐项确认更新状态。这样回溯时可以从任一交付物版本找到对应变更，也能从变更记录查到它改动了哪些文档和评审结论。
