## 一、典型的软件开发流程（中国境内常见实践）

在中国，软件开发流程通常是**“类瀑布 + 敏捷迭代”的混合模式**，尤其在互联网公司最为常见。

整体流程可抽象为 8 个阶段：

```
立项 → 需求分析 → 产品设计 → 技术设计 → 开发 → 测试 → 上线 → 运维/迭代
```

下面逐阶段展开。

---

## 二、各阶段说明 + 核心文档

### 1️⃣ 立项阶段（项目启动）

**目标**：决定“做不做、为什么做、值不值得做”。

**参与角色**

* 业务负责人 / 产品负责人
* 技术负责人
* 管理层（评审）

**常见文档**

| 文档    | 说明             |
| ----- | -------------- |
| 项目立项书 | 项目背景、目标、范围、ROI |
| 可行性分析 | 技术、成本、周期、风险    |
| 项目章程  | 角色分工、里程碑       |

👉 政企项目中尤为正式，互联网内部项目可能简化。

---

### 2️⃣ 需求分析阶段（需求澄清）

**目标**：搞清楚“用户要什么、业务怎么跑”。

**核心角色**

* 产品经理（主导）
* 业务方
* 技术、测试参与评审

**关键文档**

* **PRD（重点，见下文详解）**
* 需求评审纪要
* 原型图（Axure / 墨刀 / Figma）

---

### 3️⃣ 产品设计阶段（方案细化）

**目标**：把“需求”变成“可交付的产品形态”。

**文档**

| 文档     | 内容        |
| ------ | --------- |
| 交互原型   | 页面跳转、流程   |
| UI 设计稿 | 视觉规范      |
| 业务流程图  | 状态流转、业务规则 |

> 在很多公司，**产品设计与需求分析阶段是合并的**。

---

### 4️⃣ 技术设计阶段（系统设计）

**目标**：回答“技术上怎么实现”。

**核心角色**

* 技术负责人 / 架构师
* 后端 / 前端 / 客户端

**关键文档**

| 文档                | 说明              |
| ----------------- | --------------- |
| **DDS（重点，见下文详解）** | 详细设计说明          |
| 架构设计说明            | 系统拆分、技术选型       |
| 接口文档              | API 定义（Swagger） |
| 数据库设计             | 表结构、索引          |

---

### 5️⃣ 开发阶段（编码实现）

**目标**：把设计变成代码。

**常见产物**

* 代码仓库（Git）
* Code Review 记录
* 开发自测说明

**中国公司特点**

* 强调 **PR / MR 审核**
* 常配合 Jira / TAPD / 禅道

---

### 6️⃣ 测试阶段

**目标**：验证功能、稳定性、安全性。

**文档**

| 文档   | 说明           |
| ---- | ------------ |
| 测试计划 | 测什么、怎么测      |
| 测试用例 | 功能 / 异常 / 边界 |
| 缺陷单  | Bug 记录       |

---

### 7️⃣ 上线发布阶段

**目标**：安全、可控地交付生产环境。

**文档**

* 上线方案
* 回滚方案
* 变更单（政企尤其严格）

---

### 8️⃣ 运维与迭代阶段

**目标**：稳定运行 + 持续优化。

**文档**

* 运维手册
* 监控指标说明
* 复盘文档

---

## 三、重点详解：PRD 是什么？

### 1️⃣ PRD 全称与含义

> **PRD = Product Requirements Document**
> 中文常称：**产品需求文档**

---

### 2️⃣ PRD 是“做什么”，不是“怎么做”

**PRD 解决的问题：**

* 用户是谁？
* 解决什么问题？
* 产品功能是什么？
* 业务规则是什么？
* 成功标准是什么？

**PRD 不关心：**

* 用什么语言
* 表怎么建
* 接口怎么拆

---

### 3️⃣ PRD 的典型结构（中国公司常见）

```text
1. 背景与目标
2. 用户画像
3. 使用场景
4. 功能需求列表
5. 业务规则
6. 非功能需求（性能、权限）
7. 异常与边界
8. 数据埋点（互联网常见）
```

---

### 4️⃣ PRD 的作者 & 读者

| 角色   | 是否主要使用 |
| ---- | ------ |
| 产品经理 | ✅ 编写   |
| 技术   | ✅ 理解需求 |
| 测试   | ✅ 编写用例 |
| 业务   | ✅ 验收   |

---

### 5️⃣ 中国语境下的特点

* PRD **非常详细**
* 常被当作“需求合同”
* 政企项目中甚至作为验收依据

---

## 四、重点详解：DDS 是什么？

### 1️⃣ DDS 全称与含义

> **DDS = Detailed Design Specification**
> 中文常称：**详细设计说明书**

⚠️ 注意：
不要和“数据分发服务（Data Distribution Service）”混淆。

---

### 2️⃣ DDS 是“怎么做”，不是“做什么”

**DDS 解决的问题：**

* 系统架构怎么拆？
* 模块职责是什么？
* 接口参数、返回值？
* 数据表怎么设计？
* 关键算法逻辑？

---

### 3️⃣ DDS 的典型结构

```text
1. 总体技术架构
2. 模块划分说明
3. 核心流程时序图
4. 接口设计（API）
5. 数据库设计（ER 图）
6. 异常与容错设计
7. 性能与并发考虑
```

---

### 4️⃣ DDS 的作者 & 读者

| 角色    | 是否主要使用   |
| ----- | -------- |
| 技术负责人 | ✅ 主导     |
| 开发工程师 | ✅ 实现依据   |
| 测试    | ◯ 理解技术边界 |
| 产品    | ◯ 辅助理解   |

---

### 5️⃣ 中国公司 DDS 的现实情况

| 公司类型      | DDS 情况  |
| --------- | ------- |
| 政企 / 传统软件 | 必须，极其正式 |
| 大厂        | 视项目而定   |
| 创业公司      | 常弱化或口头  |

---

## 五、PRD 与 DDS 的对比总结（重点）

| 维度   | PRD                           | DDS                           |
| ---- | ----------------------------- | ----------------------------- |
| 全称   | Product Requirements Document | Detailed Design Specification |
| 关注点  | 业务 & 产品                       | 技术 & 实现                       |
| 回答问题 | 做什么                           | 怎么做                           |
| 作者   | 产品经理                          | 技术负责人                         |
| 面向对象 | 产品 / 技术 / 测试                  | 开发 / 架构                       |
| 是否必须 | 几乎必须                          | 视项目规模                         |
| 中国特点 | 偏详细                           | 偏重形式化                         |

---

## 六、一句话总结（非常重要）

> **PRD 是业务视角的“需求合同”，DDS 是技术视角的“实现蓝图”。**