Всем привет! Меня зовут Марина Гончарова, и я IT-проджект-менеджер в Купере.

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

Именно во второй роли я сейчас работаю в Купере. Легко ли это? Нет, но безумно интересно и драйвово!

В этой статье я расскажу:

• Как в Купере появились кросс-командные проджекты и почему важна эта роль

• Чем различаются работа с командой и работа без нее

• Какие инструменты упрощают жизнь кросс-командному проджекту

• Как договариваться с командами, чтобы залезть в их бэклог

Контекст Купера

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

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

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

Тимлид и продакт-менеджер внутри команды занимаются развитием своего сервиса и команды, поэтому для координации кросс-командных бизнес-проектов нужна отдельная роль.

Кросс-командный проджект-менеджер:

• связывает все команды;

• составляет сквозной план-график проекта;

• следит за сроками;

• решает проблемы, возникающие в межкомандном взаимодействии.

Это не бог и не супергерой, но иногда очень похоже :)

Win-win. Выгода для бизнеса и самого проджекта

Зачем компании роль кросс-командного проектного менеджера?

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

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

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

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

Проджект с командой и без: ключевые отличия

Предположим, вы проджект-менеджер одной команды. Как понять, что вы готовы стать кросс-командным проджектом? Я упаковала свой опыт в сравнительную табличку. Она наверняка не исчерпывающая, но может навести вас на умные мысли :)

Что такое хорошо и что такое плохо — решать вам, исходя из личных качеств. А для тех, кому по душе перспективы кросс-командного проджекта, — мои советы дальше.

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

Инструменты кросс-командного проджекта

Главное правило при работе над проектом без собственной команды — придерживаться классического процесса управления проектом. Речь о пяти этапах проектного менеджмента, которые описаны во всех учебниках и которые вы легко нагуглите ;) Чем тщательнее вы пройдете эти пять этапов, тем прозрачнее будет проект и его управление для всех участников: и для бизнеса, и для команд. А значит, тем выше вероятность, что проект запустится в срок и без критичных ошибок.

Подчеркну: тщательная проработка важна даже на этапе инициации. Когда мы юны и зелены, инициация кажется пустяковым делом. По моим наблюдениям, kick-off встреча на старте проекта примерно на 50% определяет будущий успех. Не поленитесь и соберите всех-всех-всех. Большая встреча помогает каждому усвоить мысль, что проект официально начался. Это как торжественное перерезание ленточки, жирная точка, нулевой километр. В календаре красуется встреча — тумблер перещелкивается.

Еще есть артефакты и документы, которые обеспечивают прозрачность и порядок.

Без чего точно не обойтись?

1. Документация. Функциональные требования, техническое задание, Solution Design, архитектурные схемы — вся проектная документация должна быть собрана и структурирована. Я, как правило, объединяю в one-pager все это + расчет ожидаемого эффекта (экономику), перечень вовлеченных команд, план-график и любую другую нужную информацию.

2. Матрица распределения ответственности (RACI). Таблица ролей и обязанностей — чтобы точно понимать, кто за что отвечает в рамках проекта.

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

4. Рабочая среда для общения. Не забывайте про канал для оперативного межкомандного взаимодействия — общий чат или другой инструмент, где участники проекта могут решать вопросы между созвонами. Умоляю, фиксируйте договоренности, ведите минутки! Это базовая база, про которую почему-то часто забывают, хотя она сильно помогает не тормозить процесс.

5. План-график проекта. Единый календарный план, отражающий все этапы и контрольные точки проекта, дедлайны по задачам и взаимозависимости.

Я стараюсь использовать все эти артефакты в каждом проекте. Чем полнее набор, тем проще управлять проектом, а это прямо влияет на успешный и своевременный запуск.

Как добиться вовлеченности команд

Отдельная задача для проджект-менеджера без команды — сделать так, чтобы команды-исполнители взяли в работу все необходимое. У них тьма забот по собственным сервисам, а тут кто-то приходит и говорит взвалить на себя еще больше задачек… Просто попросить — не вариант.

Чтобы попасть в бэклог команд, я применяю несколько методов.

Прежде чем идти к командам с «чужим» проектом, важно перевести его ценность на язык метрик. Я собираю оценки, какие показатели улучшит запуск (финансы, конверсия, устойчивость системы, лояльность клиентов и т. п.) и насколько широкий круг пользователей или партнеров затронут изменения. Цифры реально помогают обосновать, зачем нужен проект, и не биться за место под солнцем в бэклоге.

Второй ключевой момент — «продажа» проекта исполнителям. Если разработчики и лиды понимают ценность задачи, отдача от них будет совсем другая.

Можно сухо сказать: «Сверху спустили проект. Надо делать, потому что так сказал бизнес». А можно — заразить энтузиазмом: «Ребята, есть классный проект! После его внедрения ожидаем рост конверсии на 100500%! Сейчас, чтобы оформить заказ, пользователю нужно 25 кликов, а будет достаточно одного. Стильно, модно, молодежно — давайте запускать, у меня прямо руки чешутся!» Разница колоссальная.

Чтобы вдохновить других, нужно самому верить в проект — «купить» его у инициаторов. А для этого нужно замучать бизнес миллионом вопросов: для чего мы это делаем, какую проблему пользователя собираемся решить. Если у проджекта горят глаза, исполнители это чувствуют.

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

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

Бывает, что бизнес настаивает на проекте, а команда сомневается (например, считает эффект незначительным). Тогда приходится эскалировать приоритет проекта через менеджмент, чтобы лид получил установку сверху. После этого диалог с командой обычно идет легче. Возможно, это из разряда запрещенных приемов, но все-таки имейте в виду для кризисов.

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

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

Давайте пообщаемся в комментариях! Особенно жду отклик от тех, кто пробовал себя в кросс-командной роли. Узнали? Согласны?