Крупные организации часто сталкиваются с проблемой функциональных колодцев (на западе - silos) - это когда каждое подразделение или продуктовая команда работает изолированно, фокусируясь только на своих целях, бюджетах и приоритетах. На первый взгляд, это кажется эффективным: каждый знает свои задачи и отвечает за свой результат... до тех пор, пока не потребуется реализовать кросс-функциональный / кросс-продуктовый проект. Рассмотрим это с позиции вендора, которые делает такой проект у крупного заказчика.

Причины

Почему так происходит? Можем рассмотреть это на примере 2-3 разных продуктов внутри большой компании. Что видел я на своих проектах:

Продукты имеют свои квартальные цели, KPIs, которые, как правило, не согласованы.
Продуктовые команды могут работать в разных ритмах / с разными каденциями.
Команды, по очевидным причинам, не могут иметь избытка ресурсов “на всякий случай” и любые непредвиденные запросы/инициативы неизбежно сталкиваются с дефицитом ресурсов.
Рассинхрон в понимании приоритетов внутри одного продукта - сеньор менеджмент видит одну картину, миддл-менеджмент и исполнители - другую.
Информационные потоки между продуктами недостаточно прозрачные.

В итоге, когда возникает необходимость в кросс-продуктовом проекте, требующем усилий со стороны нескольких продуктов, возникают сложности. Даже если руководители продуктов в курсе проекта и обещают свою полную поддержку (очевидно же, что проект реализуется в целях компании и компании от реализации этого проекта будет хорошо), кросс-продуктовое взаимодействие “на местах” обычно вызывает серьезные сложности.

Что же помогает реализовывать проекты/инициативы в таких условиях?

Что работает

Правильные ожидания. Свои

Важно самому с самого начала понимать, что взаимодействие между силосами не будет быстрым и гладким. Лучше заранее заложить в планы дополнительное время на согласования и быть готовым к тому, что не все запросы будут выполнены в срок, а некоторые и вовсе не будут выполнены.

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

Заранее обсудить сроки и зависимости.
Убедиться, что ваш запрос вписывается в их приоритеты. Если не вписывается, постараться подробнее понять планы и приоритеты другой команды и возможные варианты.
Быть готовым к компромиссам.

Раннее выявление зависимостей

Давайте сделаем небольшой шаг назад. Что такое кросс-продуктовый или кросс-функциональный проект? Очевидно, что это когда усилий только вашей собственной команды для выполнения проекта недостаточно и у вас есть некие зависимости на другие продукты / другие команды. Также очевидно, что в самом начале любого проекта никто не в силах выявить, детализировать и задокументировать все зависимости.

Для другой команды ваша зависимость на неё - это некая дополнительная задача, на которую нужно выделить конкретные ресурсы и их время. Очевидно, что если эта задача изначально не находится в бэклоге конкретного спринта, а вы придёте требовать её выполнения “на следующей неделе”, то понимания вы не встретите.

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

RACI

Да, старый добрый RACI и тут способен значительно облегчить вам жизнь. Опять же, перед началом проекта вы вряд ли сможете сделать RACI достаточно полным. Но если во время детализации зон ответственности при описании очередной выявленной зависимости вы должным образом отразите это в RACI и согласуете изменения с нужными стейкхолдерами - и вам и проекту бонус поинт.

При этом, не стоит воспринимать RACI как что-то, что непременно должно работать. Да, вы договорились, да, сферы ответственности такие, но это не всегда работает.

По-этому, всегда стоит понимать, что происходит в сферах, за которые, согласно RACI или каким-то отдельным договоренностям, отвечает заказчик. Люди есть люди и все могут ошибаться. Если заказчик с какой-то задачей по какой-то причине не справляется, это совсем не повод тыкать в конкретного исполнителя пальцем. Вам же, как вендору, нужен выполненный проект, а не железобетонное оправдание, что проект задержан/провален не по вашей вине, правда же?

Помощь и проявление инициативы

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

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

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

Управление рисками

Конечно же, все выявленные зависимости, сразу после их выявление и анализа, превращаются в риски. Вне зависимости от того, насколько вы уверены в том, что соседний продукт или команда сделает всё требуемое вовремя. Дальше ваша задача регулярно делать ревизию рисков с последующей коррекцией их Probability и Impact. Однако, если вы будете работать с рисками в своем персональном реестре рисков и раз в месяц показывать выдержку из него на Governance meeting - много ли будет от него пользы? Врядли. И дальше мы переходит к двум очень важным разделам - Transparency и Visibility.

