做一个技术方案要花多少时间

一、为什么很多方案讲不清楚

不是表达能力问题，是没想清楚就开始讲。方案文档写不出来，通常说明方案本身还有没定的关键点。

我自己的判断标准是：如果讲的时候要靠"这里我们先这样，后面再优化"来糊过去，那就是没想清楚。 真正想清楚的人讲方案是不带犹豫的，犹豫的地方就是没想清楚的地方。

二、写方案先回答这四个问题

一、要解决什么问题。 一句话，说不出来就是没想清楚。常见的问题是写了方案但说不出它解决什么，只说"优化架构"。

二、怎么做，有几种选择。 至少两种。只想到一种方案的方案，通常是没想过别的可能。

三、为什么选这个。 这一段才是方案的重点。“我们对比了 A 和 B，选 A 因为……” 比通篇描述 A 有说服力得多。

四、有什么风险和代价。 说不清代价的方案，是在推销而不是在决策。

三、一段能用的方案模板

## 背景
现在 XX 每次要 3 秒，原因是 XX（一句话）
影响：XX 场景下用户等待过长

## 目标
把耗时降到 1 秒以内
不追求：实时性再提升（本期不做）

## 方案对比

| 方案 | 做法 | 预估耗时 | 改动范围 | 风险 |
|---|---|---|---|---|
| A 缓存 | 热点数据缓存 5 分钟 | 200ms | 小 | 数据可能不新鲜 |
| B 改查询 | 加索引 + 拆分查询 | 600ms | 中 | 需要改 SQL |
| C 异步 | 转异步 + 前端轮询 | 立即返回 | 大 | 交互变复杂 |

## 结论
选 A。覆盖 90% 的请求，改动最小。
B 作为后续优化方向，索引改动可以独立上线。

## 风险与验证
风险：数据不新鲜，用在 XX 场景可接受
验证：上线后对比 P99 耗时

这个结构的好处是：“选 A” 和 “不选 B、C” 的理由都在文档里，评审时不用反复问"为什么不试试别的"。

四、汇报的时候别从技术开始

顺序很重要：

1. 先说问题。 “现在每次操作要等 3 秒，用户投诉过两次。”
2. 再说影响。 “这个页面是每天访问最高的页面之一，DAU 一千多。”
3. 最后才说方案。 “我建议先加缓存，能降到 200 毫秒。”

反过来先讲技术方案，听众在还没意识到问题重要性的时候就开始评估技术细节，往往得出"这个方案好像有点复杂"的结论，而没意识到简单方案可能不够。

五、方案被否了怎么办

先问否决的理由是哪一层。

• “这个方案我们以前试过，有问题” —— 这是最有价值的信息，问清楚具体什么问题，避免重新踩坑。
• “太复杂了” —— 问能简化到哪一步，往往能砍出一个够用的最小版本。
• “再想想” —— 大概率是当前场合不适合讨论，私下再问。

不要在会上争论。 会上争论方案，最后往往是提出方案的人妥协，而且失去后续话语权。会上记录下来，会后单独沟通。

六、方案落地的最后一件事

方案定了之后，把它变成可验证的东西。如果是技术方案，配一个能跑的 demo；如果是流程方案，写成具体的 checklist；如果是配置变更，给出完整的前后对比。

"下周开始改"这种表述是没有信息量的，而"先加索引上线，观察三天 P99，没降下来再走缓存"这种表述是可以被跟踪、被讨论、被追责的。

差别在于：第二种把决策变成了一个可以验证的假设，而不是一个承诺。