Особенности коммуникации на этапе запуска проекта

Недавно ко мне обратился молодой человек, который испытывал трудности в новом проекте.

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

Чтобы объяснить клиенту, что происходит, я придумала такую метафору как «слаживание подразделений перед боем».

— Представьте, что будет, если бросить солдат в бой без подготовки. Именно это происходит сейчас с вашей командой.

— Да, пара человек уже уволились. Потеряли бойцов, получается…

Метафора хорошо ложится на старт проекта, потому что в обоих случаях речь про то, чтобы из отдельных специалистов сделать команду, которая действует синхронно и без взаимных помех.

В бою несогласованность стоит дорого, (цена — человеческие жизни), если кто-то уходит вперёд, кто-то отстаёт и связь теряется. В проекте это выглядит как «я думал, это делает соседний отдел», «мы не синхронизировались по срокам», «у нас разные версии ТЗ».

Как выглядит проектное слаживание по аналогии с военным делом:

  • Индивидуальная подготовка. Каждый специалист должен четко понимать свои роли и функции до того, как начнется проект.
  • Синхронизация целей. Выработка единого понимания общей картины и движение к общему результату.
  • Собственно слаживание. На этом этапе военные отрабатывают сигналы, позывные, порядок докладов, зоны ответственности. В проекте это договорённости между отделами, правила эскалации (регламентированный алгоритм действий для передачи задачи или проблемы на более высокий уровень), формат статусов, шаблоны писем и встреч, критерии «готово».
  • Отработка типовых ситуаций. В армии это «атака», «отход», «огневая поддержка». В проекте это «клиент поменял требования», «сроки горят», «подрядчик не сдал этап», «нужна срочная доработка». Если заранее договориться, кто и как реагирует, команда не рассыпается при первом стрессе.
  • Пробные маневры, или проверка в условиях, близких к реальным. В армии это полигон, ночь, дождь, помехи связи. В проекте — пилот на небольшом участке, тестовая встреча с требовательным клиентом, проверка интеграции систем. Цель здесь не сделать идеально, а выявить проблемы и исправить.

.

Какие инструменты можно использовать:

  • Матрица ролей и ответственности (RACI) + чек-лист передачи этапа. Например, «проектирование → смета»: кто подтверждает готовность, какие документы передаются, кто проверяет, в какие сроки. Это убирает недопонимания и риск ошибок.
  • Сценарий демо для клиента. Кто ведёт, кто показывает визуализацию, кто отвечает за технические детали, кто фиксирует правки. Это снижает риск, что на встрече команда будет «спонтанно импровизировать».
  • Ежедневные «короткие сводки». Не длинные отчёты, а 5 строк: статус, риски, что нужно от смежников, прогноз по срокам, план. Это аналог радиодоклада: коротко, по делу, все слышат одно и то же.
  • Регламент изменений. Любое изменение требований фиксируется письменно, оценивается по времени/стоимости/рискам, утверждается. Это предотвращает «тихие» сдвиги, которые потом ломают весь график.

.

Таким образом, вместо призывов лучше взаимодействовать руководителю проекта стоило провести слаживание команды, чтобы не терять «бойцов», время и деньги. По данным Forbes, российские компании ежегодно теряют около 9 трлн рублей из-за плохо выстроенных коммуникаций между сотрудниками. В эту сумму входят как траты на оплату потраченного впустую рабочего времени, так и потери от сорванных сделок, нездоровой атмосферы в коллективе и внезапных увольнений.