Comments 23
В любых процессах важно не перемудрить, не закрутить эти самые гайки до скрипа. И уж тем более это важно в коммуникации, т.к. это софт скилл и прежде всего про людей. Одно дело, когда кто-то "приносит" тебе шаблоны хард скиллов, например, по написанию кода, другое дело, когда кто-то начинает учить тебя общаться. "Я что, не умею ОБЩАТЬСЯ? Да я всю жизнь общаюсь!" - это частая реакция)
Из полезных советов я докину два момента. Первый касается собственно агентов изменений, будь то один человек или команда. Начинать надо с себя. Простая истина, но стОящая упоминания. Предлагаешь всем писать фоллоу-апы? Начни это делать первым, может даже ещё до внедрения во всей компании. Топишь за шаблоны? Составь их для своей команды и показывай своим как реальный образец, а не что-то из книжек. Ты не будешь выглядеть как сапожник без сапог.
Второй момент касается того, что как правило к моменту начала внедрения изменений есть некий накопленный негатив. Часто он мешает изменениям, хотя направлен не против них - это всё против текущих порядков. Именно поэтому полезно описывать состояние AS IS. А ещё полезно провести некую разрядку. Будь то толковая ретроспектива или тимбилдинг.
Системный подход к управлению коммуникациями - большая редкость в компаниях. Очень часто все носит формальный характер и не несет никакого смысла. На одном из проектов (да что тут говорить, на большинстве из них) у меня не было follow-up. Компания использовала протоколы, называя их "минутками". Это по сути были стенограммы встреч, которые готовили администраторы проекта. В них не было никакой фиксации решений, ответственных или сроков. К чему эта история? А к тому что в большинстве компаний коммуникаций ради коммуникаций. Нет в конце ответственности, сроков и задач.
Отвечая на твой вопрос в конце статьи - все изменения, которые я в итоге смог внести зашли только через руководство. Сверху вниз. И то дайджест релиза, который я ввел в итоге неоднократно пытались использовать против нас.
Ну и стандартное напутствие для всех кто отлаживает процессы поставки ценности или настраивает коммуникации - терпения.
Всегда дико раздражали такие форматы встреч, даже со стенограммами, но когда нет ответов на вопросы что/кто/когда. В духе мэрфологии "В совещаниях экономятся минуты, но теряются часы". Ну или более русское -ППР (расшифровывать аббревиатуру не буду, ибо матом).
Касательно коммуникаций между подразделениями приводящих к коммуникациям ради коммуникаций заметил масштабируемость от размера компании, были не редки случаи, когда весь день прошёл во встречах по разным проектам/процессам/проблемам и к вечеру с ужасом обнаруживаешь, что поработать (сделать что то полезного) за сегодня и не успел.
Про фасилитацию встреч бесспорно важно написано, но порой для адекватного времени/результатов встречи (в т.ч. и с follow-up) достаточно модератора, к которому прислушиваются участники (не "секретарь")
Вы совершенно правы. Особенно «дни встреч» раздражают аналитиков, разработчиков и других специалистов, которые непосредственно претворяют в жизнь фичи, доработки и проекты. Для эффективности, как и говорила выше, недостаточно взять инструменты (например админа), у фасилитатора должен быть навык и авторитет, ну или умение этот авторитет наработать.
К сожалению, из моего опыта, это болезнь больших компаний. Когда не нужно выживать каждую секунду, люди расслабляются и получается хаос, из которого плодятся бесконечные встречи. Тут хорошо работает «главный продуктовый вопрос» — чтобы что?
Встреча? Чтобы что?
Минутки? Чтобы что?
И так далее. Помогает держать фокус и не растекаться мыслью по древу
Мы тоже столкнулись с тем, что наши открытые письменные коммуникации могут быть использованы и используются против нас. Уроки вынесли: пишем аккуратнее
Поэтому я фиксировал их через самого главного стейкхолдера. Чтобы потом вообще не было вопросов. Плюс это все делается через официальный канал коммуникаций. Только почта, только хардкор. Все остальное приводит к тому, что вас и ваши артефакты крутят без какого-либо положительного результата.
Да и нельзя не согласится с автором статьи, что если высокий менеджмент на твоей стороне, то перемены внедрить гораздо легче. Если высокому менеджменту не до этого, то перемен и не будет.
А что касается главного стейкхолдера, то тут я с вами согласен: он должен увидеть коммуникацию раньше, чем ему кто-то кроме вас принесет со своими комментариями и намерениями. В этом и была наша основная ошибка - рассылали по привычке компаний, где раньше работали (с более интересной культурой) открыто всем. Оказалось, что в этой компании это повод забурлить и начать копать друг под друга. Теперь с главными стейхолдерами отдельно общаемся до выпуска коммуникаций
Мы идем следующим путем. Внутри нашей команды создаем культуру работы (и как ее часть, культуру общения) по нашему мнению положительно отличающуюся от текущего состояния культуры всей компании. Наша команда может себе такое позволить - мы функционально достаточно независимы от остальной среды. Одна из наших целей: работать настолько эффективно и приятно, что мы могли бы стать ролевой моделью для других команд и подразделений. И получается. Адекватные менеджеры и сотрудники начинают приходить к нам с запросом: «мы хотим также хорошо, как у вас. Расскажите, как и что вы сделали». Пытаемся создать центр кристаллизации, чтобы из него вырос хороший дельный кристалл культуры компании. Один из возможных путей
Что вы закладываете в понятие requirements freeze? на какой срок предполагаете морозить требования? По мне это совсем не работает и было отвергнуто еще лет 15 назад
Полагаю тут речь о финальной фиксации требований перед стартом разработки.
Спасибо за вопросы. Отвечу по порядку:
- Requirements freeze - это фиксация требований, необходимая для того, чтобы результат разработки не расходился с ожиданиями заказчика.
- На какой срок предполагаете морозить требования - минимум на срок одной итерации.
Поделитесь, почему считаете, что это не работает? Интересно узнать ваш опыт
Простите, автор, но читая статью с заголовком "Как решить проблему?" я жду в самой статье ответ на этот вопрос. У вас же получилось описать проблему, симптомы и инструменты, проведу аналогию: "если болит голова - принимайте таблетки". А какие именно надо принимать таблетки вы не рассказали, но зато в конце подчеркнули как хорошо и умело "вылечили голову".
Прочитал статью и малось не понял
В заголовке озвучена проблема с коммуникацией. Я даже скопирую, чтобы убедиться в том, что у меня все ОК с глазами :)
Коллеги, а кто за что отвечает? Как наладить коммуникацию, чтобы сдавать проекты в срок без лишнего раздражения
В самой статье ... смешались в кучу кони, люди, телеги, рыба, сено ....
При этом в самом начале самокритично написано "В статье делюсь опытом, как я выстроила процессы в компании" будучи в должности "руководитель проектов" :) Тут можно только порадоваться за корпорацию, в которой ПМ может ее "выстроить" сверху донизу и реализовать такую задачу.
Хотя, боюсь ошибиться, но судя по статья, проблема с коммуникацией началась с "головы"
--------------------------
Начнем з базового. У ПМа всегда есть:
спонсор - тот, кто дает деньги и кому ты репортишь
продакт - тот, кто отвечает за продукт, который должен получиться в результате проекта
тим лиды - те кто рулят командами внутри
всякие "согласователи" и "запрещалы"
прочие
Вроде как первые три группы понять несложно, что делать с остальными?
--------------------------
Во-первых - есть организационный справочник. Там помимо телефонов, позиции и прочего можно понять, кто кому линейный руководитель. И соответственно на кого эскалировать. Вроде просто и тривиально, не?
Во-вторых - есть делегирование. К примеру, не ясно кто еще должен ссогласовать требования. неожиданный простой рецепт. Берем за "жабры" продакта и делегеруем ему эту чудную задачу, так как (сюрприз) именно он отвечает за продукт. Можно ходить с ним и помогать ему (а также иногда брать с собой кого-то из команды), но помнить что означает слово "делегирование". Это его задача получить согласования
-----------------
Теперь тактические методы:
Можно интересоваться опытом коллег. Да, они делали другие проекты, но база в виде коммуникации осталась. Это несложно, надо пойти и банально спросить. Можно записать опыт. Людям вообще нравится, когда с ними советуются. Применяйте почаще
"Гюльчатай" - или любимая жена. Применяется, если есть "мутное" подразделение, которое внутри себя все время вас куда-то пинает. Тогда идем к руководителю и просто объявляем ему, что он теперь моя "Гюльчатай" по таким вот вопросам. Либо пусть дает кого-то вместо себя. Это очень упрощает матрицу коммуникации. Если "Глючатай" не справляется - берем "ее" за ручку к начальнику и поясняем, что либо она будет справляться, либо все таки отдуваться будет начальник. Да, иногда надо быть в курсе "политических" нюансов, но в целом, если не борзеть больше возможного - отлично работает
Если начинается пинание между подразделениями - собирается кол/встреча. Тут уже надо реально посидеть и написать список вопросов, чтобы идти четко по ним и никуда не сворачивать. Если на встрече "балаган" - идет на курсы по управлению встречами, там расскажут. И всегда помним о предыдущем методе
ПМ - не эксперт. Вот просто надо себе написать на лбу и жить с этим. Задача ПМа - работать с людьми, но не пытаться их заменить. Это ключевое. Мне вот стало интересно, с каким вообще вопросом ПМа может быть "пущен" по кругу? Вот просто пример?
Ну и в целом. Задача ПМа - работа с людьми. Если у вас проблемы с коммуникацией - 99.99% проблема в вас, так как коммуникация - это всегда две стороны. И не бывает, что вокруг все тридварасы, а вы - д'Артаньян.
@Batalmvвы преследуете цель поделиться своим опытом или выразить недовольство? Если ваша цель — обмен опытом, то я готова пообщаться, если же вы хотели “указать на недостатки статьи”, то все, что я могу сделать — поблагодарить вас за потраченное время :)
В статье действительно смешались люди, кони и ПМ-ы, а тут божественный коммент - структурировано, четко, с опытом.
Из статьи я вынес ничего, из комента сделал себе пару задачек для работы)
Чет независимо от организации и уровня хаоса в ней любой вопрос решался в 1-3 итерации - смотрю, к какому отделу относится данный проект, нахожу там рандомного коллегу (желательно того, с кем уже хотя бы знаком), спрашиваю у него, кто может подсказать по этому вопросу. Но никогда ПМом не был - всего лишь скромный разраб. Но теперь я знаю, что с таким сосредоточенным видом целыми днями делают менеджеры - рисуют таблички)
Коллеги, а кто за что отвечает? Как наладить коммуникацию, чтобы сдавать проекты в срок без лишнего раздражения