背景：这是一份 2008 年整理的"瀑布式软件项目"全流程方法论。本文写于 2026 年 3 月——站在 18 年后再回看，它定义了中文 IT 行业最经典的角色分工、阶段物、评审机制。大多数中型项目的"项目管理"模板，至今仍是这套骨架。

一、为什么 2026 年还要读瀑布流

也许你会问：都 2026 年了（距离 2008 年这份方法论已经 18 年），谁还用瀑布流？

事实上，瀑布流仍然是强约束、弱变更、合规优先项目的首选——政府/国企/医疗/工业软件。这些项目里：

• 需求一次性评审拍板，改一次合同 = 改一次报价
• 阶段物是审计/验收的依据（BRD、MRD、PRD、需求规格、概要设计……少一份不签字）
• 角色边界清晰：产品经理、研发项目经理、研发工程师、测试工程师，谁负责什么、产物是什么、有没有评审，全部白纸黑字

When to use：当你的项目周期 ≥ 3 个月、参与方 ≥ 3 个（含客户/监理/外部审计）、变更成本极高时，这套流程就是底座。敏捷会在它的某些阶段上叠加，但不会取代。

二、流程全景（7 阶段）

Tip：从"启动 → 日常/管理"是横向的 7 个阶段，每个阶段都有输入 / 处理 / 输出 / 评审四件套。少一个，流程就不闭环。

三、阶段 0：项目启动

启动阶段是"把人和事定下来“的阶段。关键动作：

1. 确定项目方向——产品经理和项目干系人对齐。干系人包括：
   • 产品型项目：公司领导、产品总监、技术总监
   • 客户型项目：客户方领导、主要执行人
2. 组建项目组——研发项目经理、研发工程师、测试团队
3. 建立项目管理制度：
   • 每阶段评审必须有《会议纪要》
   • 启动起研发项目经理每周提供《项目研发周报》
   • 测试阶段测试工程师每周提供《项目测试周报》
4. 需求调研——产品经理输出《需求调研》文档，方法主要是背景资料调查 + 访谈
5. 业务梳理——四步法：
   • 明确项目目标
   • 梳理项目涉及的角色
   • 每个角色要做的事项
   • 划分端口、模块、功能

常见坑：启动会只发个通知就开始写代码，没产出物。结果需求阶段返工、设计阶段推翻，项目结束时成本是预算的 1.5-2 倍。

四、阶段 1：需求阶段

需求阶段是”把业务画出来“的阶段。关键动作：

1. 产品原型——产品经理提供最简单也最接近成品的原型，线框图形式。还会产出：
   • 业务流程图：不同节点不同角色的操作
   • 页面跳转流程图：界面之间的跳转关系
2. 需求讲解——产品经理面向整个团队宣讲
3. 项目里程碑——研发项目经理根据需求明确《项目里程碑》
4. 产品开发计划——明确详细阶段时间点
5. 项目任务分解——把工作包拆到人/天
6. 概要需求——研发工程师按分工初步理解业务，评估技术可行性

4.1 文档层次：BRD / MRD / PRD

在更大的组织里，需求阶段会按三个层次产出文档：

Why 三层：

• 外包项目：甲方出 BRD+MRD，乙方对接出 PRD / 需求分析报告 / 需求规格说明书
• 自研项目：业务部门出 BRD+MRD，产品经理出 PRD，项目经理出需求分析报告，研发经理出需求规格说明书

BRD 的 5 大块：研发背景、可行性分析、产品规划、商业模式、投资与收益、风险及对策。

PRD 的核心：产品概述、产品框架、数据需求、功能性需求、非功能性需求、系统上线需求。

五、阶段 2：设计阶段

设计阶段是”把业务变成可实现的图纸"。关键动作：

1. 界面效果图 + UI 设计规范——UI 设计师输出，标注每个控件尺寸；规范统一字号、间距、按钮尺寸
2. 需求规格——研发工程师基于界面效果图输出，包含最终要实现的一切要素
3. 概要设计——模块划分、接口定义、数据结构
4. 通讯协议——前后端、客户端与服务端的接口约定
5. 表结构设计——数据库 schema

5.1 概要设计的两个误区

Tip：概要设计阶段最常踩的两个坑：

• ❌ 过于重视业务流程（应该画图、不该写流程）
• ❌ 过于重视细节实现（应该定接口、不该写算法）

5.2 概要设计的标准结构

一份合格的概要设计应当覆盖以下内容（顺序自上而下）：

