Коллеги, а кто за что отвечает? Как наладить коммуникацию, чтобы сдавать проекты в срок без лишнего раздражения

Что больше злит: когда перенаправляют от одного к коллеги к другому и все равно не получаешь информацию, или когда постоянно меняются бизнес-требования? Мой текст посвящен работе над проектом в корпорации, вернее, решению главной ее сложности — коммуникации.

В статье делюсь опытом, как я выстроила процессы в компании, привожу чек-лист агента изменений, 5 действенных инструментов и шаблоны документов. А еще рассказываю о результатах: как системное выстраивание коммуникации сделали бизнес-процессы эффективнее.

Меня зовут Мария Болдырева — я руководитель проектов в IT-компании Outlines Tech. В профессии 3,5 года, сейчас развиваю финтех-направления корпораций. Всего в управлении командами 6 лет.

Когда я начала работать над проектами в корпорации, в моей идеальной картине мире все выглядело так, будто здесь все давно отлажено, на любой вопрос существует матрица компетенций, ответственный и страничка в Confluence. Стартапы, которые я развивала до этого, представлялись полными дикого первобытного хаоса с изредка пробегающими мимо кричащими разработчиками.

С точки зрения ресурсов и полноты команды все стало действительно кратно лучше, чем в стартапе. Аналитики не дрались за одну миску риса. Зато я столкнулась с другой проблемой: коммуникация. Нет, даже не так: коммуникация.

На встречах члены команды могли час выяснять, на кого и куда надо эскалировать, кто за что отвечает, в какие сроки может быть решена проблема. Когда мне самой требовалось узнать детали или задать вопрос, я сталкивалась с явлением, которое назвала парадоксом крутящейся двери.

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

Уже позже, обсуждая новую позицию в сообществе, я сделала выводы, что в огромной структуре самоуправление происходит стихийно и требует системного подхода. Отдельной болью и сюрпризом для меня стала тяга к локальным копиям документов и отчетов: сущности множились, вызывая проблемы с версионированием, данные начинали расходиться и вынуждали организовывать все новые и новые встречи.

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

Если есть симптомы необходимости изменений, то и нужен план, как внедрять перемены. Я придерживаюсь чек-листа, который составила на основе своего опыта:

0. Запаситесь терпением
Изменения не происходят быстро: процесс занимает спринт, два, а может длиться целый квартал.

1. Изучите процесс поставки ценности в вашей команде/отделе

Особенно это актуально, если видите несколько команд, которые находятся на разном уровне процессной зрелости.

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

3. Внедряйте изменения сверху вниз
Знаю хороший кейс от коллеги, когда компания пыталась пересадить сотрудников на использование нового корпоративного чата. При этом руководители продолжали писать в WhatsApp. Такое внедрение абсолютно бесполезное. Это все равно, что плавать на яхте и требовать от подчиненных использовать для хода по морю автобус.

4. Опишите процесс внедрения изменений с вехами, инструментами и методами, а затем утвердите его с руководством

5. Действуйте итерационно
Любые попытки насильственного внедрения не дадут вам желаемого результата (см. пункт 0).
Сложно прыгнуть с нуля до идеального результата. Скорее всего, будут ошибки, где-то вы поймёте избыточность или недостаток инструментария. После каждой итерации полезно проводить ретро с командами или самостоятельно.

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

Если подытожить, я столкнулась с 7 сложностями. Думаю, с ними встречаются все агенты изменений:

Внедрение проходило в несколько этапов. Первыми версиями стали матрицы для собственного использования, в которых я фиксировала ответственных за проект или направление и кратко описывала зону ответственности.

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

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

Здесь оставлю ссылки на шаблоны документов, которые я использую в работе. Переходите и сохраняйте себе.

Чем проще всего измерять эффективность коммуникаций? Конечно же, эффективностью бизнес-процессов, которые они пронизывают. В основном удалось повлиять именно на производственные метрики команды.

В заключение отмечу, что процесс внедрения был не без приключений, ведь как мы выяснили выше — люди не любят новое и со скрипом вырабатывают новые привычки. Однако мое упорство, помощь руководства и несколько сознательных коллег вывели коммуникации ИТ и бизнеса на новый уровень.

А как вы внедряете изменения в компании? Интересно узнать о разном опыте и лайфхаках.