60 дней фильмов и сериалов
по промокоду:
VC60
Забрать
60 дней подписки Яндекс Плюс бесплатно для новых пользователей, ранее не оформлявших подписку Яндекс Плюс либо подписки, её включающие, при условии привязки банковской карты. Далее — автопродление: 199 ₽/месяц. Действует на территории РФ. Активировать до 04.06.2021 г. https://hd.kinopoisk.ru/gift. Условия: clck.ru/FMQND.
Личный опыт
Joom

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

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

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

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

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

С чего мы начали и что пошло не так

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

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

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

  • Все менеджеры работали в своём темпе. Кто-то вообще отложил свою задачу, кто-то сделал не то, что мы написали в требованиях. Это выяснилось только на следующей встрече через две недели. Мы все затягивали сроки и ничего не успевали.
  • Чтобы лучше синхронизироваться, мы решили звать на встречи всех участников команды, а не только менеджеров: думали, что если будем рассказывать, что нужно делать сразу всем коллегам, они вовлекутся и будут лучше понимать, что происходит. Но даже на общих встречах разговаривали в основном менеджеры: спорили, вступали в обсуждение, а участники команды не понимали, зачем их сюда позвали. Мы быстро прекратили такую практику.
  • Разбивали цели по командам вместо того, чтобы задать одну цель для всех. Мы в Joom планируем квартал по системе OKR. Цели по нашему кросс-командному проекту мы делили в зависимости от направления команд. Получилось, что в течение квартала мы вроде бы собирали общий продукт, но по факту все смотрели немного в разные стороны.
  • Не смогли правильно разделить ответственность. Сначала мы с моим коллегой садились вместе и делили задачи: это тебе, это мне, это опять тебе. Порой мы делили ответственность даже по времени: я прямо сейчас зашиваюсь, давай ты. Звучит логично, но в кросс-командных проектах это не работает. Ожидания не совпадают, а люди уходят от ответственности. Команда терялась, к кому ходить с вопросами, кто будет отвечать за раскатку фичи, а кто — за результаты эксперимента.

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

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

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

1. Ставить общие цели и вести общий бэклог

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

2. Проводить менеджерские синки

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

3. Создать полноценную кросс-команду

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

4. Сделать общий синк-планирование и звать на него всю команду

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

5. Выделить одного менеджера на проект

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

6. Собирать кикоф-встречи для обсуждения фич

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

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

7. Выделить технического лида направления

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

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

8. Создать понятные тематические чаты

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

9. Собираться на общее командное демо

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

10. Делать общее ретро

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

Над чем мы всё ещё думаем

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

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

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

{ "author_name": "Joom", "author_type": "editor", "tags": [], "comments": 22, "likes": 9, "favorites": 26, "is_advertisement": false, "subsite_label": "life", "id": 242999, "is_wide": true, "is_ugc": false, "date": "Wed, 12 May 2021 10:21:59 +0300", "is_special": false }
0
22 комментария
Популярные
По порядку
Написать комментарий...
1

Вроде бы очевидные вещи были и так до того как пришли. Что разделение команд по платформам ни к чему хорошему не приводит.
Странно что происходит обсуждение фич и ничего не сказано про блокирование фичи, если фича пришла дичь)

Ответить
0

Несите дичь! ЗЫ: если я правильно помню, то это не первый секрет Полишинеля от Joom здесь.

Ответить
0

Ну типа план наверное делают по статьям или реальная проблема менеджерская при формирование команды)

Ответить
0

Всё может быть. Не знаю, не работал там.

Ответить
0

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

Кросс-команда объединяет разработчиков не только из разных платформ (iOS, Android, Web), но и других частей компании — команды рекомендаций, поиска, рекламы. Это ключевой момент.

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

Ответить
0

Основная проблема заключается в том, что опыт появляется после того, как он был нужен. :)

А вообще - критическое восприятие, отсутствие вечного аврала - сильно экономят деньги и время.

Ответить
1

Главное забыли упомянуть все это не работает если платить налоги, НДС, пошлины и прочие вещи, а не завозить из Китая посылки.

Ответить
0

Инфа сотка!

Ответить
1

Сколько менеджеров понадобится чтобы изобрести колесо? в Joom точно много.
"Собирать кикоф-встречи для обсуждения фич" - эта статья для булшит бинго ))
Вообще надо накатать какого-нить бота, который будет показывать post bullshit index )

Ладно, к делу.
Про аджаил не говорил наверное только немой, но в статье веет каким-то лютым формализом процессов на пустом месте, без какой либо гибкости на деле.

Есть владелец продукта: тот, кто знает как продукт должен выглядеть и как работать. Он составляет видение продукта, декларирует набор и объем фич, которые надо сделать, потом тип лиды собираются и договариваются кто что и в какой последовательности делает.
Вот тут могут быть все, кому в общем интересно что делается.
Далее лиды отдельно определяют кто от кого зависит и кому и что надо сделать, если прям какие-то глобальные изменения, то можно позвать оунера.
Лид вполне может делегировать конкретную реализацию конкретной фичи разработчику, который сходит и сам утрясет детали с потребителем. (Вот он этот самый отджаил, когда лид ДОВЕРЯЕТ разработку фичи, но сам, ели что контролирует.) 
И дальше все работают, бэк энд разработчик идет к конкретному фронту, или же наоборот, они делают фичу и выкатывают ее как результат работы, мини кросс команда так сказать, показывают оунеру, который всю картину держит в голове и если что корректирует бизнес реализацию. Все что можно пилить отдельно от всех, пилится отдельно и за пределы команды не особо выходит.

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

