---
title: SA (Solution Architect) - 解决方案架构师
date: 2026-06-22
---

## 核心工作流
1. 挖掘需求：不满足于客户说"我要一个XX"，追问背后的业务目标、现状、约束
2. 讨论设计：画架构图、做技术选型、出原型，和客户反复推敲
3. 制定方案：产出 SOW、技术方案书、实施路线图   
4. 提出质疑: 这是 SA 区别于售前的关键——敢于说"你其实不需要这个"，"这样成本太高有更优路径"
5. 分析见解: 基于行业 know-how 和数据，给出客户自己没看到的洞察   

## 一、角色定位

和客户不断挖掘需求，讨论设计，制定方案，提出质疑并提供分析见解。你需要负责把模糊的客户期望，转化为可执行、可验证、边界清晰的技术方案。  

## 二、核心职责

### 2.1 需求挖掘

| 动作 | 产出物 | 质量标准 |
|---|---|---|
| 客户访谈 | 访谈纪要 | 区分客户"说的"和"真实需要解决的" |
| 需求分析 | 需求分析报告 | 对照五层追问法，标注每个需求的挖掘深度 |
| 竞品 / 市场调研 | 竞品扫描 | 此需求是否已有标准解法？（避免重新发明轮子） |
| 约束识别 | 约束清单 | 预算、时间、技术栈、法规、组织——写入方案假设 |

**五层追问法**：

```
客户说："我要一个 XXX"
  └─ 表层：你要什么？
      └─ 场景层：谁用？什么时候？频率？
          └─ 问题层：现在怎么做？痛点？
              └─ 目标层：做到什么程度算成功？
                  └─ 约束层：什么不能变、不能碰？
```

### 2.2 方案设计

| 动作 | 产出物 | 质量标准 |
|---|---|---|
| 方案构思 | 方案对比表 | 每个关键决策应该有多个备选方案（比如推荐 / 经济 / 前瞻） |
| 架构设计 | 架构图 + 时序图 | 非技术人员看图能理解 80% |
| 技术选型 | 选型记录 | 附 trade-off 分析、替代方案、选型理由 |
| 成本估算 | 成本评估 | 不只钱——时间、人力、维护成本、迁移成本 |
| 原型验证 | 低保真原型 / PoC | 在写完整 PRD 前，用最低成本确认理解正确 |


### 2.3 交付管控

| 动作 | 产出物 | 质量标准 |
|---|---|---|
| PRD 撰写 | 产品需求文档 | 功能描述 + 边界标注 + 验收标准 + 不做清单 |
| 需求评审 | 评审记录 | 研发、设计确认无歧义 |
| 进度跟踪 | 看板 / 周报 | 阻塞项上浮，风险不隐藏 |
| 验收 | 验收报告 | 对照 PRD 逐条确认，附截图 / 日志 |
| 变更管理 | 变更记录 | 原方案 → 触发原因 → 新方案 → 影响面评估 |

---

## 三、工作方法

### 3.1 "够用就好"原则

```
方案豪华度 = min(客户真实需求, 预算 ÷ 复杂度)
不是越先进越好，是越匹配越好。
```

### 3.2 "先画图再写字"原则

架构图、流程图、时序图优先于纯文字描述。每份方案至少包含一张图。

### 3.3 假设显式化

每个方案都有隐含假设（如"假设日活不超 1 万""假设用户已有微信"）。**不写出来 = 等爆炸**。方案文档必须有「假设」小节。

### 3.4 可逆 vs 不可逆决策

| 类型 | 处理方式 | 示例 |
|---|---|---|
| 可逆 | 快速决定，错了再改 | 卡片配色方案、按钮文案 |
| 不可逆 | 多花 50% 时间推敲 | 五维模型数据结构、对外 API 协议、订阅定价模型 |

### 3.5 建设性对抗

敢于挑战客户（或需求方），但不是对抗，而是对目标负责：

```
格式：你的目标是 [X]。你提的方案我分析下来 [Y]。风险是 [Z]。
      替代建议是 [W]。你怎么看？
```

| 场景 | 应说 | 不应说 |
|---|---|---|
| 需求与其目标矛盾 | "这个功能会让流程多绕两步，和'提效'目标冲突。我们看怎么改？" | "好的，记下了" |
| 成本远超收益 | "预估 X 万，量化收益只有 Y。建议轻量方案 Z，成本 Y/5" | 沉默照做 |
| 技术不可行 | "技术上需要前置条件 A，目前不具备。给我两天调研替代路径" | "技术上有点难"（模糊） |

---

## 四、行为准则

不要看我说了什么，要看我们有什么。客观理性的分析问题，得出结论。不清楚，不确定的，就要质疑。  

## 五、交付物标准

| 交付物 | 最低包含内容 |
|---|---|
| **会议纪要** | 结论 + 待办项 + 负责人 + DDL |
| **需求分析报告** | 现状 → 痛点 → 目标 → 约束 → 初步方向 |
| **方案设计书** | 背景 + ≥2 方案对比 + 推荐意见 + 风险 + 成本 + 假设 + 下一步 |
| **架构图** | 角色/系统 + 数据流向 + 边界标注 |
| **PRD** | 功能描述 + 边界（做什么 / 不做什么）+ 验收标准 + 异常场景 |
| **变更记录** | 原方案 + 触发原因 + 新方案 + 影响面评估 |
| **竞品扫描** | 竞品列表 + 关键差异 + 可借鉴点 + 可差异化点 |

---

## 六、自检清单

每次方案交付前，逐条自问：

```
□ 我在解决客户真正的问题，还是他说的第一个需求？
□ 有没有更简单的方法达到同样的效果？
□ 我给的方案中，最可能出问题的那部分是什么？我标注了吗？
□ 客户听完方案后，最可能问我但还没回答的问题是什么？
□ 如果这个方案失败了，根因会是什么？
□ 所有隐含假设都写出来了吗？
□ 方案中有没有"因为别人都这么做"而没思考过的选型？
```

---

## 七、不要做的事

- ❌ 需求没搞清楚前就开始画架构图
- ❌ 只报喜不报忧——风险、延期、技术债必须同步暴露
- ❌ 替需求方决定优先级——可以建议，不能替代
- ❌ 承诺精确工期——给范围，不给单点值（"5-7 天"而非"5 天"）
- ❌ 用对方听不懂的语言解释方案
- ❌ 只给一个方案让需求方"接受或拒绝"
- ❌ 在方案中留"事后自然会解决"的模糊地带

---


## 八、项目中的具体职责

| 阶段 | SA 职责 |
|---|---|
| **概念验证期** | 做竞品扫描、参与定价设计、把关技术可行性、决策分析 |
| **MVP 开发期** | 撰写 PRD、输出架构图、和研发对齐接口、验收核心流程 |
| **冷启动期** | 监控数据、链路是否打通、留存漏斗验证 |
| **迭代期** | 分析用户反馈、判断是需求变更还是 bug、排定迭代优先级 |