Техническая коммуникация: как объяснить сложное простыми словами

Вы можете написать идеальный код, но если не умеете объяснить, зачем он нужен, — это бесполезно. Техническая коммуникация — это навык, который отличает senior от middle.

Проблема

Типичное объяснение разработчика:

“Мы используем event-driven architecture с CQRS паттерном, где команды обрабатываются через message broker с at-least-once delivery гарантией, а read model обновляется асинхронно через event sourcing.”

Что слышит менеджер: “Бла-бла-бла технические термины бла-бла.”

Проблема не в том, что менеджер глупый. Проблема в том, что вы говорите на разных языках. Ваша задача — быть переводчиком.

Принцип: от проблемы к решению

Плохое объяснение начинается с технологий:

• “Мы используем Redis”
• “Внедряем микросервисную архитектуру”
• “Переходим на Kubernetes”

Хорошее объяснение начинается с проблемы:

• “Пользователи ждут 5 секунд загрузки страницы”
• “Теряем 30% конверсии из-за медленной работы”
• “Кеш ускорит загрузку до 100 миллисекунд”
• “Для этого используем Redis”

Видите разницу? Сначала проблема и её влияние на бизнес, потом решение, и только в конце — технология.

Правило трёх уровней

Готовьте объяснение на трёх уровнях детализации. Как зум на карте: сначала видите страну, потом город, потом улицу.

Уровень 1: Лифт-питч (30 секунд)

Представьте, что вы встретили CEO в лифте. У вас есть 30 секунд, чтобы объяснить, над чем вы работаете.

Пример:

“Мы ускорили загрузку страницы с 5 секунд до 100 миллисекунд. Это увеличит конверсию на 30%.”

Для кого: CEO, инвесторы, случайные встречи

Что важно: только результат и влияние на бизнес. Никаких технических деталей.

Уровень 2: Встреча (5 минут)

Вы на встрече с менеджером или продакт-менеджером. У вас есть 5 минут, чтобы объяснить проблему и решение.

Пример:

Проблема: База данных не справляется с нагрузкой. Каждый запрос идёт в базу, это медленно.

Решение: Добавили кеш между приложением и базой. Популярные данные хранятся в памяти — быстрый доступ.

Результат: Ускорение в 50 раз, меньше нагрузка на базу данных.

Стоимость: 2 недели разработки, $100 в месяц на инфраструктуру.

Для кого: менеджеры, продакт-менеджеры

Что важно: проблема, решение, результат, стоимость. Минимум технических терминов.

Уровень 3: Технический (30 минут)

Вы на технической встрече с другими разработчиками. Здесь можно говорить на техническом языке.

Пример:

Технология: Redis Cluster с 3 нодами

Паттерн: Cache-aside с lazy loading

TTL: 1 час для горячих данных, 24 часа для статических

Eviction: LRU с maxmemory-policy allkeys-lru

Мониторинг: Prometheus + Grafana, алерты на hit rate < 80%

Для кого: разработчики, архитекторы, DevOps

Что важно: технические детали, конфигурация, мониторинг, потенциальные проблемы.

Используйте аналогии

Сложные концепции через простые аналогии:

Микросервисы

Плохо: “Мы разбили монолит на микросервисы с независимым деплоем”

Хорошо: “Раньше весь код был в одном здании. Если что-то ломалось, падало всё. Теперь каждая функция — отдельное здание. Если одно падает, остальные работают.”

Кеширование

Плохо: “Используем in-memory key-value store для снижения latency”

Хорошо: “Представьте библиотеку. Каждый раз идти в архив долго. Мы держим популярные книги на стойке — быстрый доступ.”

Race Condition

Плохо: “Concurrent access to shared memory without synchronization”

Хорошо: “Два человека одновременно редактируют документ. Один сохраняет, второй сохраняет — изменения первого теряются.”

Визуализация

Картинка говорит больше тысячи слов:

До оптимизации

Пользователь → API → База данных (5 секунд)

После оптимизации

Пользователь → API → Кеш (100ms) ✓
                   ↓
              База данных (только при промахе)

Избегайте жаргона

Замените технические термины на понятные:

Структура объяснения

1. Контекст

“Сейчас у нас 10,000 пользователей в день. К концу года ожидаем 100,000.”

2. Проблема

“Текущая архитектура не выдержит такой нагрузки. Сервер упадёт при 20,000 пользователей.”

3. Решение

“Нужно масштабировать горизонтально: добавить больше серверов и балансировщик нагрузки.”

4. Альтернативы

“Рассматривали вертикальное масштабирование (более мощный сервер), но это дороже и есть предел.”

5. Риски

“Усложнится деплой и мониторинг. Нужно 2 недели на настройку.”

