Кейс о цене плохой коммуникации
Плохая коммуникация редко выглядит как большая управленческая проблема.
Обычно это что-то очень бытовое.
Кто-то не уточнил.
Кто-то понял по-своему.
Кто-то не передал изменение.
Кто-то решил, что другой и так знает.
Но в сложной системе именно такие мелкие разрывы способны создавать очень дорогие последствия.
Потому что проблема коммуникации почти никогда не заканчивается на одном неверном сообщении.
Она проходит по цепочке дальше.
Всё начиналось с простой задачи
Представим кросс-функциональный проект.
В нём участвуют бизнес, HR, IT и обучение.
Нужно изменить процесс и одновременно обновить цифровой инструмент, инструкции и обучение сотрудников.
На старте договорились, что бизнес формирует требования, HR описывает новый процесс, IT вносит изменения в систему, а обучение готовит материалы для сотрудников.
Все роли понятны.
Все согласны.
Проект запущен.
Проблема возникла позже, когда бизнес немного изменил требования.
Изменение казалось небольшим.
О нём обсудили на встрече.
Несколько участников услышали.
Несколько — нет.
Формально решение было принято.
Но не было зафиксировано так, чтобы вся система одинаково его поняла.
Одна и та же информация стала существовать в нескольких версиях
HR продолжил работать по новой логике.
IT — по предыдущей.
Команда обучения получила промежуточный вариант.
Операционный блок вообще ориентировался на первую согласованную версию процесса.
На протяжении нескольких недель никто не видел серьёзной проблемы.
Каждая команда была занята своей частью.
У всех были задачи.
У всех были статусы.
У всех был прогресс.
Именно поэтому плохая коммуникация так опасна.
Она часто не создаёт мгновенную остановку.
Она создаёт параллельные версии реальности.
Ошибка обнаружилась слишком поздно
Проблема стала очевидна только на этапе интеграции.
IT показал готовый функционал.
HR увидел, что часть логики реализована по старым требованиям.
Команда обучения поняла, что материалы уже не соответствуют процессу.
Операционный блок запросил дополнительные изменения.
Началась переделка.
Пришлось корректировать техническое решение.
Обновлять инструкции.
Пересобирать обучение.
Переносить сроки пилота.
Снова собирать руководителей.
Снова согласовывать.
Одна маленькая коммуникационная ошибка превратилась в несколько недель дополнительной работы.
Цена была не только во времени
Обычно в таких ситуациях считают прямую стоимость.
Дополнительные часы IT.
Переделка материалов.
Перенос запуска.
Но реальная цена гораздо выше.
Во-первых, появляется стоимость переключения.
Люди уже перешли к другим задачам и вынуждены возвращаться назад.
Во-вторых, возникает управленческая нагрузка.
Руководители снова включаются в проект, который считали почти завершённым.
В-третьих, снижается доверие между функциями.
Начинаются вопросы:
«Почему нас не предупредили?»
«Кто это согласовал?»
«Почему мы узнаём об этом сейчас?»
И наконец, появляется самое опасное последствие — желание защититься.
После ошибки система начала производить бюрократию
Руководство сделало логичный вывод:
такие ситуации нельзя повторять.
Поэтому решили усилить коммуникацию.
Все изменения теперь фиксируются письмом.
Потом появился обязательный протокол.
Затем согласование у нескольких руководителей.
Потом дополнительная встреча перед каждым изменением.
То есть исходная проблема была в отсутствии понятного механизма синхронизации.
Но вместо него возник дополнительный слой контроля.
Количество сообщений выросло.
Количество согласований выросло.
Проектная коммуникация стала тяжелее.
Ирония в том, что информации стало больше, а понимания не обязательно стало больше.
Информация и коммуникация — не одно и то же
Это принципиальный момент.
Можно отправить письмо двадцати людям и не обеспечить коммуникацию.
Можно провести часовую встречу и не создать общего понимания.
Можно написать подробный протокол, который никто не прочитает.
Коммуникация состоялась не тогда, когда информация была отправлена.
А тогда, когда у участников сформировалось общее понимание того, что изменилось и что теперь нужно делать иначе.
В Agile-подходах именно shared understanding — общее понимание — рассматривается как отдельная важная способность команды, а физические и культурные барьеры коммуникации напрямую влияют на проектный результат. Agile манифест
Проблема оказалась не в людях, а в архитектуре взаимодействия
После разбора стало понятно, что команда не была безответственной.
Никто специально не скрывал информацию.
Просто система не отвечала на несколько базовых вопросов.
Где находится единственная актуальная версия решения?
Кто отвечает за фиксацию изменения?
Кто должен подтвердить, что зависимые команды его поняли?
Какие изменения требуют обязательной синхронизации?
Когда новая версия начинает считаться рабочей?
Без этих правил коммуникация существовала как социальная договорённость.
Кто-то написал в чат.
Кто-то сказал на встрече.
Кто-то переслал письмо.
Пока проект был простым, этого хватало.
Когда количество участников и зависимостей выросло, неформальная модель перестала масштабироваться.
После этого изменили сам процесс коммуникации
Вместо того чтобы увеличивать количество сообщений, ввели несколько простых правил.
Появилось одно место с актуальной версией решения.
Каждое существенное изменение получало владельца.
Владелец отвечал не только за фиксацию, но и за синхронизацию зависимых команд.
На общей встрече обсуждались не все новости подряд, а только изменения, влияющие на другие функции.
И главное — после коммуникации проверялось не то, что сообщение отправлено.
Проверялось, что участники одинаково понимают последствия изменения.
Это сильно поменяло качество взаимодействия.
Хорошая коммуникация сокращает количество коммуникации
Это ещё один парадокс.
Когда система коммуникации слабая, сообщений много.
Уточнения.
Переписки.
Повторные встречи.
Эскалации.
Пересылки.
Попытки восстановить историю решений.
Когда система сильная, общения часто становится меньше.
Потому что понятно:
где смотреть;
кому писать;
кто принимает решение;
какая версия актуальна;
кто должен быть уведомлён.
Информационный поток становится короче.
Именно поэтому PMBOK уделяет внимание не только самой информации, но и её движению между уровнями системы: обратная связь должна обеспечивать адаптацию, согласование и своевременную корректировку работы. PMBOK7
Плохая коммуникация почти всегда создаёт скрытые потери
Их трудно увидеть в одном отчёте.
Но они накапливаются.
Переделки.
Повторные встречи.
Ожидание ответа.
Неправильные решения.
Работа по устаревшим вводным.
Конфликты.
Потеря времени на выяснение истории.
Дополнительные согласования, которые потом вводятся «на всякий случай».
Именно поэтому коммуникацию неправильно считать мягким управленческим навыком.
В сложной организации это часть операционной архитектуры.
Она напрямую влияет на скорость, стоимость и качество результата.
Самая дорогая фраза в проекте
Есть одна фраза, которая почти всегда должна настораживать:
«Я думал, что все об этом знают».
Она означает, что система передачи информации основывалась на предположении.
А предположение в проекте — это скрытый риск.
Особенно когда несколько команд зависят друг от друга.
Поэтому сильная коммуникация строится не вокруг количества сообщений.
Она строится вокруг качества общего понимания.
Кто что знает.
Что изменилось.
Что это меняет.
Кто должен действовать.
И где находится актуальная информация.
Главный вывод
Цена плохой коммуникации — это не стоимость одного неправильно понятого письма.
Это стоимость всех решений, которые были приняты после него на неправильной основе.
Чем сложнее организация, тем сильнее эффект.
Одна небольшая несогласованность может пройти через несколько команд, породить переделки, задержки, конфликты и новые бюрократические механизмы.
Поэтому зрелая коммуникация — это не «говорить больше».
Это проектировать информационный поток так, чтобы участники системы принимали решения на основе одной и той же реальности.
И чем лучше это спроектировано, тем меньше организации приходится платить за недоговорённости.
Данный материал носит исключительно ознакомительный и дискуссионный характер и отражает личное мнение автора.
