# 19. Коммуникация

Как архитектор объясняет решения инженерам, продукту и бизнесу: vocabulary, diagrams, trade-off language и decision facilitation.

- **Author:** Фёдор Чищин
- **Level:** advanced
- **Reading time:** ~25 минут чтения
- **Published:** 2026-05-23
- **Source:** https://fedorthinks.com/ru/learn/software-architect-19-communication

---

## 1. Главная идея

Архитектор должен говорить на языке аудитории, не упрощая смысл до пустых лозунгов.

### Разным людям нужны разные объяснения

> Один и тот же маршрут водитель, пассажир и механик описывают по-разному. Все три описания могут быть правильными.

Инженеру нужны границы, контракты, edge cases, migration plan. Product manager хочет понять impact on roadmap, risk и sequencing. Бизнесу важны cost, time-to-market, compliance, reliability и future optionality.

Плохой архитектор говорит всем одинаково и обижается, что его не поняли. Хороший сохраняет техническую точность, но меняет уровень абстракции.

### Архитектор фасилитирует решение

> Хороший модератор не выигрывает спор. Он помогает группе увидеть варианты, риски и выбрать направление.

Коммуникация архитектора — это не презентация «моё решение правильное». Это процесс: сформулировать problem statement, собрать constraints, назвать options, сравнить trade-offs, зафиксировать decision и consequences.

Когда люди понимают, почему альтернатива отвергнута, сопротивление обычно снижается. Даже если решение неприятное.

## 2. Пример и антипример

Профессиональная коммуникация делает компромиссы видимыми и проверяемыми.

### Пример: объяснить отказ от микросервисов

> Иногда лучший способ ускорить стройку — не добавлять ещё одну бригаду, а убрать лишние согласования.

Архитектор говорит: «Мы остаёмся на modular monolith на два квартала. Причина: одна команда, общий релизный ритм, низкая нагрузка, нет отдельного ownership для сервисов. Мы вводим module boundaries и ADR. Пересмотрим решение, когда появится отдельная billing-команда или независимый compliance-релиз».

Это не «микросервисы плохие». Это decision с контекстом и триггером пересмотра.

### Антипример: давить авторитетом

> Фраза «я архитектор, значит так надо» закрывает разговор, но не создаёт понимания.

Архитектор навязывает Kafka, потому что «это enterprise standard», не объясняя проблему, цену и альтернативы. Команда формально соглашается, но не понимает модель, допускает ошибки и начинает обходить решение.

В архитектуре авторитет без ясности почти всегда создаёт скрытое сопротивление.

#### Самопроверка

- Как я объясню это решение инженеру, PM и CEO?
- Какие альтернативы были честно рассмотрены?
- Где записаны consequences?
- Что команда сможет решить сама после этого разговора?

Следующий модуль: [Лидерство без власти](./software-architect-20-leadership).