10 правил создания кросс-командного проекта

Продакт-менеджер Joom Анна Васильева рассказала, какие ошибки совершали в совместной работе, а главное — как их потом исправили.

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

Мы поделимся своим опытом сотрудничества внутри компании, расскажем как сделать чтобы все участники только выиграли от объединения, а у каждой кнопки в вашем продукте не было отдельного менеджера. Статья написана по мотивам выступления продакт-менеджера Joom Анны Васильевой на Product Camp — спасибо, что позвали!

Всё началось с того, что летом 2020 мы решили сделать новую экосистему магазинов внутри приложения Joom. Это альтернативный способ поиска товаров. Проект сложный, в нём должны были участвовать несколько команд: клиентский продукт, продукт для продавцов, команды рекомендаций, поиска, акций, маркетинг и другие. Мы объединили усилия и конечно, поначалу наделали кучу ошибок.

На первом этапе над проектом работали три команды. Чтобы решить, как организовать процесс, мы провели встречу продактов этих трёх команд:

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

Но, конечно же, так это не сработало.

• Все менеджеры работали в своём темпе. Кто-то вообще отложил свою задачу, кто-то сделал не то, что мы написали в требованиях. Это выяснилось только на следующей встрече через две недели. Мы все затягивали сроки и ничего не успевали.

• Чтобы лучше синхронизироваться, мы решили звать на встречи всех участников команды, а не только менеджеров: думали, что если будем рассказывать, что нужно делать сразу всем коллегам, они вовлекутся и будут лучше понимать, что происходит. Но даже на общих встречах разговаривали в основном менеджеры: спорили, вступали в обсуждение, а участники команды не понимали, зачем их сюда позвали. Мы быстро прекратили такую практику.

• Разбивали цели по командам вместо того, чтобы задать одну цель для всех. Мы в Joom планируем квартал по системе OKR. Цели по нашему кросс-командному проекту мы делили в зависимости от направления команд. Получилось, что в течение квартала мы вроде бы собирали общий продукт, но по факту все смотрели немного в разные стороны.

• Не смогли правильно разделить ответственность. Сначала мы с моим коллегой садились вместе и делили задачи: это тебе, это мне, это опять тебе. Порой мы делили ответственность даже по времени: я прямо сейчас зашиваюсь, давай ты. Звучит логично, но в кросс-командных проектах это не работает. Ожидания не совпадают, а люди уходят от ответственности. Команда терялась, к кому ходить с вопросами, кто будет отвечать за раскатку фичи, а кто — за результаты эксперимента.

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

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

Мы отказались от идеи разбивать цели по направлениям, несмотря на то, что в кросс-команде есть разработчики из разных команд внутри компании. Теперь цели у нас общие. Они прописаны на специальной странице в Notion. Все стремятся к ним и смотрят в одну сторону: и разработчики, и продакт-менеджеры, и маркетологи.

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

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

Раньше во время работы с кросс-командой менеджер ходил на планирование разных команд (бэкенд, фронтенд…) и распределял задачи, которые нужно взять в следующий спринт. Мы сделали только одно общее планирование нашего направления — максимум на полчаса. Это очень удобно, потому что если задачи связаны друг с другом, люди хорошо понимают, в какой команде какая задача в какой момент начнет делаться. На встрече мы договариваемся, что, например, этот разработчик сейчас задачу не возьмет, потому что другая команда ещё не приступила к нужной части проекта.

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

Мы сделали правило, что по каждой новой фиче, которую мы берем в следующий спринт, мы обязательно встречаемся. Неважно, маленькая она, большая, или очень большая. Мы обсуждаем (именно голосом) каждую задачу. Даже если нужно созвониться на две минуты, это все равно нужно делать.

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

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

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

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

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

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

Строить кросс-команду — это живой процесс. У нас ещё остались незакрытые вопросы. Например:

• нужен ли кросс-команде выделенный дизайнер?
• а кросс-командный продакт-менеджер, который бы отвечал не за ведение самого проекта, а за описание фичей и их реализацию?
  

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