и почему её отсутствие делает ещё хуже…

В большинстве компаний delivery пытаются лечить коммуникацией.

Не успеваем — давайте добавим встречи
Не понимаем друг друга — давайте добавим синки
Конфликты — давайте соберём всех и обсудим

Это звучит разумно, но если посмотреть на систему чуть глубже, то становится видно странное:

чем больше коммуникации, тем ниже предсказуемость

А если убрать коммуникацию, всё разваливается ещё быстрее.

Парадокс

Delivery ломается в двух крайностях:

• слишком много коммуникации = хаос

• слишком мало коммуникации = дезинтеграция

И в обоих случаях команды приходят к одному и тому же:

невозможность прогнозировать результат

Часть 1. Когда коммуникации слишком много

Иллюзия контроля

Один из самых частых паттернов:

• команда не успевает, а менеджмент увеличивает количество синков

Сначала это выглядит как контроль, но потом превращается в зависимость.

Кейc 1. «Команда, которая жила в календаре»

Продуктовая команда (~20 человек):

• ежедневный стендап

• 3 синка в неделю по статусу

• отдельные встречи по фичам

• отдельные обсуждения пожаров

И при этом:

• сроки постоянно срываются

• задачи переоткрываются

• команда перегружена

• растет недовольство разработки (не дают заниматься «делом»)

Что оказалось на самом деле

Мы разобрали систему и увидели:

• приоритеты менялись каждую неделю

• решения не фиксировались

• backlog не имел структуры

• у каждой задачи было несколько «версий правды»

Каждая встреча не уменьшала неопределенность, а пересобирала её заново

Эффект

• рост когнитивной нагрузки

• потеря фокуса

• зависимость от последнего разговора

• компрометация документации (не все решения из разговоров своевременно превращаются в обновление документации)

система перестала быть детерминированной.

Часть 2. Когда коммуникации недостаточно

Теперь другая крайность.

Кейc 2. «Сильная команда, которая молчит»

Инженерная команда с высоким уровнем:

• сильные разработчики

• автономные команды

• минимум встреч

Идеал, на первый взгляд.

Но через 2-3 месяца

• команды начали расходиться в архитектуре

• дублировались решения

• возникли несовместимые компоненты

И главное, никто не понимал, что происходит (в целом).

Причина

Коммуникации было мало, но проблема глубже:

• не было общей модели системы

• не было зафиксированных решений

• не было единых принципов

Эффект

• локальная оптимизация

• глобальная деградация

Важный вывод

Проблема не в количестве коммуникации. Проблема в отсутствии системы, которая определяет когда и зачем она нужна.

Часть 3. Где на самом деле ломается согласованность

Согласованность это не: «люди поняли друг друга».

Это:

система ведёт себя предсказуемо во времени

Она ломается, когда:

• решения не финализируются

• приоритеты нестабильны

• правила необязательны

Кейc 3. «Backlog как список желаний»

Типичный сценарий.

Backlog:

• задачи разного масштаба

• нет явной приоритизации

• постоянные «срочные» вбросы

Коммуникации много. Каждая новая задача обсуждается. Каждое обсуждение меняет контекст.

Что происходит

• команда теряет горизонт планирования

• прогнозы становятся фикцией

• доверие к системе падает

Часть 4. Переломный момент

Ключевой вопрос, который меняет всё:

Что если проблема не в коммуникации,
а в том, что система не задаёт рамки для решений?

Governance вместо коммуникации

Коммуникация является симптомом, а Governance является причиной.

Что меняется

Вместо:

• обсуждения каждой задачи

• ручных согласований

• постоянных синков

Появляется:

• модель приоритетов

• правила принятия решений

• прозрачная структура backlog

Кейc 4. «Backlog как инвестиционный портфель»

Мы переупаковали backlog из списка задач, в систему управления инвестициями.

Что добавили

Каждая задача получила:

• тип ценности

  • Growth (рост)

  • Protection (защита)

  • Research (исследование)

• сигнал спроса (Requests как фактический спрос)

• возраст (как долго задача лежит)

Что изменилось

• обсуждения стали короче

• решения стали быстрее

• приоритеты стали стабильнее

И неожиданно:

• количество коммуникации снизилось

Почему

Потому что:

• меньше неопределенности

• меньше интерпретаций

• меньше «ручного управления»

Часть 5. Баланс: сколько коммуникации нужно

Правильный вопрос звучит не так:

НЕ «Сколько нам нужно встреч?»

А так:

«Где система требует синхронизации?»

Коммуникация нужна, когда:

• принимаются новые решения

• меняется контекст

• появляются риски

Коммуникация вредна, когда:

• она заменяет правила

• она компенсирует хаос

• она становится способом держать всё под контролем

Главный сдвиг

Не:

«Давайте лучше коммуницировать»

А:

«Давайте построим систему, в которой коммуникация нужна реже»

Финальный кейс. «Когда система начинает работать»

После внедрения governance в одной из команд:

• количество встреч снизилось ~30%

• прогнозируемость релизов выросла

• напряжение в команде снизилось

Но самое важное:

• исчезла зависимость от «последнего разговора»

Вывод

Коммуникация — это не решение. Ровно как и её отсутствие, тоже не решение.

Настоящее решение

Это:

• последовательные решения

• стабильные приоритеты

• управляемая система

Согласованность — это свойство системы, а коммуникация, лишь её побочный эффект.