项目开发全流程手册：8 个节点，每个节点的产出物与避坑清单

这份手册想解决什么问题

很多团队的项目流程是”口口相传”的：老人知道这一步该产出什么、该拉谁评审、该卡什么门禁，新人只能靠犯错来学。等到项目出问题复盘，才发现根因往往不是技术，而是某个流程节点该有的产出没有、该拉的人没拉、该定的边界没定。

这篇文章把一个完整的软件项目拆成 8 个主节点 + 1 条贯穿全程的管理线，每个节点都回答四个问题：

• 谁负责（Owner）、要拉谁（参与方）
• 输入是什么、产出物是什么
• 准出标准（做到什么程度才算这一步完成）
• 最容易踩的坑

目标是让项目经理和产品经理能”拿来即用”——照着清单走，不遗漏关键动作。文档层面的细节（PRD 与 SRS 的边界、概要设计和详细设计怎么分、时序图放哪）在另一篇《Spring Boot 项目全流程文档体系梳理》里有专门讨论，本文聚焦流程和产出，两篇可以配合看。

全流程概览

flowchart LR
    M["管理线：计划、变更、风险、沟通"] -.贯穿全程.-> S
    S[1 立项] --> R[2 需求]
    R --> D[3 设计]
    D --> C[4 开发]
    C --> T[5 测试]
    T --> A[6 验收]
    A --> L[7 上线]
    L --> O[8 运维迭代]
    O -.迭代回流.-> R

    style M fill:#f9f0ff,stroke:#9254de
    style R fill:#e6f7ff,stroke:#1890ff
    style D fill:#fff7e6,stroke:#fa8c16
    style L fill:#fff1f0,stroke:#f5222d

先记住一个原则：每个节点之间都有一道”门”（Gate）。门的作用是——上一步的产出没达标，就不允许进入下一步。省掉门禁，问题会一路滚雪球到上线前才爆发，那时候修复成本是需求阶段的几十倍。

---

节点 0（贯穿全程）：项目管理线

这不是一个独立阶段，而是从立项到运维一直存在的四条线。项目经理的主要战场就在这里。

管理线	核心产出物	关键动作
计划与进度	项目计划书、里程碑、甘特图、周报	拆解 WBS、定里程碑、每周同步进度与风险（展开见《项目计划与进度管理》）
变更管理	需求变更单、变更评审记录	任何范围/工期/成本变动，走变更单，留签字
风险管理	风险清单（Risk Register）	定期识别风险，标注概率×影响，指定责任人
沟通管理	会议纪要、干系人清单、决策记录	固定会议节奏，重要决策书面留痕

注意点

• 变更单是责任凭证，不是形式主义。 客户临时加需求、改口径，一律走书面变更并确认工期影响。90% 的”扯皮”都发生在没有变更记录的口头承诺上。
• 风险要写”应对措施”和”触发条件”，而不只是列出来。 “核心开发可能离职”不是风险管理，”若核心开发离职，由 X 接手，关键模块已有设计文档兜底”才是。
• 决策要留痕。 谁在什么时间基于什么信息做了什么决定，三个月后没人记得，书面记录是唯一的锚。

---

节点 1：立项 / 启动

目标：确认”这个项目值不值得做、做成什么样、投多少资源”，拿到正式授权。

项	内容
Owner	项目经理 / 产品负责人
参与方	业务方、投资/决策方、技术负责人
输入	商业机会、客户诉求、市场信息
产出物	项目立项书、项目计划书（初版）、干系人清单
准出标准	目标、范围、预算、周期、关键干系人明确，决策方批准

关键活动

1. 明确项目目标与范围边界（尤其是”不做什么”）。
2. 识别关键干系人，明确谁有决策权、谁需要被知会。
3. 初步估算资源、周期、预算，定里程碑。
4. 立项评审，拿到正式授权（Kick-off）。

最容易踩的坑

• 范围不写”不做什么”。 只写要做什么，边界永远是模糊的，后期所有争议都源于此。立项书里明确”本期不包含 XX”，价值极高。
• 把”目标”写成”功能列表”。 目标是”把订单处理时效从 2 天压到 2 小时”，不是”做一个订单系统”。没有可衡量的目标，验收时无据可依。
• 决策方没真正签字。 口头”你们先做着”不算立项。没有正式授权的项目，中途最容易被砍。

