项目全流程概述：从启动到运维的七阶段方法论

Sun, 15 Mar 2026 00:00:00 +0800

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

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

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

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

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

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

二、流程全景（7 阶段）

阶段	关键角色	核心产物	评审机制
0 启动	产品经理、研发项目经理、客户/上级	会议纪要、研发周报、需求调研、业务梳理	启动会评审
1 需求	产品经理、研发工程师	产品原型、业务流程图、里程碑、任务分解、概要需求	需求评审会
2 设计	UI 设计师、研发工程师	界面效果图、UI 规范、需求规格、概要设计、通讯协议、表结构	设计评审会
3 开发	研发工程师	源代码、技术预研报告、功能评审记录	功能评审
4 测试	测试工程师、研发工程师	测试实例、测试结果报告、操作手册、维护手册	测试报告评审
5 运维	运维工程师、研发工程师	上线方案、监控配置、应急预案	上线评审
6 日常	全员	周报、月报、培训记录	部门例会
7 管理	部门负责人	考核指标、绩效系数、年度总结	部门评审

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

三、阶段 0：项目启动

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

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

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

四、阶段 1：需求阶段

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

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

4.1 文档层次：BRD / MRD / PRD

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

文档	回答的问题	受众
BRD（Business Requirement Document）	商业论证：要不要做？	决策层
MRD（Market Requirements Document）	市场需求：如何做能赚钱？	产品/运营/市场/研发
PRD（Product Requirement Document）	产品需求：做成什么样？	研发/测试/交互

Why 三层：

外包项目：甲方出 BRD+MRD，乙方对接出 PRD / 需求分析报告 / 需求规格说明书

自研项目：业务部门出 BRD+MRD，产品经理出 PRD，项目经理出需求分析报告，研发经理出需求规格说明书

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

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

五、阶段 2：设计阶段

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

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

5.1 概要设计的两个误区

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

❌ 过于重视业务流程（应该画图、不该写流程）

❌ 过于重视细节实现（应该定接口、不该写算法）

5.2 概要设计的标准结构

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

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

六、阶段 3：开发阶段

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

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

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

七、阶段 4：测试阶段

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

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

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

八、阶段 5：系统上线

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

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

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

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

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

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

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

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

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

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

等级	描述	滞后天数
1	非常及时，随意可查阅	0 天
2	非常规范，较及时，可查阅近期文档	≤ 3 天
3	较规范，较及时，一般可查阅近期文档	3-6 天
4	较规范，不及时，常难查阅	≥ 6 天
5	不规范，不及时，常难查阅甚至无文档	—

9.2 绩效系数参考

绩效分	绩效系数	备注
≥ 100	1.3	超出预期
95 - 99	1.15	略超预期
85 - 94	1.0	达标

十、核心 5 点提炼

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

十一、常见 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 年再写一篇——“骨架不变，工具全换”：

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

需求分析 on Liangweidong's blog