技术方案怎么写才能让产品经理看懂
大约 12 分钟
技术方案怎么写才能让产品经理看懂
前言
你花了三天写了一份 20 页的技术方案，满怀信心地发给 PM，结果 PM 只回了一句：
"我看不太懂，你能用大白话讲一下吗？"
挫败感拉满。但冷静下来想想：PM 看不懂你的技术方案，真的只是 PM 的问题吗？
技术方案需要两个版本：一个给技术团队看的"完整版"，一个给 PM 和业务方看的"产品化版本"。本文教你如何写出让 PM 也能看懂、愿意看、看了有用的技术方案。
一、为什么 PM 看不懂你的技术方案
1.1 五个经典原因
PM 看不懂技术方案的五个原因：
1. 术语轰炸
"我们采用 CQRS 架构，写操作走 Command Bus，
读操作走 Query Bus，通过 Event Store 实现事件溯源。"
PM 内心：CQRS 是什么？Bus？公交车？
2. 过早陷入技术细节
开口就是"我们选了 Redis Cluster 7.0 作为缓存，
RDB 持久化策略，内存淘汰策略用 allkeys-lru..."
PM 内心：我只想知道这个功能能不能做，多久能做完。
3. 没有翻译"技术影响"为"业务影响"
"这个方案的延时是 P99 500ms"
PM 内心：500ms 是什么意思？快还是慢？对用户有什么影响？
4. 流程图太技术化
画的是"微服务之间 RPC 调用的链路"，而不是"用户操作流程"
5. 篇幅太长，抓不住重点
20 页方案，PM 需要的核心信息可能只有 3 句话
1.2 PM 真正关心什么
PM 看技术方案时，ta 想知道的是：
优先级 1（必须知道）：
✅ 这个需求能做吗？
✅ 什么时候能上线？
✅ 有没有风险可能导致延期？
优先级 2（最好知道）：
✅ 技术方案对用户体验有什么影响？
✅ 有没有 PM 需要做的决策？
✅ 分阶段上线的话，每个阶段能交付什么？
优先级 3（可以后续了解）：
○ 具体用了什么技术？
○ 数据库怎么设计的？
○ 架构是怎样的？有什么理由？
二、技术方案的产品化表达技巧
2.1 核心技术：翻译
技术语言 → 产品语言的翻译词典：
技术语言 产品语言
─────────────────────────────────────────────────
"数据库读写分离" "用户查询速度快 40%"
"引入消息队列异步处理" "用户点击后不用等，后台处理完了通知你"
"缓存预热" "第一次打开也不会慢"
"灰度发布" "先让小部分用户试用，没问题再全量"
"降级策略" "系统忙的时候，核心功能正常用，
非核心功能暂时停用"
"数据迁移" "把老数据搬到新系统里"
"幂等性" "重复操作不会产生重复结果"
"最终一致性" "数据会在几秒内同步完成"
"微服务" "把大系统拆成小模块，各自独立"
"熔断" "某个功能出问题了，自动关闭防止影响全局"
2.2 一句话原则
每个技术决策，都加上一句话的产品影响说明：
❌ "我们决定使用 MySQL 读写分离 + Redis 缓存"
✅ "我们决定使用 MySQL 读写分离 + Redis 缓存。
**对用户的影响**：列表页加载速度从 3 秒降到 0.5 秒。"
❌ "异常流程走消息队列重试，最多重试 3 次"
✅ "异常流程走消息队列重试，最多重试 3 次。
**对用户的影响**：网络波动导致的操作失败会自动重试 3 次，
用户只需等待几秒，不需要手动重新操作。"
❌ "使用 Elasticsearch 作为搜索引擎"
✅ "使用 Elasticsearch 作为搜索引擎。
**对用户的影响**：搜索结果从'只能精确匹配'变成
'支持模糊搜索、拼音搜索、同义词搜索'。"
2.3 分层表达
技术方案的结构：从"产品视图"到"技术视图"
第一层：产品视图（给 PM 和业务方看）
- 一句话总结：这个方案要做什么
- 用户体验变化：用户会感受到什么变化
- 时间线：什么时候能体验
- 风险：可能出现什么问题，影响什么
第二层：业务视图（给 Tech Lead / 架构师看）
- 技术选型理由
- 架构变化点
- 数据流变化
第三层：技术视图（给开发团队看）
- 详细接口设计
- 数据模型设计
- 实现方案细节
- 测试策略
三、架构图：画到什么粒度让 PM 看懂
3.1 给 PM 的架构图原则
给 PM 看的架构图 vs 给 RD 看的架构图：
PM 版本（业务架构图）：
- 去掉所有技术组件（Redis、MQ、Nacos）
- 用"业务模块"代替"微服务"
- 标注数据和操作的流向
- 用业务语言描述每一步
RD 版本（技术架构图）：
- 画出所有技术组件
- 标注协议和通信方式
- 标注数据存储方案
- 标注依赖关系
3.2 示例对比
技术版架构图（RD 看懂，PM 看不懂）：
┌──────┐ HTTP ┌─────────┐ RPC ┌────────┐
│ NGINX├────────┤Gateway ├───────┤Order │
└──────┘ └────┬─────┘ │Service │
│ └───┬────┘
┌────▼─────┐ │
│Nacos │ ┌─────▼────┐
│注册中心 │ │MySQL │
└──────────┘ │主从集群 │
└──────────┘
产品版架构图（PM 能看懂）：
用户操作流程：
用户打开 App
│
▼
下单页面
│ 用户点"提交订单"
▼
系统检查库存 ──── 有货 → 锁定库存 → 生成订单 → 显示"下单成功"
│ │
└──── 无货 → 显示"库存不足" │
│
用户收到推送通知： │
"您的订单已生成" ◄───────┘
3.3 用"场景流程"代替"技术流程"
技术流程（PM 看不懂）：
Client → BFF → OrderService.createOrder()
→ InventoryService.checkStock()
→ PaymentService.createPayment()
→ MQ.publish(OrderCreatedEvent)
→ NotificationService.sendPush()
产品流程（PM 能看懂）：
用户点击"下单" →
系统检查库存 →
├── 库存充足：进入支付页 →
│ 用户完成支付 →
│ 系统生成订单号 →
│ 用户收到推送"订单已生成" →
│ 商家后台显示新订单
└── 库存不足：提示"该商品已售罄"
四、用业务语言翻译技术概念
4.1 常见技术概念的业务翻译
性能相关：
"QPS 500" → "每秒能处理 500 个用户请求"
"P99 延迟 200ms" → "99% 的用户操作在 0.2 秒内得到响应"
"吞吐量 1000/s" → "每秒能处理 1000 笔订单"
可靠性相关：
"3 个 9 的可用性" → "一年内不可用时间不超过 8.8 小时"
"主从切换" → "一台服务器挂了，备用的自动顶上"
"异地多活" → "即使一个城市的数据中心出问题，服务也不受影响"
扩展性相关：
"水平扩展" → "用户量涨了，多加几台服务器就行"
"分库分表" → "数据量增长 10 倍，性能不降"
4.2 技术决策的业务影响
每个技术决策，都翻译成对 PM 有意义的语言：
技术决策：使用异步处理代替同步处理
技术语言：引入 RocketMQ，订单创建成功后发送消息，异步扣减库存
产品语言：
✅ 用户体验：用户提交订单后立刻显示"已提交"，不需要等待库存扣减完成
⚠️ 需要注意：极少数情况下，库存扣减失败时用户会收到"订单取消"通知
📊 数据：从点击提交到收到反馈，时间从 3 秒降到 0.3 秒
技术决策：引入缓存
技术语言：使用 Redis 缓存热门商品数据，TTL 10 分钟
产品语言：
✅ 用户体验：热门商品页面秒开（< 100ms）
⚠️ 需要注意：商品信息修改后，最多 10 分钟才会在页面上更新
📊 数据：列表页加载速度提升 10 倍
五、技术方案中的"业务影响分析"
5.1 业务影响分析模板
## 业务影响分析
### 用户体验变化
| 环节 | 改前 | 改后 | 变化 |
|------|------|------|------|
| 列表加载 | 3 秒 | 0.5 秒 | 提升 6 倍 |
| 提交订单 | 同步等待，5 秒 | 异步处理，立即反馈 | 感知延迟降低 |
| 搜索结果 | 仅精确匹配 | 支持模糊搜索 | 搜索成功率 +40% |
### 运营/业务影响
| 维度 | 影响 |
|------|------|
| 运营效率 | 导出时间从 30 分钟降到 1 分钟 |
| 数据准确率 | 从人工核算的 95% 提升到系统保障的 99.9% |
| 业务灵活性 | 新增报表维度从"需要开发排期"变成"配置即可" |
### 数据指标预期
| 指标 | 预期变化 | 衡量方式 |
|------|---------|---------|
| 页面加载速度 | P99 < 1s | 前端监控 |
| 订单提交成功率 | > 99.5% | 服务端监控 |
| 用户投诉 | 下降 50% | 客服数据 |
5.2 风险评估的产品化
技术版风险评估：
"Redis 缓存击穿风险：热点数据过期瞬间，大量请求同时访问数据库"
产品版风险评估：
"在极端情况下（如大促活动时），部分热门页面的加载速度
可能会暂时变慢（从 0.5 秒回到 3 秒左右），但不会完全打不开。
我们会在活动前提前预热缓存来避免这个问题。"
六、让 PM 参与技术决策的时机
6.1 哪些决策需要 PM 参与
需要 PM 参与的 5 类技术决策：
1. 体验取舍型
"我们可以做到实时数据更新，但用户需要等待 5 秒。
或者我们先展示 5 分钟前的数据，秒开。
你觉得哪种体验更好？"
2. 范围取舍型
"MVP 版本我们建议先支持 3 种导出格式，剩下 2 种放到 V2。
业务上只有这 3 种够用吗？"
3. 成本告知型
"这个功能要实现你要的效果，需要搭建一个推荐系统，
开发周期 2 个月。如果用简易版（基于标签匹配），2 周就行。
你觉得从业务角度，值得等 2 个月吗？"
4. 风险告知型
"这个方案在用户量增长到 10 万时，需要再加机器扩容。
按目前增长速度，预计明年 Q1 需要扩容。
从预算角度，可以接受吗？"
5. 策略确认型
"缓存更新有两个策略：
策略 A：实时更新，但系统复杂度增加 30%
策略 B：5 分钟更新一次，实现简单
从业务角度，5 分钟的延迟可以接受吗？"
6.2 不打扰 PM 的决策
以下决策不需要 PM 参与，RD 自己决定：
- 用 MySQL 还是 PostgreSQL
- 用 Redis 还是本地缓存
- 接口用 RESTful 还是 GraphQL
- 日志格式用什么
- 代码怎么组织
- 用什么设计模式
- 单元测试怎么写
原则：
影响用户体验的 → 需要 PM 参与
纯技术实现的 → RD 自己决定
七、实际案例对比：一份技术方案的两个版本
7.1 案例背景
需求：运营后台的客户列表页，增加"批量导出"功能
7.2 技术版（给 RD 看）
# 客户列表批量导出 - 技术方案
## 架构设计
- 前端触发导出请求 → BFF 层 → Export Service
- Export Service 通过 MyBatis 分页查询 customer 表
- 使用 EasyExcel 流式写入，避免 OOM
- 上传至 OSS，返回下载链接
- 通过 RocketMQ 发送导出完成通知
## 数据模型
CREATE TABLE export_task (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
task_no VARCHAR(32) UNIQUE NOT NULL,
user_id BIGINT NOT NULL,
status VARCHAR(16) NOT NULL DEFAULT 'PENDING',
...
) ENGINE=InnoDB;
## 接口设计
POST /api/v1/export/customers
Request: { queryParams, requestId }
Response: { taskNo, status }
## 性能评估
- 单次导出最大 10 万行，预计耗时 30-60 秒
- 并发限制：每用户每小时最多 5 次
- 使用 SXSSFWorkbook 控制内存占用 < 512MB
7.3 产品版（给 PM 看）
# 客户列表批量导出 - 给产品经理的说明
## 一句话总结
运营可以在后台一键导出客户数据到 Excel，以前需要 30 分钟手工操作，
现在点一下按钮，等 1 分钟就能下载。
## 用户体验
1. 运营打开客户列表页，点击"导出"
2. 系统弹出提示："正在生成导出文件，完成后会通知你"
3. 运营可以继续做其他事
4. 1 分钟左右，系统通知"导出完成"，点击下载 Excel 文件
## 需要注意的地方
- 📊 单次最多导出 10 万条客户（覆盖 99% 的日常需求）
- ⏱️ 生成文件需要等待约 1 分钟（后台处理）
- 🔄 每小时最多导出 5 次（避免服务器压力过大）
- 💡 如果数据量特别大，建议用"高级筛选"缩小范围
## 上线计划
- 预计开发周期：5 个工作日
- 预计上线时间：6 月 25 日
- 分批上线：先给运营组的 10 个人开放，稳定后全量
## 需要你确认的事情
1. 导出的 Excel 需要包含哪些字段？（我列了一个字段清单，你看看）
2. "已完成"的导出文件，需要保留多久？（建议 7 天自动删除）
3. 是否需要支持"定时自动导出"？（建议 V2 再做）
7.4 对比总结
两个版本的区别：
技术版 产品版
────────────────────────────────────────────
假设读者懂技术 假设读者不懂技术
用技术术语描述 用业务场景描述
关注"怎么实现" 关注"有什么用"
技术风险和降级方案 业务影响和体验变化
架构图、时序图、ER 图 用户操作流程图
八、总结
8.1 给 RD 的 7 条建议
- 先写产品版，再写技术版：产品版帮你自己理清"用户视角"
- 每个技术决策都加上"这对用户意味着什么"：一句就够了
- 架构图给 PM 看之前，去掉所有技术组件：只保留业务模块和用户操作流
- 技术方案不是越长越好：PM 需要的核心信息不超过一页纸
- 主动标记"需要 PM 决策"的事项：不要让 PM 从 20 页里找
- 用类比和比喻："就像你在淘宝下单一样，你点完就不用管了"
- 写完找 PM 反馈："你看得懂吗？哪里需要我解释？"
8.2 一句话总结
一份好的技术方案，不仅要让 RD 同事点头，更要让 PM 看完后说"原来如此，我理解了"。技术方案的终极目标不是展示你的技术深度，而是让所有人对齐认知，让项目顺利推进。