1. 原则——评价总体设计的可行性、检查模块是否完整、评估开发工作量
2. 总述——需求或目标、环境、局限
3. 总体设计——组织结构、功能、处理流程、模块、模块间关系、运行环境（输出：系统结构图、系统流程图、数据流程图）
4. 外部接口——外部用户、软硬件接口
5. 模块设计——每个模块"做什么"、“怎么做”、逻辑位置、物理位置
6. 数据结构——逻辑结构、物理结构
7. 容灾设计——出错信息、出错处理
8. 监控设计——运行模块组合、控制、时间
9. 用户界面设计
10. 安全设计
11. 其它设计
12. 制定规范——设计原则、代码规范、接口规约、命名规则

六、阶段 3：开发阶段

编码阶段看似就是"写代码"，实际包含：

1. 技术预研——对关键技术点做 POC
2. 需求确认——编码中发现需求模糊点，反查需求
3. 联调——服务端、移动端、外部系统的联调
4. 功能评审——编码完成后团队过一遍

2026 年补充：18 年后回看，“技术预研"这一步在当下分布式 / 大模型 / 云原生环境下变得比 2008 年更重要——选错技术栈，不是返工 1 周的问题，是整条技术债要背 3-5 年。

七、阶段 4：测试阶段

测试是”证明系统符合规格“的阶段。关键动作：

1. 测试实例——按阶段设计，未通过的提交至 Jira 分配给开发
2. 修改回归——研发改完重新提交测试
3. 测试结果报告——功能测试结果、压力测试结果
4. 操作手册 / 维护手册——每个端口都要写

Tip：测试实例的设计要兼顾正常流程 + 异常流程 + 边界条件。只测正常流程，上线后必出生产事故。

八、阶段 5：系统上线

与客户/上级达成一致后，系统进行试运行，稳定后上线。

试运行期通常 2-4 周，验证：

• 数据迁移正确性
• 性能指标（响应时间、并发量、错误率）
• 业务流程跑通
• 备份/恢复演练

九、阶段 6 & 7：日常与管理

日常阶段是”项目结束后的运维期"，包括：

• 故障响应
• 用户反馈处理
• 小版本迭代
• 数据备份与恢复

管理阶段是"对人评价“的阶段，考核指标包括：

1. 工作态度
2. 软件质量（bug 等级/个数、回归次数、重要模块系数）
3. 工作难易度（功能性、可靠性、易用性、高效性、可维护性、可移植性、功能点数、复杂度）
4. 工作效率/能力（完成百分比、工作经验）
5. 主动性
6. 沟通能力
7. 程序规范程度

9.1 程序规范程度的 5 级评估

文档编写的及时性和可查阅性，按滞后天数分 5 级：

9.2 绩效系数参考

十、核心 5 点提炼

1. 阶段物是法律证据——所有评审、纪要、文档、报告都是项目结束时对账/审计/验收的依据。少一份都可能卡付款。
2. 角色边界必须清晰——产品/研发/测试/运维，谁负责什么产物，谁有最终签字权，提前在启动会定清楚。
3. 变更必须走流程——需求变更单、技术变更单、紧急变更单，没有单子不动代码。
4. 周报不是形式——研发周报和测试周报是项目经理对客户/上级同步进度的唯一窗口，写得烂就丢信任。
5. 手册要趁热写——操作手册和维护手册测试期间就要开始写，别拖到上线后。

十一、常见 5 个坑

1. 跳过需求评审——直接进开发，最后发现做出来不是客户要的东西
2. 概要设计变成详细设计——把实现细节写进概要设计，导致接口反复改
3. 测试实例覆盖不全——只测正常流程不测异常流程，上线后出生产事故
4. 没有维护手册——运维靠"老人记忆”，老人一走系统就瘫
5. 绩效考核靠感觉——没有数据化指标，年终评优变成"谁关系好"

十二、和敏捷的关系

瀑布流不等于落后，敏捷不等于先进。实际项目里：

• 底层用瀑布：合同/范围/阶段物/验收
• 上层用敏捷：需求池/Sprint/迭代评审/回顾会

混合模式：

• 0 启动 / 1 需求：瀑布（拍板）
• 2 设计 / 3 开发 / 4 测试：敏捷（迭代）
• 5 运维 / 6 日常 / 7 管理：瀑布（运维 + 考核）

十三、2026 年回望

18 年后再读这份方法论，有几个仍然成立的判断：