---

节点 2：需求

目标：把模糊的业务诉求，变成开发和测试都能理解、能落地的精确需求。

项	内容
Owner	产品经理
参与方	业务方、开发、测试、UI
输入	立项书、业务调研
产出物	调研报告、PRD（含业务流程图、原型）、需求规格说明书 SRS、需求评审纪要
准出标准	需求经过评审、无重大歧义，开发和测试确认可实现、可验证

关键活动

1. 业务调研，画现状业务流程图，识别真实痛点。
2. 写 PRD：讲清”为什么做、给谁用、怎么用”，画未来业务流程图，配原型。
3. 写 SRS：把每条业务规则细化成精确、可编码、可测试的条目（有效期、频控、边界、性能指标）。
4. 组织需求评审，开发/测试逐条确认。

最容易踩的坑

• PRD 和 SRS 混为一谈。 PRD 面向业务方讲价值，SRS 面向开发测试讲规则。前者”验证码登录提升体验”，后者”验证码 5 分钟有效、60 秒限发 1 次、错误 5 次锁 15 分钟”。缺了 SRS，边界条件会在测试和上线阶段以 Bug 的形式补交学费。
• 需求评审只有产品自己讲，开发测试不表态。 评审的价值在于让下游确认”能做、能测”。开发点头、测试点头，需求才算冻结。
• 没有需求基线（Baseline）。 评审通过的那一版要冻结存档，此后所有改动走变更单。否则”需求一直在变”就成了无底洞。
• 非功能性需求缺失。 性能、并发、安全、兼容性这些在 PRD 里往往一笔带过，必须在 SRS 里写成明确指标，否则验收时”响应快不快”永远是主观争论。

---

节点 3：设计

目标：确定系统”怎么搭、怎么拆、每块怎么实现”，让开发照着写就行。

项	内容
Owner	架构师 / 技术负责人
参与方	开发、DBA、安全、运维
输入	PRD、SRS
产出物	概要设计（架构图、技术选型、模块划分、部署拓扑、粗粒度时序图）、详细设计（ER 图+DDL、接口设计、细粒度时序图、安全方案）
准出标准	设计经评审，技术方案可行、无重大架构风险，开发可依此编码

关键活动

1. 概要设计：定架构风格、技术选型、模块边界、部署拓扑。
2. 详细设计：定数据库表结构、接口契约（入参/出参/错误码）、关键交互流程、安全实现。
3. 设计评审，重点看架构风险、扩展性、安全性。

最容易踩的坑

• 概要和详细的边界不清。 一句话记住：概要回答”分几块、怎么连”，详细回答”每块里面具体怎么写”。 架构图、部署拓扑属概要；表结构、接口字段属详细。
• 接口契约不先定。 前后端、服务间的接口契约必须在开发前冻结，否则联调阶段互相等、互相改，工期直接失控。
• 数据库设计不评审就开建。 表结构一旦有数据就极难改。字段、索引、分库分表策略要在这一步定死。
• 跳过设计直接写代码。 中小需求可以合并概要和详细成一份轻量文档，但”完全不设计”意味着架构决策散落在每个人的脑子里，无法交接、无法把关。

---

节点 4：开发

目标：按设计把功能实现出来，并保证基本质量。

项	内容
Owner	开发负责人
参与方	开发、测试（提前介入）
输入	详细设计、接口契约
产出物	源代码、接口文档（如 Swagger）、单元测试、Code Review 记录、编码规范
准出标准	功能自测通过、单测覆盖核心逻辑、Code Review 通过、提测

关键活动

1. 按模块/接口拆任务，纳入迭代计划。
2. 编码 + 单元测试 + 自测。
3. Code Review，遵循统一编码规范。
4. 提测前做冒烟自测，避免把明显问题丢给测试。

最容易踩的坑