Видимость (Visibility)

Чем больше команд знает, что происходит у вас на проекте, и чем больше вы знаете про события на соседних проектах и в соседних продуктах - тем лучше. И ваша задача распространять информацию о своём проекте, его сроках и зависимостях всеми доступными способами.

PI Planning, SoS

Какие способы у вас есть? Это напрямую зависит от процессов заказчика. Если вам повезло и заказчик практикует какую-то из гибких методологий (SAFe, Nexus или что-то похожее), то ваша задача очень качественно готовиться и на полную катушку использовать PI Planning и Scrum of Scrums. Это ивенты, одной из главных задач которых является выявление и устранение/ минимизация зависимостей.

Однако, PI Planning и Scrum of scrums - не панацея. Иногда ситуация меняется чаще, чем происходят нужные ивенты. И уж тем более нужны какие-то другие инструменты, если ваш заказчик не практикует ничего из вышеперечисленного.

Общий реестр рисков

Очень хорошо, если у заказчика есть общий реестр рисков, доступный всем заинтересованным сторонам и руководство действительно работает с этими рисками. Тогда ваши риски (и зависимости!) будут у всех на виду и по мере повышения probability / impact, продуктовые команды, отвечающие за конкретные риски, будут стараться с ними работать. Потому что никто не хочет, чтобы кросс-продуктовый проект задержался именно по его вине.

Митинги других команд

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

Ваши митинги

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

Прозрачность (Transparency)

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

Актуальный план проекта в публичном доступе (как минимум с доступом для всех стейкхолдеров)
Еженедельные отчёты о ходе проекта со ссылками на все рабочие артефакты (план проекта, реестр рисков, пространство проекта в Confluence, Deployment plan, и так далее) - также должны быть доступны всем стейкхолдерам + еженедельно рассылаться как часть Meeting notes с еженедельного статус-митинга
Meeting notes - это мощнейший инструмент поддержания transparency и visibility. Про это будет отдельная заметка. А тут пока можно отметить, что все митинги должны протоколироваться, все протоколы должны рассылаться участникам, все протоколы должны отражать обсужденные вопросы и принятые решения с согласованными исполнителями и сроками. И у всех стейкхолдеров должна быть возможность ознакомиться со всеми протоколами в любое время.

1on1ы с ключевыми стейкхолдерами

Это просто обязательно к применению. Индивидуальные встречи с ключевыми стейкхолдерами из продуктов / команд, на которые у вас есть зависимости, делает вышеперечисленные инструменты ещё более эффективными.

На встрече с ключевым стейкхолдерами у вас будет возможность:

обсудить текущее положение вещей,
уточнить их ожидания,
обсудить риски и текущие проблемы,
установить правильные ожидания относительно грядущего взаимодействия с вашим проектом,
ознакомить с актуальными планами,
попросить о своевременном выделении ресурсов,
дать свою обратную связь по текущему взаимодействию,
предложить свою помощь в решении вопросов, важных для стейкхолдера,
a также запротоколировать достигнутые договорённости и выслать follow up, чтобы у стейкхолдера при необходимости была возможность вспомнить, о чем он с вами разговаривал.

И конечно же, 1 on 1 совсем не обязательно целиком проводить в формальном ключе.

Неформальное общение

Официальные процессы работают, но личные отношения решают. Потому здорово работают любые неформальные отношения: короткие разговоры на кухне и в лифте, личные чаты, чашечка кофе и т.п. Если у вас есть прямой доступ к стейкхолдеру, то им стоит пользоваться. И если у вас сложились хорошие личные отношения со стейкхолдерами, то это половина успеха. Потому что когда вы придёте к нему с очередным запросом, то для него это будет не безличный официальный запрос от кросс-продуктового проекта, а просьба от вас лично.

Что не работает

Не работают ожидания, что между силосами взаимодействие будет простым и правильным:

ваши запросы выполнят быстро и без проблем.
RACI матрица правильная, актуальная и рабочая. И что все будут работать в соответствии в ней.
Эскалации.

А что работает у вас?

Дневники пиэма. Заметка 02: Функциональные колодцы (они же — silos)