• 角色分工的边界——产品、研发、测试、运维的职责切分，至今没有过时；只是协作工具从邮件/共享文件夹换成了 Jira/Slack/飞书
• 阶段物的严肃性——BRD/MRD/PRD 在 2026 年的互联网大厂依然在用，只是"敏捷化"了产出节奏（每个 Sprint 出一份精简版）
• 周报的价值——周报是项目经理对干系人同步进度的最低成本手段，没有替代品

也有一两个明显过时的判断：

• Jira 作为测试 bug 流转工具——2026 年的中型团队更多用 GitHub Issues / Linear / 飞书项目
• 压力测试的边界——2008 年主要靠 LoadRunner，2026 年已经是 k6 / Locust / 云厂商 PTS 标准化
• 运维靠人值班——2026 年的中等规模系统早已 SRE 化、告警自愈、ChatOps 化

但底层的 7 阶段骨架、输入/处理/输出/评审四件套、阶段物即法律证据的判断——18 年后依然站得住。这也是为什么我把这套方法论重新整理出来：给在 2026 年进入 IT 行业的新人，一份"知道流程为何长这样"的参考。

参考资料

• 《项目全流程》方法论原始整理稿（2008）
• 《需求文档 / 需求分析报告 / 需求规格说明书》模板（2008）
• 《概要设计》标准结构（2008）
• 团队内部 7 阶段项目复盘记录

2024 视角（项目全流程：阶段不变，工具全换）

2026 年再写一篇——“骨架不变，工具全换”：

1. 0 启动——DOR（Definition of Ready） + DOD（Definition of Done） 取代模糊的"评审会"。启动产出物在 2024 年已经从"会议纪要 + 共享文档"升级为Jira Initiative → Epic → Story 三级结构 或 飞书项目 / Linear。
2. 1 需求——BRD/MRD/PRD 三件套在 2024 年互联网大厂仍有效，但文档形式从 Word 转向 Notion / 飞书 / Confluence，并要求每条需求带"用户故事 + 验收标准 + 度量指标"。LLM 工具（GitHub Copilot、Cursor、Trae）能自动从 PRD 草稿生成用户故事和边界用例。
3. 2 设计——C4 模型（Context / Container / Component / Code）+ ADR（Architecture Decision Records） 取代大段 Word 描述。一个 ADR = 一个决策 + 上下文 + 后果，git 一并管理。Mermaid / PlantUML 取代 Visio。
4. 3 开发——GitOps（Argo CD / Flux）+ Trunk-Based Development + Feature Flags（LaunchDarkly / Unleash）取代"长分支 + 合并冲突"。AI 代码评审（GitHub Copilot Review、Coderabbit）已成 PR 标配。
5. 4 测试——契约测试（Pact）+ E2E 自动化（Playwright）+ 性能测试左移（k6 / Grafana k6 Cloud）+ AI 生成测试用例（Diffblue、腾讯 IAST）取代纯人工测试。
6. 5 运维——SRE + GitOps 持续发布 + Observability 三大支柱（Prometheus + Loki + Tempo / OpenTelemetry）+ ChatOps（PagerDuty + Slack）取代人工值班。
7. 6 日常——数据驱动的运维（SLO/SLI 看板）+ SRE 错误预算 取代"故障后开复盘会"。
8. 7 管理——OKR + KPI 双轨——OKR 驱动方向、KPI 驱动执行。HR 系统 + Jira 数据 自动生成绩效，不再"凭感觉评优"。

额外 4 个 2024 视角：

• AI 工具是新一代"阶段物"：需求阶段用 LLM 拆解用户故事；设计阶段用 LLM 生成 ADR 草稿；开发阶段用 Copilot / Cursor；测试阶段用 AI 生成用例；运维阶段用 AIOps（异常检测 + 自愈）。
• 远程办公让"会议"不再是默认协作方式——异步优先（Async-First）+ 文档驱动（Doc-Driven）+ 决策记录（ADR）成为新基础。
• 数据合规：等保 2.0、GDPR、CCPA 让阶段物"合规性"要求大幅上升——日志、审计、用户授权必须全生命周期留痕。
• DevSecOps 嵌入：安全不再是"上线前扫描一下"，而是从需求阶段就介入（SAST/DAST/SCA/IaC 扫描全在 CI 中）。

结论：2008 年的"7 阶段骨架"在 2024 年仍可用，但每个阶段内的工具、产物格式、协作方式都经历了 2-3 次代际升级。新人最该学的不是"流程长啥样"，而是**“每个阶段的产物在 2024 年用什么工具、什么格式、谁在什么时候产出”**——这才是 IT 项目管理的"现代工程实践"。