Что больше злит: когда перенаправляют от одного к коллеги к другому и все равно не получаешь информацию, или когда постоянно меняются бизнес-требования? Мой текст посвящен работе над проектом в корпорации, вернее, решению главной ее сложности — коммуникации.
В статье делюсь опытом, как я выстроила процессы в компании, привожу чек-лист агента изменений, 5 действенных инструментов и шаблоны документов. А еще рассказываю о результатах: как системное выстраивание коммуникации сделали бизнес-процессы эффективнее.
Меня зовут Мария Болдырева — я руководитель проектов в IT-компании Outlines Tech. В профессии 3,5 года, сейчас развиваю финтех-направления корпораций. Всего в управлении командами 6 лет.
Парадокс крутящейся двери
Когда я начала работать над проектами в корпорации, в моей идеальной картине мире все выглядело так, будто здесь все давно отлажено, на любой вопрос существует матрица компетенций, ответственный и страничка в Confluence. Стартапы, которые я развивала до этого, представлялись полными дикого первобытного хаоса с изредка пробегающими мимо кричащими разработчиками.
С точки зрения ресурсов и полноты команды все стало действительно кратно лучше, чем в стартапе. Аналитики не дрались за одну миску риса. Зато я столкнулась с другой проблемой: коммуникация. Нет, даже не так: КОММУНИКАЦИЯ.
На встречах члены команды могли час выяснять, на кого и куда надо эскалировать, кто за что отвечает, в какие сроки может быть решена проблема. Когда мне самой требовалось узнать детали или задать вопрос, я сталкивалась с явлением, которое назвала парадоксом крутящейся двери.
Иногда мне казалось, что я застряла при входе в офисное здание, меня крутит дверь, периодически бьет по лицу и рукам, а я никак не могу выйти. Выражалось это в том, что меня по кругу отправляли к разным специалистам, у которых не было ответа на мой вопрос. Нередко цепочка замыкалась и я возвращалась к исходному сотруднику.
Тогда я впервые задумалась о необходимости изменений, как минимум внедрения матрицы коммуникаций, и, конечно, пошла уточнять наличие таковой. Не скажу, что ее не было совсем: в некоторых командах она была, в некоторых — нет, в отдельных случаях помогала адресная книга со структурой подразделения. Уже позже, обсуждая новую позицию в сообществе, я сделала выводы, что в огромной структуре самоуправление происходит стихийно и требует системного подхода. Отдельной болью и сюрпризом для меня стала тяга к локальным копиям документов и отчетов: сущности множились, вызывая проблемы с версионированием, данные начинали расходиться и вынуждали организовывать все новые и новые встречи.
Всего я выделяю 5 симптомов, которые указывают на необходимость в изменениях:
Длительность согласований
Часто меняющиеся бизнес-требования
Сорванные сроки сдачи поставки
Отсутствие четко очерченных зон ответственности
Отсутствие единого канала коммуникации
Чек-лист агента изменений
Если есть симптомы, то и нужен план, как внедрять перемены. Я придерживаюсь чек-листа, который составила на основе своего опыта:
0. Запаситесь терпением
Изменения не происходят быстро: процесс занимает спринт, два, а может длиться целый квартал.
1. Изучите процесс поставки ценности в вашей команде/отделе
Особенно это актуально, если видите несколько команд, которые находятся на разном уровне процессной зрелости.
2. Подготовьте артефакты и регламенты, которые помогут вам улучшить текущий процесс поставки
3. Внедряйте изменения сверху вниз
Знаю хороший кейс от коллеги, когда компания пыталась пересадить сотрудников на использование нового корпоративного чата. При этом руководители продолжали писать в WhatsApp. Такое внедрение абсолютно бесполезное. Это все равно, что плавать на яхте и требовать от подчиненных использовать для хода по морю автобус.
4. Опишите процесс внедрения изменений с вехами, инструментами и методами, а затем утвердите его с руководством
5. Действуйте итерационно
Любые попытки насильственного внедрения не дадут вам желаемого результата (см. пункт 0).
Сложно прыгнуть с нуля до идеального результата. Скорее всего, будут ошибки, где-то вы поймёте избыточность или недостаток инструментария. После каждой итерации полезно проводить ретро с командами или самостоятельно.
7 сложностей агента-изменений
Из-за специфики работы с большим количеством очень разных команд вылечить боли нахрапом не удалось. Мой изначальный план с ровными табличками и использованием проектных пространств в Confluence разбился, столкнувшись со сложившейся иерархической структурой и человеческими привычками.
Если подытожить, я столкнулась с 7 сложностями. Думаю, с ними встречаются все агенты изменений:
Человеческий фактор сопротивления переменам
Я в очередной раз убедилась, как много для нас значит то, к чему мы уже привыкли: чем дольше существует текущая форма, тем сложнее «продать» изменения. Это относится не только к коммуникации, но к любым переменам.Отсутствие однородного AS IS в разных командах
Отсутствие консистентного источника информации для всех участников поставки
Частая смена ответственных
Отсутствие системного процесса документации
Отсутствие регламентов проведения встреч
Отсутствие фасилитатора встреч
Какие инструменты помогли улучшить коммуникацию
Внедрение проходило в несколько этапов. Первыми версиями стали матрицы для собственного использования, в которых я фиксировала ответственных за проект или направление и кратко описывала зону ответственности.
Пройдя несколько итераций в работе с матрицей, я поменяла подход и начала использовать метод прогрессивного джипега: набрасывала крупными мазками ответственных за продукты или стримы и по мере необходимости детализировала направления, с которыми работала чаще всего.
С картой эскалаций проблем почти не возникло, поскольку зафиксированные по методу джипега ответственные и являлись теми, на кого чаще всего приходилось эскалировать вопросы.
Триггер необходимости внедрения |
Инструмент |
Возможные проблемы при внедрении |
|
Затянутые встречи без фасилитации «Обнуление» участников после встречи |
Follow up/agenda |
Сопротивление изменениям |
|
Отсутствие прозрачности в ответственных Отсутствие единого канала коммуникации для всех участников процесса Долгое уточнение требований |
Матрица коммуникаций |
Непрозрачность процессов в компании, отсутствие регламентов взаимодействия между отделами |
|
Длительный процесс согласования Незамкнутая петля обратной связи с руководством |
Карта эскалаций |
Нехватка административного ресурса Потенциальный конфликт интересов между участниками поставки ценности |
|
Отсутствие requirements freeze Некачественный сбор бизнес-требований Состав поставки отличается от изначального заказа стейкхолдера |
Шаблон для сбора бизнес-требований |
Отсутствие достаточного уровня квалификации стейкхолдера Отсутствие в компании аналитического отдела Отсутствие времени/желания у стейкхолдеров вовлекаться в процесс формирования бизнес-требований Отсутствие приоритетов у бизнес-направлений или конфликт интересов в группе стейкхолдеров одинакового уровня |
|
Отсутствие прозрачности в процессе поставки для стейкхолдера Падение уровня управления ожиданиями заказчика Особые условия ТЭО Начальные стадии внедрения изменениями |
Дайджест релиза/разработки |
Нежелание участников процесса изучать артефакты и быть в едином инфополе Артефакты могут быть использованы с целью давления на команду В зависимости от сложности проекта может понадобиться помощь технического писателя или аналитика |
Здесь оставлю ссылки на шаблоны документов, которые я использую в работе. Переходите и сохраняйте себе.
Итоги работы
Чем проще всего измерять эффективность коммуникаций? Конечно же, эффективностью бизнес-процессов, которые они пронизывают. В основном удалось повлиять именно на производственные метрики команды.
Коммуникации должны быть четко регламентированы. Если артефакты и порядок взаимодействия между командами/сотрудниками/стейкхолдерами не утверждены руководством — процесс не будет работать.
В заключение отмечу, что процесс внедрения был не без приключений, ведь как мы выяснили выше — люди не любят новое и со скрипом вырабатывают новые привычки. Однако мое упорство, помощь руководства и несколько сознательных коллег вывели коммуникации ИТ и бизнеса на новый уровень.
А как вы внедряете изменения в компании? Интересно узнать о разном опыте и лайфхаках.
Комментарии (22)
LegatusSeraphim
27.12.2023 05:56+1Системный подход к управлению коммуникациями - большая редкость в компаниях. Очень часто все носит формальный характер и не несет никакого смысла. На одном из проектов (да что тут говорить, на большинстве из них) у меня не было follow-up. Компания использовала протоколы, называя их "минутками". Это по сути были стенограммы встреч, которые готовили администраторы проекта. В них не было никакой фиксации решений, ответственных или сроков. К чему эта история? А к тому что в большинстве компаний коммуникаций ради коммуникаций. Нет в конце ответственности, сроков и задач.
Отвечая на твой вопрос в конце статьи - все изменения, которые я в итоге смог внести зашли только через руководство. Сверху вниз. И то дайджест релиза, который я ввел в итоге неоднократно пытались использовать против нас.
Ну и стандартное напутствие для всех кто отлаживает процессы поставки ценности или настраивает коммуникации - терпения.
Anatol2007
27.12.2023 05:56Всегда дико раздражали такие форматы встреч, даже со стенограммами, но когда нет ответов на вопросы что/кто/когда. В духе мэрфологии "В совещаниях экономятся минуты, но теряются часы". Ну или более русское -ППР (расшифровывать аббревиатуру не буду, ибо матом).
Касательно коммуникаций между подразделениями приводящих к коммуникациям ради коммуникаций заметил масштабируемость от размера компании, были не редки случаи, когда весь день прошёл во встречах по разным проектам/процессам/проблемам и к вечеру с ужасом обнаруживаешь, что поработать (сделать что то полезного) за сегодня и не успел.Про фасилитацию встреч бесспорно важно написано, но порой для адекватного времени/результатов встречи (в т.ч. и с follow-up) достаточно модератора, к которому прислушиваются участники (не "секретарь")
WonderMary Автор
27.12.2023 05:56Вы совершенно правы. Особенно «дни встреч» раздражают аналитиков, разработчиков и других специалистов, которые непосредственно претворяют в жизнь фичи, доработки и проекты. Для эффективности, как и говорила выше, недостаточно взять инструменты (например админа), у фасилитатора должен быть навык и авторитет, ну или умение этот авторитет наработать.
WonderMary Автор
27.12.2023 05:56К сожалению, из моего опыта, это болезнь больших компаний. Когда не нужно выживать каждую секунду, люди расслабляются и получается хаос, из которого плодятся бесконечные встречи. Тут хорошо работает «главный продуктовый вопрос» — чтобы что?
Встреча? Чтобы что?
Минутки? Чтобы что?
И так далее. Помогает держать фокус и не растекаться мыслью по древуLegatusSeraphim
27.12.2023 05:56Да. На новом месте работе задаю регулярно этот вопрос. Потому что 75 вопросов на обсуждение в регулярном синке - это явно что-то не то. Либо с процессом поставки, либо с продуктом.
Neom1an
27.12.2023 05:56Мы тоже столкнулись с тем, что наши открытые письменные коммуникации могут быть использованы и используются против нас. Уроки вынесли: пишем аккуратнее
LegatusSeraphim
27.12.2023 05:56Поэтому я фиксировал их через самого главного стейкхолдера. Чтобы потом вообще не было вопросов. Плюс это все делается через официальный канал коммуникаций. Только почта, только хардкор. Все остальное приводит к тому, что вас и ваши артефакты крутят без какого-либо положительного результата.
Neom1an
27.12.2023 05:56Да и нельзя не согласится с автором статьи, что если высокий менеджмент на твоей стороне, то перемены внедрить гораздо легче. Если высокому менеджменту не до этого, то перемен и не будет.
А что касается главного стейкхолдера, то тут я с вами согласен: он должен увидеть коммуникацию раньше, чем ему кто-то кроме вас принесет со своими комментариями и намерениями. В этом и была наша основная ошибка - рассылали по привычке компаний, где раньше работали (с более интересной культурой) открыто всем. Оказалось, что в этой компании это повод забурлить и начать копать друг под друга. Теперь с главными стейхолдерами отдельно общаемся до выпуска коммуникаций
Neom1an
27.12.2023 05:56Мы идем следующим путем. Внутри нашей команды создаем культуру работы (и как ее часть, культуру общения) по нашему мнению положительно отличающуюся от текущего состояния культуры всей компании. Наша команда может себе такое позволить - мы функционально достаточно независимы от остальной среды. Одна из наших целей: работать настолько эффективно и приятно, что мы могли бы стать ролевой моделью для других команд и подразделений. И получается. Адекватные менеджеры и сотрудники начинают приходить к нам с запросом: «мы хотим также хорошо, как у вас. Расскажите, как и что вы сделали». Пытаемся создать центр кристаллизации, чтобы из него вырос хороший дельный кристалл культуры компании. Один из возможных путей
WonderMary Автор
27.12.2023 05:56+1Это хорошая практика, делиться опытом важно как для роста внутри, так и снаружи команды. Главное не становиться менеджером-снежинкой, замкнув на себе все практики и знания. Члены команды должны быть равными носителями культуры .
Спасибо, что рассказали о своем опыте работы
msolovyev
27.12.2023 05:56Что вы закладываете в понятие requirements freeze? на какой срок предполагаете морозить требования? По мне это совсем не работает и было отвергнуто еще лет 15 назад
LegatusSeraphim
27.12.2023 05:56Полагаю тут речь о финальной фиксации требований перед стартом разработки.
WonderMary Автор
27.12.2023 05:56Спасибо за вопросы. Отвечу по порядку:
- Requirements freeze - это фиксация требований, необходимая для того, чтобы результат разработки не расходился с ожиданиями заказчика.
- На какой срок предполагаете морозить требования - минимум на срок одной итерации.
Поделитесь, почему считаете, что это не работает? Интересно узнать ваш опыт
M1straL
27.12.2023 05:56Простите, автор, но читая статью с заголовком "Как решить проблему?" я жду в самой статье ответ на этот вопрос. У вас же получилось описать проблему, симптомы и инструменты, проведу аналогию: "если болит голова - принимайте таблетки". А какие именно надо принимать таблетки вы не рассказали, но зато в конце подчеркнули как хорошо и умело "вылечили голову".
Batalmv
27.12.2023 05:56+2Прочитал статью и малось не понял
В заголовке озвучена проблема с коммуникацией. Я даже скопирую, чтобы убедиться в том, что у меня все ОК с глазами :)
Коллеги, а кто за что отвечает? Как наладить коммуникацию, чтобы сдавать проекты в срок без лишнего раздражения
В самой статье ... смешались в кучу кони, люди, телеги, рыба, сено ....
При этом в самом начале самокритично написано "В статье делюсь опытом, как я выстроила процессы в компании" будучи в должности "руководитель проектов" :) Тут можно только порадоваться за корпорацию, в которой ПМ может ее "выстроить" сверху донизу и реализовать такую задачу.
Хотя, боюсь ошибиться, но судя по статья, проблема с коммуникацией началась с "головы"
--------------------------
Начнем з базового. У ПМа всегда есть:
спонсор - тот, кто дает деньги и кому ты репортишь
продакт - тот, кто отвечает за продукт, который должен получиться в результате проекта
тим лиды - те кто рулят командами внутри
всякие "согласователи" и "запрещалы"
прочие
Вроде как первые три группы понять несложно, что делать с остальными?
--------------------------
Во-первых - есть организационный справочник. Там помимо телефонов, позиции и прочего можно понять, кто кому линейный руководитель. И соответственно на кого эскалировать. Вроде просто и тривиально, не?
Во-вторых - есть делегирование. К примеру, не ясно кто еще должен ссогласовать требования. неожиданный простой рецепт. Берем за "жабры" продакта и делегеруем ему эту чудную задачу, так как (сюрприз) именно он отвечает за продукт. Можно ходить с ним и помогать ему (а также иногда брать с собой кого-то из команды), но помнить что означает слово "делегирование". Это его задача получить согласования
-----------------
Теперь тактические методы:
Можно интересоваться опытом коллег. Да, они делали другие проекты, но база в виде коммуникации осталась. Это несложно, надо пойти и банально спросить. Можно записать опыт. Людям вообще нравится, когда с ними советуются. Применяйте почаще
"Гюльчатай" - или любимая жена. Применяется, если есть "мутное" подразделение, которое внутри себя все время вас куда-то пинает. Тогда идем к руководителю и просто объявляем ему, что он теперь моя "Гюльчатай" по таким вот вопросам. Либо пусть дает кого-то вместо себя. Это очень упрощает матрицу коммуникации. Если "Глючатай" не справляется - берем "ее" за ручку к начальнику и поясняем, что либо она будет справляться, либо все таки отдуваться будет начальник. Да, иногда надо быть в курсе "политических" нюансов, но в целом, если не борзеть больше возможного - отлично работает
Если начинается пинание между подразделениями - собирается кол/встреча. Тут уже надо реально посидеть и написать список вопросов, чтобы идти четко по ним и никуда не сворачивать. Если на встрече "балаган" - идет на курсы по управлению встречами, там расскажут. И всегда помним о предыдущем методе
ПМ - не эксперт. Вот просто надо себе написать на лбу и жить с этим. Задача ПМа - работать с людьми, но не пытаться их заменить. Это ключевое. Мне вот стало интересно, с каким вообще вопросом ПМа может быть "пущен" по кругу? Вот просто пример?
Ну и в целом. Задача ПМа - работа с людьми. Если у вас проблемы с коммуникацией - 99.99% проблема в вас, так как коммуникация - это всегда две стороны. И не бывает, что вокруг все тридварасы, а вы - д'Артаньян.
WonderMary Автор
27.12.2023 05:56@Batalmvвы преследуете цель поделиться своим опытом или выразить недовольство? Если ваша цель — обмен опытом, то я готова пообщаться, если же вы хотели “указать на недостатки статьи”, то все, что я могу сделать — поблагодарить вас за потраченное время :)
Batalmv
27.12.2023 05:56Что ж вы так остро реагируете? :)
Ну смотрите. Недовольство - ну как можно? Я ж не издатель, денег не платил, статью не заказывал. С чего мне быть недовольным?
Обмен опытом - ну я как бы поделился, мне не жалко. Хотите что-то обсудить подробно - да не вопрос :)
donlocura
27.12.2023 05:56Чет независимо от организации и уровня хаоса в ней любой вопрос решался в 1-3 итерации - смотрю, к какому отделу относится данный проект, нахожу там рандомного коллегу (желательно того, с кем уже хотя бы знаком), спрашиваю у него, кто может подсказать по этому вопросу. Но никогда ПМом не был - всего лишь скромный разраб. Но теперь я знаю, что с таким сосредоточенным видом целыми днями делают менеджеры - рисуют таблички)
WonderMary Автор
27.12.2023 05:56Из моего опыта, это не всегда работает. Замечательно, что вам повезло больше)
ozzyBLR
В любых процессах важно не перемудрить, не закрутить эти самые гайки до скрипа. И уж тем более это важно в коммуникации, т.к. это софт скилл и прежде всего про людей. Одно дело, когда кто-то "приносит" тебе шаблоны хард скиллов, например, по написанию кода, другое дело, когда кто-то начинает учить тебя общаться. "Я что, не умею ОБЩАТЬСЯ? Да я всю жизнь общаюсь!" - это частая реакция)
Из полезных советов я докину два момента. Первый касается собственно агентов изменений, будь то один человек или команда. Начинать надо с себя. Простая истина, но стОящая упоминания. Предлагаешь всем писать фоллоу-апы? Начни это делать первым, может даже ещё до внедрения во всей компании. Топишь за шаблоны? Составь их для своей команды и показывай своим как реальный образец, а не что-то из книжек. Ты не будешь выглядеть как сапожник без сапог.
Второй момент касается того, что как правило к моменту начала внедрения изменений есть некий накопленный негатив. Часто он мешает изменениям, хотя направлен не против них - это всё против текущих порядков. Именно поэтому полезно описывать состояние AS IS. А ещё полезно провести некую разрядку. Будь то толковая ретроспектива или тимбилдинг.
WonderMary Автор
Это правда, если сам не делаешь, никто делать не будет. Как и с другими софтами, коммуникация – сложная штука, и оттачивать ее нужно всю жизнь.
Спасибо за комментарий, думаю, я продолжу рассказывать о софтах в разрезе работы менеджера.