# 19. 沟通

架构师如何向工程师、产品和业务解释决策：vocabulary、diagrams、trade-off 语言以及 decision facilitation。

- **Author:** Fedor Chishchin
- **Level:** advanced
- **Reading time:** 约 25 分钟阅读
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/zh/learn/software-architect-19-communication

---

## 1. 核心观点

架构师必须用听众的语言说话，但不能把含义压扁成空洞的口号。

### 不同的人需要不同的解释

> 同一条路线，司机、乘客和修理工会用三种方式描述。三种描述都可能是对的。

工程师需要 boundaries、contracts、edge cases 和 migration plan。Product manager 想知道对 roadmap 的影响、风险和 sequencing。业务关心的是 cost、time-to-market、compliance、reliability 和 future optionality。

差的架构师对所有人用一套话术，然后抱怨别人没听懂。好的架构师保留技术上的精确度，只调整抽象层级。

### 架构师在做 decision facilitation

> 好的主持人不是赢下争论的那个人。他帮助一组人看清选项、风险，并选出方向。

架构师的沟通不是一场"我的方案是对的"的演讲。它是一个过程：陈述 problem statement、收集 constraints、列出 options、对比 trade-offs、记录 decision 与 consequences。

当人们理解为什么某个替代方案被否决，阻力通常会下降——哪怕决策本身并不讨喜。

## 2. 例子与反例

专业的沟通让 compromise 变得可见、可被检验。

### 例子：解释为什么暂不上微服务

> 有时候加快工程进度的方式，不是再加一个施工队，而是去掉多余的审批环节。

架构师说："接下来两个季度我们继续用 modular monolith。原因：一个团队、统一的发布节奏、负载不高、服务没有独立的 ownership。我们会引入 module boundaries 和 ADR。出现独立的 billing 团队或独立的 compliance 发布时，重新审视这个决定。"

这不是"微服务不好"。这是一个带上下文、带触发条件的 decision。

### 反例：靠权威压人

> "我是架构师，就得这么干"——这句话能终结对话，但不会创造理解。

架构师强推 Kafka，理由是"这是 enterprise standard"，不解释问题、代价和替代方案。团队表面同意，但没理解模型，开始犯错，并慢慢绕开这个决策。

在架构里，权威而无清晰几乎一定会催生暗中抵触。

#### 自检

- 我要怎么把这个决策分别讲给工程师、PM 和 CEO 听？
- 哪些替代方案被认真考虑过？
- consequences 写在哪里？
- 这次谈话之后，团队能自己决定哪些事？

下一模块：[无权威的领导力](./software-architect-20-leadership)。