Меня зовут Влад Самойлов. Последняя компания, в которой я занимал позицию IT portfolio manager, — «Киевстар». В проектном и продуктовом менеджменте на рынках СНГ, Европы, США и Азии я уже более 6 лет. Последние два года активно преподаю IT project management в нескольких школах и центрах IT-образования, а также являюсь тренером по командообразованию.
Случилось как-то мне работать с проектом, в котором было два проджект-менеджера при равноправной управленческой модели. Проект был довольно крупным, слабая матрица в организационной структуре имела плюсы и минусы со своим шеринг-пулом ресурсов. И наверное, одним из самых интересных проектов в моей карьере. Наличие двух проджект-менеджеров в нем, конечно, могло бы принести больше пользы, чем вреда, если бы все то, о чем я пишу в этой статье, мы смогли реализовать в полном объеме и, главное, вовремя. Есть еще ряд assumptions, но они уже второстепенны.
Однако обо всем по порядку.
Имея за спиной довольно разнообразный опыт работы с различными типами команд и будучи как на стороне заказчика, так и на стороне исполнителя, могу с уверенностью сказать, что идеальной формулы управления проектом вдвоем нет. Но успешно показавшие себя методики, инструменты и практики существуют.
Статью на эту тему я решил написать по материалам своего доклада на Project Management Day 2019, в рамках которого мы смогли очень глубоко изучить эту тему и подискутировать с аудиторией, оптимизируя инструменты и подходы для работы с подобными кейсами в будущем.
Цель любой современной IT-конференции сегодня — нетворкинг. За последние 6–7 лет я посетил внушительное количество конференций, чтобы сегодня четко формулировать задачи. Выполнение этих задач поможет мне вынести максимум, будучи спикером или участником. Цели, поставленные на этот год в роли спикера на PM Day, можно считать достигнутыми.
Вопрос «Что самое главное в построении команд?» довольно сложный. Деньги? Мотивация? Высококвалифицированные специалисты? Возможно. Но я для себя вынес иные ценности.
Не бывает стопроцентно успешно реализованных проектов. И один из таких моих кейсов напоминает мне уже несколько лет о важности максимального уровня вовлеченности каждого участника команды в продукт.
Был я в тот момент еще совсем молодым проджект-менеджером, и попался мне в команде человек со слабой заинтересованностью в продукте. Забегая наперед, скажу, что проект был провален, правда, частично, так как удалось выйти в ресурсный ноль. При этом потратив 7 месяцев. Для заказчика это полная неудача. Безусловно, ответственность лежала на проджект-менеджере. Тогда меня подвел слабый интерес к фриланс-проектам этого разработчика, одним из которых оказался заказ от конкурента на смежный с нашим продукт (тут, конечно, ожидаю от вас множество комментариев, что правильно было бы делать и как себя вести). А ведь он даже согласовывал со мной свой гибкий график для возможности ведения своего проекта. Эх, молодость... Ну да ладно, продолжим.
Последняя компания, в которой я очередной раз на практике убеждался в важности не просто создавать продукты, а создавать ценность от этих продуктов, это «Киевстар». Рынок телеком-услуг, конечно, не сильно велик в Украине, но выбрать есть из чего. Поэтому нам в каждой, даже самой мелкой, инициативе приходилось тщательно изучать потребности, боли и желания конечных пользователей, чтобы именно у тебя не возникло желание «попробовать более удобное приложение оператора АВС» или «поставить вторую симку только для инета».
Для более наглядного понимания важности создания ценности можно привести пример возможного распределения бюджета проекта по разработке простейшего API (что позволит пользователю избежать необходимости прохождения дополнительного шага при оплате пакета услуг), которое может составлять 90/10. А именно: 90% затрат бюджета — на маркетинговые исследования, customer success experience, пилотный запуск, А/Б тесты и т. д. и всего 10% — на фактическое выполнение проекта (полный SDLC).
Вы же пользуетесь чем-то конкретным из месяца в месяц не одолжения ради, а потому что для тебя это представляет определенную ценность... Стоит задуматься.
Три самых важных аспекта, понимание которых поможет вам с первого раза успешно построить эффективные процессы менеджмента:
Для аудиторий различных конференций, которые так или иначе относятся к проектному/продуктовому менеджменту, все эти вопросы оказались до боли актуальными, несмотря на то что встречаются представители компаний самых разных масштабов. Способы управления или направления по отношению к командам могут быть разными. Но, говоря о коммуникации, мы каждый раз приходили к выводу, что ею можно только управлять и команда в таком случае становится эффективнее.
Сегодня можно придумывать различные методологии/фреймворки (Waterfall, Agile, Scrum, Kanban, Lean...), инструменты (RACI, WBS, Gantt chart diagram, матрица требований/рисков/стейкхолдеров...), ссылаясь на профессиональные источники (PMI, ScrumAlliance, DOU и др.). Но иногда встречаются кейсы, которые противоречат не только классическим подходам в проектном менеджменте, но и здравому смыслу. Один из них — управление одним проектом при равноправной ролевой модели двух проджект-менеджеров. И даже в этом случае у вас есть все шансы на успех. Не опускаем руки, для начала необходимо разобраться, законно ли это.
Это весьма нетипичная модель, но она часто встречается в современной практике, когда идет этап реструктуризации проекта или его передача от одного к другому PM (ведь этап передачи highload-проекта может достигать 2–3 месяцев, и на протяжении всего этого времени проектом управляют два человека). Очень важно вовремя идентифицировать, что проект начал какую-либо трансформацию, например из проекта в программу или портфель, ведь эти структурные изменения требуют пересмотра ролевой и поведенческой модели в команде, в том числе — количества проджект-менеджеров (возможно, функциональных).
Также наличие двух проджект-менеджеров возможно в мультистримовых проектах, где, кроме направления разработки ПО, есть стримы маркетинга, продаж/логистики и прочее. И в каждом направлении может быть свой менеджер.
Мой любимый кейс, с которым я сам однажды столкнулся на практике, когда на проекте появляются два проджект-менеджера, это вопрос-хотелка заказчика «А давай усилим твой проект?»; хотя фактически это никогда не является вопросом, а скорее: «Я умнее, поэтому решил, что теперь вас двое». И даже если вы использовали все свои хард-, софт- и мегасупер-скилы для ухода от данного «решения», с этим можно эффективно работать. Поговорим детальнее как.
Итак, на очередной встрече с руководителем/клиентом вам озвучивают: «Ты молодец. Но мы решили усилить твой проект, и завтра к тебе присоединяется еще один PM». Вы, конечно, попытались изменить условия игры, вытереть холодный пот. Но что же делать, учитывая, что данного кейса не избежать? Поехали.
Причина. Определите, какой из вышеперечисленных кейсов у вас сложился и по какой причине у вас в проекте добавился второй PM. Ведь трансформация проекта или организационной структуры компании — далеко не единственная причина. Еще одной причиной я бы хотел назвать ваше собственное решение как менеджера проекта. Добавление второго человека не всегда «плохое, притянутое за уши решение». И если вы как менеджер решили вырасти (до Program/Portfolio manager), чтобы тем самым принести пользу проекту, то имеете все инструменты для этого; главное, не забудьте подготовить под такие изменения бюджет.
Проблема/задача. Что именно мы или не мы хотим решить и чего добиться добавлением нового проджект-менеджера в команду.
Результат. А второй действительно сможет решить поставленные задачи или мы пытаемся увеличить скорость автомобиля, прикручивая зеркало заднего вида?
Понять это весьма просто. В большинстве случаев новый PM может помочь с решением задач из области ресурсного перераспределения (проще говоря, примет на себя часть функций в проекте), внедрением внешней экспертизы в реализацию проекта или решение точечных проблематичных кейсов. Формулировка «Мы постоянно проваливаем даты новых релизов, поэтому нам нужен второй PM, чтобы все более качественно заменеджерить» может стать губительной, если, разбирая каждый отдельный случай, выясните, что не в недостатке ресурса проджект-менеджера проблема, а в банально не прописанных Definition of Ready и Definition of Done. Этот пример — не плод неординарной фантазии, а примеры из одного моего проекта. В момент первого знакомства с одним из главных стейкхолдеров проекта я и услышал подобную формулировку. Хорошо, что спустя несколько продолжительных встреч и множество ночей, проведенных в процессе аудита проекта, мне удалось убедить его в том, что тут не решить проблему даже 10 проджект-менеджерами, если не прописать вышеназванные критерии.
Квалификация второго проджект-менеджера. Мы же должны понимать, насколько мощный ресурс попадает к нам в команду. Есть вероятность, что нас просто заставляют поменторить какого-то джуна под таким предлогом.
Проджект-менеджер проджект-менеджеру друг. Просто поговорите с новым PM в неофициальном формате, попробуйте понять его ожидания, поделиться своими, узнать о том, какую пользу он может и хочет принести, и просто банально попытайтеь договориться, как же вам теперь жить вместе.
Допустим, первые шаги вы выполнили и уже даже смогли как-то для себя обстановку очертить. Теперь мы знаем, почему, зачем и кто. Но что же делать дальше и как с этим быть на практике?
На первый взгляд этот инструмент может показаться бюрократизированным. Век agile, а мы тут бумажки по правилам общения внутри команды формируем! Но это абсолютно не так. И тот, кто сталкивался с хаосом в проектах, понимает, что без четких правил взаимодействия и управления коммуникациями эффективное управление невозможно, тем более вдвоем.
Вы только представьте (или вспомните) свои ощущения, когда приходите на проект, в котором 10–50 (неважно сколько) человек, и вам необходимо всем этим как-то управлять. И что еще важнее, управлять, достигая определенной цели.
Согласен, за один день вся эта сложная паутина не распутается, но первое, что вы сделаете, — попытаетесь консолидировать информацию о проекте (мы надеемся, что предыдущий PM использовал конфигурационное управление, но надежды остаются надеждами). Для планомерного сбора данных вам потребуется синхронизировать потоки коммуникаций в проекте между участниками и взять их под контроль. Карта коммуникаций в этом точно поможет.
Многоуровневая RACI-матрица, конечно же, остается инструментом формирования ролевой модели на проекте, но ключевое слово — «многоуровневая», что позволяет нам формировать RACI в нескольких «измерениях». Максимально применима в матричных организационных структурах компаний.
Я для себя вывел два типа многоуровневой RACI-матрицы:
Пример классической карты коммуникаций, которая применима для многочисленных команд; поэтому структурируем карту по функциям, а не по людям и проставляем связи проектного и функционального взаимодействия:
лаконичность, доступность широкому кругу стейкхолдеров, легко вносить динамические изменения, идеально подходит для команд с более, чем 20 участников.
малая информативность о функциональных ролях, не предусматривает детальных кейсовых вариаций, имеет обязательный набор исключений.
Рассмотрим еще один вариант визуализации карты коммуникаций, но теперь уже для немногочисленных команд; и эта карта, в отличие от предыдущей, визуализирует взаимодействие между ролями в команде:
визуально доступна для восприятия, правила понятны без дополнительной презентации/пояснений/комментариев, формат применим в командах до 12–15 человек.
может содержать до 3–4 правил, не учитывает исключительных кейсов, неприменима в матричных структурных организациях.
Альтернативно-креативным вариантом карты коммуникаций может быть и такой формат. Данная карта визуализирует не ролевое взаимодействие, а маршруты коммуникации в команде/организации/группе:
применима для функциональных и матричных организационных структур, описывает любые маршруты и правила, допускает для визуализации любые кейсы.
сложна для визуального восприятия, неприменима для многочисленных команд/организаций/групп, имеет предел масштабирования.
Как вы уже поняли, нет правильного или неправильного формата для визуализации карт коммуникаций, самое главное, чтобы она отвечала своему назначению и команда готова была ею пользоваться. А для этого попробуйте не фантазировать в одиночестве, а создать ее вместе с командой. В моей практике очень хорошо зарекомендовал себя итеративный подход создания подобных карт через командные мозговые штурмы. То есть мы не стремимся создать с помощью одного подхода сразу комплектный инструмент, а дополняем, корректируем и модернизируем его на протяжении какого-то периода, например до окончания фазы инициации/планирования. В исключительных случаях, когда вы на проекте не с самого начала, есть смысл ставить дедлайн самому себе, подвязав его к impact milestone на критическом пути.
Есть и другие возможные варианты поведенческо-ролевых моделей в зависимости от структурного типа компаний, что является основополагающим фактором формирования карты коммуникаций и многоуровневой RACI. В Киеве на Project Management Day 2019 мы успели не только поговорить об этом, но и сформировать несколько детальных моделей.
Также полезно говорить с коллегами и формулировать свои взгляды и гипотезы. Так рождается истина. Надеюсь, я смог принести пользу менеджерам, с которыми поделился этими знаниями. Все вышесказанное я успешно применяю в процессе создания нашего нового продукта Connectable (проект в разработке).
Общение, общение и еще раз общение. И даже управляя командой вдвоем, вы начнете перформить на максимум.
А теперь попробуйте заглянуть за борт...
dou.ua
Случилось как-то мне работать с проектом, в котором было два проджект-менеджера при равноправной управленческой модели. Проект был довольно крупным, слабая матрица в организационной структуре имела плюсы и минусы со своим шеринг-пулом ресурсов. И наверное, одним из самых интересных проектов в моей карьере. Наличие двух проджект-менеджеров в нем, конечно, могло бы принести больше пользы, чем вреда, если бы все то, о чем я пишу в этой статье, мы смогли реализовать в полном объеме и, главное, вовремя. Есть еще ряд assumptions, но они уже второстепенны.
Однако обо всем по порядку.
Имея за спиной довольно разнообразный опыт работы с различными типами команд и будучи как на стороне заказчика, так и на стороне исполнителя, могу с уверенностью сказать, что идеальной формулы управления проектом вдвоем нет. Но успешно показавшие себя методики, инструменты и практики существуют.
Статью на эту тему я решил написать по материалам своего доклада на Project Management Day 2019, в рамках которого мы смогли очень глубоко изучить эту тему и подискутировать с аудиторией, оптимизируя инструменты и подходы для работы с подобными кейсами в будущем.
Цель любой современной IT-конференции сегодня — нетворкинг. За последние 6–7 лет я посетил внушительное количество конференций, чтобы сегодня четко формулировать задачи. Выполнение этих задач поможет мне вынести максимум, будучи спикером или участником. Цели, поставленные на этот год в роли спикера на PM Day, можно считать достигнутыми.
Принципы построения команд
Работая и в маленьких компаниях, и в крупных, каждый день сталкиваешься с непростыми задачами построения команд для создания успешных продуктов. И появляется желание найти ту самую формулу, которая принесет в результате не только идеальную команду, но и идеальный продукт.Вопрос «Что самое главное в построении команд?» довольно сложный. Деньги? Мотивация? Высококвалифицированные специалисты? Возможно. Но я для себя вынес иные ценности.
Продукт
Продукт, который команда создает, — это ее цель, и команда идет к ней каждый день. А как мы знаем, неправильно поставленная цель заведомо провальная. Поэтому продукт, который команда создает, должен делать из группы людей сплоченную общим интересом команду. Если хоть один ее участник не заинтересован в конечном результате, то вашему продукту, как и команде в целом, грозит провал.Не бывает стопроцентно успешно реализованных проектов. И один из таких моих кейсов напоминает мне уже несколько лет о важности максимального уровня вовлеченности каждого участника команды в продукт.
Был я в тот момент еще совсем молодым проджект-менеджером, и попался мне в команде человек со слабой заинтересованностью в продукте. Забегая наперед, скажу, что проект был провален, правда, частично, так как удалось выйти в ресурсный ноль. При этом потратив 7 месяцев. Для заказчика это полная неудача. Безусловно, ответственность лежала на проджект-менеджере. Тогда меня подвел слабый интерес к фриланс-проектам этого разработчика, одним из которых оказался заказ от конкурента на смежный с нашим продукт (тут, конечно, ожидаю от вас множество комментариев, что правильно было бы делать и как себя вести). А ведь он даже согласовывал со мной свой гибкий график для возможности ведения своего проекта. Эх, молодость... Ну да ладно, продолжим.
Для кого и зачем
Продукт востребован только тогда, когда вы понимаете еще на самом раннем этапе, для кого и зачем он создается. Не для заказчика/инвестора/компании, в которой работаете, а для тех конечных потребителей, которые будут платить за ваш продукт деньги. Платить снова и снова, возвращаясь за продуктом, осознавая его ценность.Последняя компания, в которой я очередной раз на практике убеждался в важности не просто создавать продукты, а создавать ценность от этих продуктов, это «Киевстар». Рынок телеком-услуг, конечно, не сильно велик в Украине, но выбрать есть из чего. Поэтому нам в каждой, даже самой мелкой, инициативе приходилось тщательно изучать потребности, боли и желания конечных пользователей, чтобы именно у тебя не возникло желание «попробовать более удобное приложение оператора АВС» или «поставить вторую симку только для инета».
Для более наглядного понимания важности создания ценности можно привести пример возможного распределения бюджета проекта по разработке простейшего API (что позволит пользователю избежать необходимости прохождения дополнительного шага при оплате пакета услуг), которое может составлять 90/10. А именно: 90% затрат бюджета — на маркетинговые исследования, customer success experience, пилотный запуск, А/Б тесты и т. д. и всего 10% — на фактическое выполнение проекта (полный SDLC).
Вы же пользуетесь чем-то конкретным из месяца в месяц не одолжения ради, а потому что для тебя это представляет определенную ценность... Стоит задуматься.
Понимание, кем вы управляете
Команда — это что такое? Какой тип команды формируется у вас? Управлять или направлять? Важно понять одно: каждый случай уникален. И ваш тоже. Поэтому каждый должен ответить на эти вопросы для себя и только потом обсуждать их вслух.Три самых важных аспекта, понимание которых поможет вам с первого раза успешно построить эффективные процессы менеджмента:
- Что хотим создать.
- Для кого хотим создать.
- Зачем хотим создать.
- структуру команды;
- ролевую модель;
- методологию управления;
- план адаптации к изменениям;
- набор инструментов и подходов управления;
- цели и road maps развития;
- метрики, KPIs, OKR.
Для аудиторий различных конференций, которые так или иначе относятся к проектному/продуктовому менеджменту, все эти вопросы оказались до боли актуальными, несмотря на то что встречаются представители компаний самых разных масштабов. Способы управления или направления по отношению к командам могут быть разными. Но, говоря о коммуникации, мы каждый раз приходили к выводу, что ею можно только управлять и команда в таком случае становится эффективнее.
Двое у руля
Как показало общение и совместная работа с проджект-менеджерами на конференциях, вопрос, которым задавался фактически каждый практик, следующий: возможно ли управление проектом вдвоем?Сегодня можно придумывать различные методологии/фреймворки (Waterfall, Agile, Scrum, Kanban, Lean...), инструменты (RACI, WBS, Gantt chart diagram, матрица требований/рисков/стейкхолдеров...), ссылаясь на профессиональные источники (PMI, ScrumAlliance, DOU и др.). Но иногда встречаются кейсы, которые противоречат не только классическим подходам в проектном менеджменте, но и здравому смыслу. Один из них — управление одним проектом при равноправной ролевой модели двух проджект-менеджеров. И даже в этом случае у вас есть все шансы на успех. Не опускаем руки, для начала необходимо разобраться, законно ли это.
Это весьма нетипичная модель, но она часто встречается в современной практике, когда идет этап реструктуризации проекта или его передача от одного к другому PM (ведь этап передачи highload-проекта может достигать 2–3 месяцев, и на протяжении всего этого времени проектом управляют два человека). Очень важно вовремя идентифицировать, что проект начал какую-либо трансформацию, например из проекта в программу или портфель, ведь эти структурные изменения требуют пересмотра ролевой и поведенческой модели в команде, в том числе — количества проджект-менеджеров (возможно, функциональных).
Также наличие двух проджект-менеджеров возможно в мультистримовых проектах, где, кроме направления разработки ПО, есть стримы маркетинга, продаж/логистики и прочее. И в каждом направлении может быть свой менеджер.
Мой любимый кейс, с которым я сам однажды столкнулся на практике, когда на проекте появляются два проджект-менеджера, это вопрос-хотелка заказчика «А давай усилим твой проект?»; хотя фактически это никогда не является вопросом, а скорее: «Я умнее, поэтому решил, что теперь вас двое». И даже если вы использовали все свои хард-, софт- и мегасупер-скилы для ухода от данного «решения», с этим можно эффективно работать. Поговорим детальнее как.
Что нужно учесть в первую очередь
Каждому на новом этапе жизни проекта важно знать, какие первые шаги нужно сделать. Я подскажу какие.Итак, на очередной встрече с руководителем/клиентом вам озвучивают: «Ты молодец. Но мы решили усилить твой проект, и завтра к тебе присоединяется еще один PM». Вы, конечно, попытались изменить условия игры, вытереть холодный пот. Но что же делать, учитывая, что данного кейса не избежать? Поехали.
Причина. Определите, какой из вышеперечисленных кейсов у вас сложился и по какой причине у вас в проекте добавился второй PM. Ведь трансформация проекта или организационной структуры компании — далеко не единственная причина. Еще одной причиной я бы хотел назвать ваше собственное решение как менеджера проекта. Добавление второго человека не всегда «плохое, притянутое за уши решение». И если вы как менеджер решили вырасти (до Program/Portfolio manager), чтобы тем самым принести пользу проекту, то имеете все инструменты для этого; главное, не забудьте подготовить под такие изменения бюджет.
Проблема/задача. Что именно мы или не мы хотим решить и чего добиться добавлением нового проджект-менеджера в команду.
Результат. А второй действительно сможет решить поставленные задачи или мы пытаемся увеличить скорость автомобиля, прикручивая зеркало заднего вида?
Понять это весьма просто. В большинстве случаев новый PM может помочь с решением задач из области ресурсного перераспределения (проще говоря, примет на себя часть функций в проекте), внедрением внешней экспертизы в реализацию проекта или решение точечных проблематичных кейсов. Формулировка «Мы постоянно проваливаем даты новых релизов, поэтому нам нужен второй PM, чтобы все более качественно заменеджерить» может стать губительной, если, разбирая каждый отдельный случай, выясните, что не в недостатке ресурса проджект-менеджера проблема, а в банально не прописанных Definition of Ready и Definition of Done. Этот пример — не плод неординарной фантазии, а примеры из одного моего проекта. В момент первого знакомства с одним из главных стейкхолдеров проекта я и услышал подобную формулировку. Хорошо, что спустя несколько продолжительных встреч и множество ночей, проведенных в процессе аудита проекта, мне удалось убедить его в том, что тут не решить проблему даже 10 проджект-менеджерами, если не прописать вышеназванные критерии.
Квалификация второго проджект-менеджера. Мы же должны понимать, насколько мощный ресурс попадает к нам в команду. Есть вероятность, что нас просто заставляют поменторить какого-то джуна под таким предлогом.
Проджект-менеджер проджект-менеджеру друг. Просто поговорите с новым PM в неофициальном формате, попробуйте понять его ожидания, поделиться своими, узнать о том, какую пользу он может и хочет принести, и просто банально попытайтеь договориться, как же вам теперь жить вместе.
Допустим, первые шаги вы выполнили и уже даже смогли как-то для себя обстановку очертить. Теперь мы знаем, почему, зачем и кто. Но что же делать дальше и как с этим быть на практике?
Инструментарий
Я за всю свою практику вынес два самых важных и эффективных инструмента, которые просто необходимы для эффективного управления проектом вдвоем:- карта коммуникаций;
- многоуровневая RACI-матрица.
На первый взгляд этот инструмент может показаться бюрократизированным. Век agile, а мы тут бумажки по правилам общения внутри команды формируем! Но это абсолютно не так. И тот, кто сталкивался с хаосом в проектах, понимает, что без четких правил взаимодействия и управления коммуникациями эффективное управление невозможно, тем более вдвоем.
Вы только представьте (или вспомните) свои ощущения, когда приходите на проект, в котором 10–50 (неважно сколько) человек, и вам необходимо всем этим как-то управлять. И что еще важнее, управлять, достигая определенной цели.
Согласен, за один день вся эта сложная паутина не распутается, но первое, что вы сделаете, — попытаетесь консолидировать информацию о проекте (мы надеемся, что предыдущий PM использовал конфигурационное управление, но надежды остаются надеждами). Для планомерного сбора данных вам потребуется синхронизировать потоки коммуникаций в проекте между участниками и взять их под контроль. Карта коммуникаций в этом точно поможет.
Многоуровневая RACI-матрица, конечно же, остается инструментом формирования ролевой модели на проекте, но ключевое слово — «многоуровневая», что позволяет нам формировать RACI в нескольких «измерениях». Максимально применима в матричных организационных структурах компаний.
Я для себя вывел два типа многоуровневой RACI-матрицы:
- Кросс-функциональная, или «RACI на RACI». Выше проговаривали, что несколько проджект-менеджеров возможно на мультистримовых проектах. Так вот мы на каждый стрим / функциональное направление создаем отдельную RACI, где ответственным за бюджет, к примеру каждого из стримов, будет свой проджект-менеджер, но при этом нам еще необходимо создать глобальную матрицу, в которой определить одного ответственного за глобальный бюджет.
- Многоуровневая RACI. Это классическая визуализация RACI-матрицы, только включает она не просто одного ответственного за бюджет например, а 3 уровня (ну или сколько у вас там проджект-менеджеров на проекте образовалось), правила, которые мы задаем. И они нам могут говорить о том, что:
- R (Responsible) 3 — ответственный за бюджет бизнеса;
- R2 — ответственный за бюджет IТ;
- R1 — ответственный за бюджет всего проекта/продукта.
Пример классической карты коммуникаций, которая применима для многочисленных команд; поэтому структурируем карту по функциям, а не по людям и проставляем связи проектного и функционального взаимодействия:
лаконичность, доступность широкому кругу стейкхолдеров, легко вносить динамические изменения, идеально подходит для команд с более, чем 20 участников. малая информативность о функциональных ролях, не предусматривает детальных кейсовых вариаций, имеет обязательный набор исключений.Рассмотрим еще один вариант визуализации карты коммуникаций, но теперь уже для немногочисленных команд; и эта карта, в отличие от предыдущей, визуализирует взаимодействие между ролями в команде:
визуально доступна для восприятия, правила понятны без дополнительной презентации/пояснений/комментариев, формат применим в командах до 12–15 человек. может содержать до 3–4 правил, не учитывает исключительных кейсов, неприменима в матричных структурных организациях.Альтернативно-креативным вариантом карты коммуникаций может быть и такой формат. Данная карта визуализирует не ролевое взаимодействие, а маршруты коммуникации в команде/организации/группе:
применима для функциональных и матричных организационных структур, описывает любые маршруты и правила, допускает для визуализации любые кейсы. сложна для визуального восприятия, неприменима для многочисленных команд/организаций/групп, имеет предел масштабирования.Как вы уже поняли, нет правильного или неправильного формата для визуализации карт коммуникаций, самое главное, чтобы она отвечала своему назначению и команда готова была ею пользоваться. А для этого попробуйте не фантазировать в одиночестве, а создать ее вместе с командой. В моей практике очень хорошо зарекомендовал себя итеративный подход создания подобных карт через командные мозговые штурмы. То есть мы не стремимся создать с помощью одного подхода сразу комплектный инструмент, а дополняем, корректируем и модернизируем его на протяжении какого-то периода, например до окончания фазы инициации/планирования. В исключительных случаях, когда вы на проекте не с самого начала, есть смысл ставить дедлайн самому себе, подвязав его к impact milestone на критическом пути.
Есть и другие возможные варианты поведенческо-ролевых моделей в зависимости от структурного типа компаний, что является основополагающим фактором формирования карты коммуникаций и многоуровневой RACI. В Киеве на Project Management Day 2019 мы успели не только поговорить об этом, но и сформировать несколько детальных моделей.
P. S.
Посещая различные конференции, для себя почерпнул важность того, что каждая компания, как и каждая команда, является уникальной и несет уникальные культурные ценности. При общении с представителями различных продуктовых, аутсорсинговых, диджитал-компаний эта их особенность очень явно видна. И это круто! Частично в этом и есть прелесть нетворкинга на подобного рода мероприятиях. После них ты всегда имеешь что-то на «подумать», если, конечно, не проводишь все время за столиком с бесплатными снеками и кофе. Очень полезно заглянуть за борт своей организации и задаться вопросом: неужели там может быть по-другому?Также полезно говорить с коллегами и формулировать свои взгляды и гипотезы. Так рождается истина. Надеюсь, я смог принести пользу менеджерам, с которыми поделился этими знаниями. Все вышесказанное я успешно применяю в процессе создания нашего нового продукта Connectable (проект в разработке).
Общение, общение и еще раз общение. И даже управляя командой вдвоем, вы начнете перформить на максимум.
А теперь попробуйте заглянуть за борт...
DOU
DOU – Найбільша спільнота розробників України. Все про IT: цікаві статті, інтервʼю, розслідування, дослідження ринку, свіжі новини та події. Спілкування на форумі з айтівцями на найгарячіші теми та технічні матеріали від експертів. Вакансії, рейтинг IT-компаній, відгуки співробітників, аналітика...
dou.ua