• 提测质量太差。 开发把没自测过的东西丢给测试，Bug 反复打回，测试沦为”帮开发调试”。提测前必须冒烟自测通过，这是准出门禁。
• Code Review 走形式。 “LGTM”点一下不叫 Review。Review 要看逻辑正确性、边界处理、安全隐患，留下有价值的记录。
• 接口文档和代码不同步。 手写文档必然过期，尽量用 Swagger/OpenAPI 从代码生成，保证前端拿到的永远是最新契约。
• 进度只报”完成度百分比”。 “开发完成 80%” 是最没有信息量的汇报——剩下的 20% 往往花掉 80% 的时间。用”哪些功能已可提测”来衡量更真实。

---

节点 5：测试

目标：系统性验证系统是否满足需求，把缺陷挡在上线之前。

项	内容
Owner	测试负责人
参与方	开发、产品
输入	SRS、需求、提测版本
产出物	测试计划、测试用例、Bug 列表、测试报告、性能测试报告
准出标准	用例执行完毕、无遗留严重 Bug、核心指标达标、测试报告签署

关键活动

1. 依据 SRS 编写测试用例（功能、边界、异常、性能）。
2. 执行测试，记录 Bug，跟踪修复与回归。
3. 出具测试报告，明确遗留问题与风险。

最容易踩的坑

• 测试用例不覆盖异常和边界。 只测”正常流程”（Happy Path）等于没测。SRS 里每条规则、每个边界值都应该对应用例。
• 没有明确的上线质量门禁。 必须提前约定”什么级别的 Bug 允许带上线、什么级别必须清零”，否则上线前一定为此扯皮。
• 性能测试留到最后。 性能问题往往需要改架构，等功能全做完再压测，发现瓶颈时已经来不及。有性能指标的项目，压测要尽早。
• 测试环境和生产差异大。 数据量、配置、依赖版本不一致，测试通过不代表生产没问题。尽量让测试环境贴近生产。

---

节点 6：验收

目标：让业务方/客户确认交付物符合约定，明确责任边界。

项	内容
Owner	产品经理 / 项目经理
参与方	客户 / 业务方、测试
输入	测试通过的版本、需求基线
产出物	UAT 验收记录、客户签收单
准出标准	客户按验收标准确认通过，签署签收单

关键活动

1. 组织 UAT（用户验收测试），让真实用户按真实场景走一遍。
2. 收集验收意见，区分”缺陷”与”新需求”（后者走变更）。
3. 客户签署签收单。

最容易踩的坑

• 验收标准没提前约定。 验收当天才谈”什么算通过”，必然扯皮。验收标准应该在需求阶段就写进 SRS/合同。
• 把验收期的新需求当缺陷免费做。 UAT 中客户提的”顺便加一下”往往是新需求，要明确区分并走变更，否则项目永远收不了尾。
• 签收单不签。 没有客户签字，项目在法律和结算意义上就没”完成”，后续维护责任、付款节点全都悬空。这一项无论项目大小都不要省。

---

节点 7：上线 / 发布

目标：把系统安全、可控地部署到生产，且随时能回退。

项	内容
Owner	运维 / 发布负责人
参与方	开发、测试、DBA、业务方
输入	验收通过的版本
产出物	发布方案（含回滚预案）、上线检查清单、部署手册、发布记录
准出标准	灰度/全量发布成功、线上冒烟通过、监控正常、回滚方案就绪

关键活动

1. 制定发布方案，明确发布窗口、步骤、负责人、回滚触发条件。
2. 数据库变更/数据迁移预演。
3. 按检查清单发布，发布后线上冒烟验证。
4. 观察监控与关键指标一段时间后再宣布成功。

最容易踩的坑

• 没有回滚预案。 这是上线的头号红线。任何一次发布都必须能在约定时间内回退，包括数据库变更（不可逆的 DDL 要格外小心）。回滚方案没写清楚，不允许发布。
• 在业务高峰期发布。 选低峰窗口，留足观察和回退时间。
• 发布靠”某个人手工操作 + 记忆”。 上线步骤要写成检查清单并尽量脚本化/自动化，避免漏步骤、避免关键人不在就没人会发。
• 发完就散。 发布后要盯监控、盯日志、盯核心业务指标一段时间，确认稳定才算完成。

---

节点 8：运维 / 迭代

