Коммуникация с заинтересованными сторонами, документация, прозрачность, асинхронная коммуникация
Время освоения: ~40 минут Цель: Освоить инструменты эффективной коммуникации на всех уровнях — от команды до топ-менеджмента, научиться управлять ожиданиями и документировать решения
| Тип | Когда использовать | Плюсы | Минусы |
|---|---|---|---|
| Синхронная | Кризис, сложные дискуссии, эмоциональные темы | Быстрое решение, ясность интонации | Прерывает рабочий поток, не масштабируется |
| Асинхронная | Статус, документация, RFC, обновления | Не прерывает, есть запись, масштабируется | Медленный отклик, риск недопонимания |
| Уровень | Аудитория | Язык | Частота |
|---|---|---|---|
| Team | Разработчики | Технический, детальный | Ежедневно |
| Stakeholder | PM, продакт, бизнес | Бизнес-язык, компромиссы | Еженедельно |
| Exec | CTO, VP, директор | Метрики, риски, решения | Ежемесячно / по запросу |
| Инструмент | Уровень | Тип | Когда |
|---|---|---|---|
| Стендап | Team | Синхронный | Ежедневно |
| Slack/Teams | Team/Stakeholder | Асинхронный | Постоянно |
| 1:1 встречи | Team | Синхронный | Раз в 1–2 недели |
| RFC документ | Team/Stakeholder | Асинхронный | При значимых изменениях |
| Status update | Stakeholder | Асинхронный | Еженедельно |
| ADR | Team/Stakeholder | Асинхронный | При архитектурных решениях |
| Incident report | Stakeholder/Exec | Асинхронный | После инцидентов |
Коммуникация — главный рычаг тимлида. Технические навыки решают проблемы в коде. Коммуникационные навыки решают проблемы в людях, процессах и ожиданиях.
Почему коммуникация критична для тимлида:
Три главные коммуникационные задачи тимлида:
💡 Помните: Плохая коммуникация не означает «мало слов». Часто это «не те слова, не той аудитории, не в нужный момент».
Стейкхолдер — любой, кто имеет интерес или влияние на результат работы команды: PM, продакт, бизнес-заказчик, другие команды, CTO.
Принципы управления ожиданиями:
Subject: [Команда Backend] Статус — неделя 7
## Выполнено
- Завершена интеграция с платёжной системой
- Исправлено 3 критических бага из прошлого спринта
## В работе
- Миграция базы данных (60% готово, план — четверг)
- Рефакторинг auth-модуля (начали, завершим следующую неделю)
## Риски
- Зависимость от команды DevOps может сдвинуть деплой на пятницу
- Если не получим доступ к тестовой среде до среды — выкатываем в понедельник
## Нужна помощь
- Решение по API-контракту нужно от команды Mobile до среды
Правило раннего предупреждения: Если вы видите риск, сообщите о нём, когда у стейкхолдеров ещё есть время отреагировать.
Плохо (за день до дедлайна):
«Мы не успеем, потому что зависимость от DevOps не была решена»
Хорошо (за неделю):
«Есть риск задержки деплоя на 2–3 дня из-за зависимости от DevOps.
Я уже разговариваю с их тимлидом. Если не решим до среды — сдвигаем план.
Хочу, чтобы вы были в курсе заранее.»
Отказ без альтернатив разрушает доверие. Отказ с альтернативами — строит его.
Формула отказа:
1. Признать запрос: «Понимаю, что X важно для бизнеса»
2. Объяснить constraint: «При текущей загрузке это займёт N недель»
3. Предложить альтернативу: «Но мы можем сделать Y к дедлайну,
а полную версию X через 2 недели»
4. Передать решение: «Как лучше: MVP сейчас или полная версия позже?»
Асинхронность — суперсила распределённых команд и инструмент защиты времени разработчиков.
Принципы:
Принцип documentation-first: Если вопрос задаётся второй раз — пора написать документ. Если встреча нужна для принятия решения — сначала RFC.
RFC — инструмент для принятия значимых технических решений асинхронно.
Структура RFC:
# RFC-007: Переход на GraphQL API
## Автор: Иван Петров
## Статус: На обсуждении
## Дедлайн для комментариев: 15 марта
## Проблема
REST API не справляется с вариативностью запросов мобильного клиента.
Овер-фетчинг приводит к +40% трафика на мобильных устройствах.
## Предлагаемое решение
Перейти на GraphQL для мобильного API, оставив REST для внутренних сервисов.
## Альтернативы
- BFF (Backend For Frontend) с REST — проще, но дублирует логику
- gRPC — эффективнее, но нет поддержки в браузерных клиентах
## Влияние
- 2 спринта на реализацию
- Нужно обучение команды GraphQL
- Миграция мобильных клиентов — координация с mobile-командой
## Вопросы для обсуждения
1. Согласны ли с проблемой?
2. Есть ли альтернативы, которые я не рассмотрел?
Как работать с RFC:
«Почему мы выбрали PostgreSQL, а не MongoDB?» — вопрос, который возникает через год. Если решение не задокументировано, команда рискует повторить уже пройденный путь или потерять контекст.
ADR (Architecture Decision Record) — минимальный формат документирования:
# ADR-003: Использование Redis для кэширования сессий
## Статус: Принято (февраль 2024)
## Контекст
При масштабировании до 10k одновременных пользователей сессии в памяти
не работают в multi-instance окружении.
## Решение
Redis как внешний сессионный хранилище с TTL 24 часа.
## Последствия
+ Масштабируется горизонтально
+ Сессии переживают перезапуск приложения
- Дополнительная инфраструктурная зависимость
- Нужен мониторинг Redis
## Отвергнутые варианты
- JWT в cookies: сложно инвалидировать, не подходит для нашей модели безопасности
- Sticky sessions: не масштабируется при автоскейлинге
Принцип «Why, not What»:
Поддержание актуальности:
Кризис проверяет коммуникационную культуру команды. Правильная коммуникация в инциденте снижает панику и ускоряет решение.
Роли в инциденте:
Шаблон обновления во время инцидента:
[14:35] ИНЦИДЕНТ - Статус: В работе
Что произошло: API платежей возвращает 500 для ~30% запросов с 14:15
Влияние: ~500 пользователей не могут завершить покупку
Что делаем: Исследуем логи, вероятная причина — деплой 13:45
Следующее обновление: через 20 минут или при изменении статуса
После инцидента: Postmortem:
# Postmortem: Инцидент с платежным API (15 февраля)
## Хронология
- 14:15 — начало инцидента (алерт не сработал)
- 14:30 — обнаружено командой через жалобы пользователей
- 14:45 — выявлена причина (неправильная миграция БД)
- 15:10 — восстановление
## Причина
Миграция изменила тип поля amount с INTEGER на DECIMAL без совместимости.
## Что сработало хорошо
- Команда быстро собралась и скоординировалась
## Что улучшить
- Настроить алерт на процент ошибок >5%
- Добавить smoke-тест после деплоя
## Action items
- [ ] Настроить алерт — Иван, до 20 февраля
- [ ] Добавить smoke-тесты — Мария, до 25 февраля
Правила:
Структура: «Хочу сообщить о проблеме [факт].
Это означает [влияние].
Вот что мы уже делаем [план].
Мне нужна ваша помощь с [конкретный запрос].»
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Использовать технический жаргон со стейкхолдерами | Теряется доверие, стейкхолдеры чувствуют себя некомпетентными и начинают микроменеджмент | Переводить технические концепции в бизнес-метрики: сроки, риски, стоимость |
| Сообщать о проблемах только когда они уже критические | Стейкхолдеры теряют доверие, у них нет времени среагировать | Внедрить правило: риск становится известен — сразу сообщаем с вариантами решения |
| Принимать решения на встречах без документирования | Через месяц никто не помнит «почему», решения переоткрываются заново | Вести краткие notes на каждой встрече, отправлять summary с action items |
| Считать, что «все всё поняли» без подтверждения | Каждый уходит с разным пониманием, расхождение обнаруживается слишком поздно | Завершать встречи проверкой: «Давайте убедимся, что мы одинаково понимаем следующие шаги» |
| Переходить в синхрон для каждого вопроса (meeting culture) | Разработчики теряют deep work время, продуктивность падает | Договориться о нормах: что идёт в документ, что в чат, что требует встречи |
| Документировать «что» без «почему» в ADR и коде | Будущая команда не знает контекст и повторяет уже принятые решения | Каждое решение сопровождать обоснованием и перечнем отвергнутых альтернатив |
Ответьте на вопросы:
Выберите одно техническое решение, которое стоит перед командой прямо сейчас. Напишите RFC:
Далее: Планирование