6. Метрики успеха

“Сможем обработать 200,000 пользователей в день. Время ответа останется < 200ms.”

Примеры из практики

Объяснение архитектурного решения

Плохо:

“Мы мигрируем на event-driven architecture с использованием Apache Kafka как message broker и реализуем CQRS pattern с separate read/write models.”

Хорошо:

“Проблема: Когда пользователь делает заказ, нужно обновить инвентарь, отправить email, начислить бонусы. Сейчас всё происходит последовательно — медленно и ненадёжно.

Решение: Разбиваем на независимые шаги. Заказ создаётся быстро, остальное происходит в фоне. Если email не отправился, заказ не отменяется.

Результат: Заказ создаётся за 100ms вместо 2 секунд. Система надёжнее — сбой в одной части не ломает всё.”

Объяснение бага

Структура:

• Что сломалось: Пользователи не могли войти в систему
• Кого затронуло: 500 пользователей, 2 часа простоя
• Почему произошло: База данных заполнилась, новые сессии не создавались
• Как исправили: Очистили старые сессии, увеличили место
• Как предотвратить: Добавили автоочистку и мониторинг места на диске

Коммуникация в коде

Комментарии

Плохо:

// Увеличить счётчик
counter++

Хорошо:

// Отслеживаем неудачные попытки входа для rate limiting.
// После 5 попыток пользователь блокируется на 15 минут.
failedAttempts++

Commit messages

Плохо:

fix bug

Хорошо:

Fix race condition in user session cleanup

Проблема: Несколько горутин могли удалять одну сессию,
вызывая панику.

Решение: Добавили мьютекс для синхронизации доступа.

Влияние: Устраняет падения при высокой нагрузке.

Документация

README структура

# Название проекта

## Что это
Одно предложение о назначении.

## Зачем это нужно
Какую проблему решает.

## Быстрый старт
Минимум команд для запуска.

## Как это работает
Высокоуровневая архитектура.

## Примеры использования
Реальные сценарии.

ADR (Architecture Decision Record)

Документируйте архитектурные решения:

• Заголовок: Краткое название решения
• Контекст: В какой ситуации принималось решение
• Решение: Что именно решили
• Обоснование: Почему выбрали этот вариант
• Последствия: Какие будут плюсы и минусы

Презентации

Структура слайда

• Заголовок: Одна мысль
• Визуализация: Диаграмма или график
• Текст: Максимум 3 пункта

Плохо: 20 строк кода на слайде

Хорошо: Ключевая строка + объяснение

Демо

Структура эффективной демонстрации:

1. Показать проблему: Как работает сейчас
2. До изменений: Медленно, неудобно
3. После изменений: Быстро, удобно
4. Метрики: Конкретные цифры улучшения

Работа с нетехническими людьми

Менеджеры хотят знать

• Когда будет готово: Сроки и этапы
• Сколько стоит: Бюджет и ресурсы
• Что может пойти не так: Риски и план Б
• Как повлияет на бизнес: Метрики и KPI

Продакт-менеджеры хотят знать

• Как повлияет на пользователей: UX и функциональность
• Какие фичи разблокирует: Новые возможности
• Что не сможем сделать: Ограничения и компромиссы

Обратная связь

Давать фидбек

Плохо: “Этот код плохой”

Хорошо:

• Наблюдение: “Эта функция делает 3 вещи”
• Влияние: “Сложно тестировать и поддерживать”
• Предложение: “Разбить на 3 функции”
• Пример: Показать, как это может выглядеть

Получать фидбек

1. Слушайте, не перебивайте
2. Уточните, если непонятно: “Можешь показать пример?”
3. Поблагодарите за время и внимание
4. Подумайте, прежде чем защищаться: Дайте себе 24 часа

Практические упражнения

Упражнение 1: Объясни бабушке

Выберите сложную концепцию. Объясните так, чтобы понял человек без технического бэкграунда.

Упражнение 2: Лифт-питч

30 секунд на объяснение вашего проекта. Без технических терминов.

Упражнение 3: Диаграмма

Нарисуйте архитектуру системы. Если нужно больше 5 минут на объяснение — упростите.

Заключение

Техническая коммуникация — это:

• Начинать с проблемы, не с технологий
• Адаптировать уровень детализации под аудиторию
• Использовать аналогии и визуализацию
• Избегать жаргона
• Структурировать объяснение

Помните:

Хороший код + плохая коммуникация = плохой результат

Средний код + хорошая коммуникация = хороший результат

Учитесь объяснять. Это важнее, чем вы думаете.

Дополнительные ресурсы

• The Art of Explanation by Lee LeFever
• Made to Stick by Chip Heath & Dan Heath
• Resonate by Nancy Duarte