目标：保障系统稳定运行，并把运营中发现的问题转化为下一轮需求。

项	内容
Owner	运维 / 产品经理
参与方	开发、客服、业务方
输入	线上系统、用户反馈、监控数据
产出物	运维手册、故障记录（复盘）、监控告警配置、版本迭代记录
准出标准	监控告警到位、故障有响应机制、迭代闭环回到需求

关键活动

1. 配置监控告警，定义 SLA/值班机制。
2. 故障处理 + 复盘（根因、影响、改进项）。
3. 收集反馈，规划下一迭代，回流到需求节点。

最容易踩的坑

• 故障只”救火”不复盘。 修好就完，同样的问题会再犯。每次故障都要有复盘记录：根因是什么、影响多大、改进措施是什么、谁跟进。
• 监控告警缺失或”狼来了”。 没监控等于蒙眼开车；告警太吵（大量误报）等于没告警。告警要精准、可行动。
• 运维知识只在一个人脑子里。 运维手册要能让”没参与开发的人也能处理常见问题”，否则关键人休假就是事故。

---

附一：RACI 角色矩阵（速查）

R=负责执行，A=最终问责，C=需咨询，I=需知会。

节点	产品经理	项目经理	架构师	开发	测试	运维	客户/业务
立项	C	A/R	C	I	I	I	C
需求	A/R	C	C	C	C	I	C
设计	C	I	A/R	R	C	C	I
开发	I	C	C	A/R	C	I	I
测试	C	C	I	C	A/R	I	I
验收	A/R	R	I	I	C	I	C/签字
上线	I	C	C	R	C	A/R	I
运维迭代	R	I	C	C	I	A/R	C

团队小的时候一个人身兼数职很正常，但每个节点必须有唯一的 A（最终问责人）——责任不能”大家都负责”，那等于没人负责。

附二：会议节奏（推荐）

会议	时机	目的	产出
Kick-off	立项后	对齐目标、范围、分工	会议纪要、干系人清单
需求评审	需求冻结前	开发测试确认可实现可测	评审纪要、需求基线
设计评审	开发启动前	审架构风险与接口契约	评审纪要、冻结的接口
每日站会	开发/测试期每天	同步进度、暴露阻塞	阻塞清单
迭代评审/演示	每迭代末	向业务方演示成果	反馈清单
上线评审	发布前	确认回滚方案与检查清单	发布决定
故障复盘	故障后	找根因、定改进	复盘报告
项目复盘	收尾后	沉淀经验教训	复盘文档

附三：阶段门禁清单（准出检查）

进入下一节点前，逐项打勾：

• 立项 → 需求：目标可衡量、范围含”不做什么”、决策方已授权
• 需求 → 设计：PRD/SRS 通过评审、开发测试确认、需求已冻结成基线、非功能需求明确
• 设计 → 开发：接口契约冻结、数据库设计评审通过、无未决架构风险
• 开发 → 测试：功能自测/冒烟通过、单测覆盖核心逻辑、Code Review 通过
• 测试 → 验收：用例执行完毕、严重 Bug 清零、性能达标、报告签署
• 验收 → 上线：客户签收单已签、验收意见已闭环
• 上线 → 运维：回滚方案就绪、检查清单执行、线上冒烟通过、监控正常

写在最后

流程节点不是越多越好。中小项目完全可以合并——PRD 和 SRS 合成一份、概要和详细设计合成一份、验收简化。但下面这几项，无论项目大小都建议保留，因为它们要么是责任凭证、要么是止损底线：

• 需求变更单（争议时唯一的凭证）
• 需求基线 / 验收标准（避免无休止扯皮的锚点）
• 客户签收单（项目”完成”的法律与结算依据）
• 回滚预案（上线出事时唯一的退路）
• 故障复盘记录（让团队不在同一个坑里摔两次）

把这几样守住，其余节点按团队规模灵活裁剪，就是一套既规范又不臃肿的项目流程。

---

本文是”项目全流程”系列的一份可裁剪流程参考手册。具体文档如何组织、边界如何划分，见《Spring Boot 项目全流程文档体系梳理》；贯穿全程的计划与进度怎么落地，见《项目计划与进度管理》。欢迎交流指正。