Не надо в людей впихивать ненужную информацию, она не то, что вылетит, она даже не залетит. Информацию люди потребляют по необходимости и вот над источниками инфы  и их доступностью и надо работать.
Условно если некий Вася с бэк энда, который не вылазит с перфоманса, дампов, логов и прочего, вдруг захотел узнать что-то про UI. То ему владелец продукта, обязан дать ссылки на видео, тексты и другую медиа где этот Вася ознакомится со всем что его интересует и задаст вопросы.
Он же не обезъяна, а разумный человек, который может самостоятельно прочитать, понять и задать вопросы и в случае чего изучить что-то более общее.

Ответить
0

В неделю, когда нет демо, на встречи мы тратим меньше часа времени всей командой. На неделе, когда демо есть — 1.5 часа или около того. В неделю.
До того как мы пришли к таким правилам, встреч было в 2 или 3 раза больше. Если хотите — пользуйтесь :) 

Ответить
0

Да это все очевидно и лежит на поверхности.
Я всегда ищу лида в тот или иной момент, который все сделает как надо и даже тебе принесет ))) А митинги не митинги он там сам разберется

Ответить
0

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

Почему бы это не отдать в команды, ведь они занимаются реализацией фичи, а описание готовить либо команде перед тем как это взять в работу или готовить описание на общем собрании, так называемый PBR https://less.works/ru/less/framework/product-backlog-refinement
 Основными видами деятельности при PBR являются (1) разделение больших Элементов Бэклога Продукта, (2) детализация элементов до готовности и (3) оценка элементов

Ответить
1

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

Ответить
0

> Ставить общие цели и вести общий бэклог

>> Они прописаны на специальной странице в Notion.

а можно хотя бы в полглазика посмотреть как вы работаете в Notion, тоже начали, но там такая помойка начинается :((( может быть какие то шаблоны интересные кто знает? 

Ответить
0

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

Ответить
0

У вас же конфлуенс есть

Ответить
0

Я бы уточнил одно правило 5. Выделить одного менеджера на проект

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

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

Будет ли это 1 менеджер или 2... Менеджер ли, может это овнер? Это уже детали.

Ответить
0

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

Ответить
0

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

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

 как надсмотрщик. Такое в команде нам не нужно

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

Ответить
0

Других задач, кроме как следить за фокусом, у нас на встречах с командой для фасилитатора обычно нет, поэтому его роль берет на себя собственно менеджер. Чтобы максимально упростить все :) 

Ответить
0

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

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

Вроде как фокус есть) а вот толку то от этого?

Ответить
0

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

Поэтому у менеджера хорошо получается держать как раз фокус именно на целе встречи.

Ответить
Читать все 22 комментария
Россия возобновит авиасообщение с курортами Турции с 22 июня Статьи редакции

С 28 июня возобновляются полёты в Италию, Болгарию, США и ещё пять стран.

Робототехника и облачные мощности: почему роботам нужны облака

Настроить автопилот квадрокоптера и запрограммировать коллаборативного робота проще с виртуальными серверами.

Что такое пассивное инвестирование. Рассказывает персональный брокер

Как правильно вкладывать деньги на годы или даже десятилетия, и как Уоррен Баффет выиграл пари

Лето с HONOR: скидки до 60 000 рублей на ноутбуки и не только

HONOR объявляет о специальных летних скидках на ноутбуки и другую продукцию бренда. С 18 июня пользователи смогут приобрести устройства HONOR с выгодой до 60 000 рублей. Подробнее об условиях акции вы можете узнать на официальном сайте интернет-магазина HONOR и в официальных монобрендовых магазинах HONOR в Москве и других городах России.

Дороги будущего: когда в России оцифруют строительство инфраструктуры и как это изменит индустрию

Использование данных и больших данных помогает различным отраслям работать более эффективно. Строительство — не исключение. Юлия Штрек, CFO группы компаний «Автобан», рассказывает о том, как использование цифровых технологий и информационное моделирование поможет развитию строительства дорог в России.

В Австралии испытали летающий гоночный электромобиль для будущих соревнований в стиле «Формулы-1» Статьи редакции

Мультикоптер Alauda Airspeeder Mk3 пока летает в беспилотном режиме, но в случае успеха место за штурвалом займёт человек.

Летающий электромобиль Alauda Airspeeder Mk3 Скриншот видеопрезентации
Москва вошла в тройку рейтинга экосистем для стартапов среди европейских городов
Занять столь высокое место в рейтинге столице позволили городские программы развития технологического сервиса.

Таким образом, столица улучшила свою позицию на один пункт по сравнению с предыдущим годом. Обогнать Москву удалось лишь Лондону. Замыкает тройку лидеров – Париж.

Облачные игры стали доступны клиентам Yota
Создатели Maps.me запустили сервис Organic Maps с офлайн-картами без трекеров и регистрации Статьи редакции

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

Скидки и деньги: как российские компании уговаривают сотрудников и пользователей на прививки от Covid-19 Статьи редакции

Обязательную вакцинацию 60% персонала в сфере услуг, торговли и других уже ввели в Москве и части регионов.

Сотрудник «Сбербанка» авторизовался в моём аккаунте — это было сделано без моего согласия

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

Комментарии
null