В этой статье на практических кейсах и моего опыта я расскажу, как сформировать команду и объединить её вокруг продукта. А также разберемся, как сформировать мотивацию, когда команда уже давно собрана, но почему-то не приносит ожидаемых результатов.
Привет, меня зовут Наташа, сейчас я продакт-менеджер в РТЛабс и работаю с командой разработки мобильных приложений Госуслуг.
Кейс №1: «Наша команда МП Авто»
Наша текущая команда занимается разработкой мобильного приложения «Госуслуги Авто». В команде: 1 PO, 3 разработчика мобильных приложений под iOS и Android, Backend разработчик, 1 системный аналитик, 2 бизнес-аналитика, 2 QA и 1 Devops – итого 14 человек.
Методология разработки – Scrum.
Приложение новое, в проде с 5 сентября 2021 года. Пока мы покрываем несколько сценариев, но в планах к текущему электронному СТС выпустить еще и водительское, а также полис ОСАГО. Это позволит водителям не носить с собой бумажные версии документов.
Трудности, с которыми мы сталкиваемся:
В команде специалисты из разных подрядных организаций, соответственно, требуется дополнительный ресурс на сплочение и мотивацию;
Так как проект государственный, некоторые процессы не позволяют выпустить функционал быстро, тратится время на административный ресурс;
Очень большое количество зависимостей от других команд и подразделений.
Какие практики мы применяем:
PO участвует во всех дейликах, делится новостями, даже теми, которые не относятся к разработке непосредственно.
Планнинги, грумминги и демо – стандартные практики из Scrum. Да, они круто работают!
Все вопросы оперативно обсуждают в чате, причем наш корпоративный чат – в Telegram, что очень удобно в плане доступности команды.
Прежде чем принимать решение, РО спрашивает мнение команды (демократия в хорошем смысле!).
Результат:
Очень высокая степень владения предметной областью у команды.
Готовятся к выходу крупные фичи – Европротокол, обжалование штрафов, электронное ВУ и ОСАГО.
Кейс №2: «Стартап с нуля с новой командой»
Сетап команды: 11 человек (1 РО, 1 QA, 2 Frontend, 4 Backend, 1 Architect, 1 DevOps)
Уровень команды: специалисты уровня Senior и Lead
Предыстория: Стартап внутри компании, которая на рынке более 20 лет. Первым участником команды был бизнес-аналитик, который выполнял роль продакт-оунера. Команда собиралась в течении 2 месяцев с рынка. Идейным вдохновителем проекта был продакт-менеджер на стороне заказчика с очень сильным техническим бэкграундом. Между командой и продакт-менеджером была большая разница во времени (Москва-Лос-Анджелес), поэтому прямо контакт команды с ним практически не было. Все решения и согласования происходили через продакт-оунера и архитектора.
Методология разработки: Agile, Scrum, 2-х недельные спринты.
Трудности:
Команда «несработанная» – каждый сам по себе сильный специалист. На настройку командной работы потребовалось время. Проблемы заключались в потребности каждого доказать, что он прав, возможно даже вопреки продукту и команде в целом;
Изолированная работа команды от самого бизнеса и заказчика;
Не было четкого плана MVP и сроков выхода в прод с первой версией;
Предметная область - Product Information Management, которая включает сложную логику связей между сущностями и зависимостями. Предполагалось разработка универсального решения, как для внутренних пользователей, так и для продажи как коробочное SaaS решение;
Не было контакта с будущими пользователями продукта.
Какие практики мы применяли:
Погружение каждого участника команды в продукт, предмет и процессы c самого первого дня на индивидуальных встречах (именно не встречах, а не «на, почитай и сам разберись») длительностью минимум 1 час.
Регулярные обсуждения нового функционала на Product Backlog Refinement встречах по схеме:
РО рассказывает, зачем нужна функциональность, приводит примеры из жизни
Команда задает вопросы, предлагает идеи. РО их фиксирует, но не отвечает сразу
РО дополняет стори исходя из заданных вопросов, рисует схемы и тд.
На следующей встрече команда смотрит на описанную ситуацию. Происходит совместная генерация и дополнения идей. Как результат – стори готова к оценке.
Подход Jira – first: сначала все стори фиксируются в Jira, комментарии и обсуждения ведутся там же. По результатам спринта, важные моменты описываются в kb.
Командные брейнштормы с архитектором.
Результат:
Получили сплоченную команду, в которой нет конфликтов;
Выстроили четкий эффективный процесс разработки без простоев;
При отсутствии РО, каждый знал, что мы делаем и зачем. Мог предложить, как сделать лучше или принять консистентное микро-решение.;
Но были и минусы – свобода творчества привела к тому, что очень много времени потрачено на рефакторинг и пересмотр концепций, которые изначально казались удачными, но не смогли оправдать себя;
Отсутствие сроков и четкого скоупа MVP не привели команду к результату – стартап был закрыт.
Кейс №3: «Готовая команда без мотивации»
Сетап команды: 15 человек (1 PO, 6 Backend, 3 Frontend, 2 QA, 2 Pentaho Dev, 1 DevOps)
Предыстория: Небольшой HR Tech стартап полного цикла, включая рекрутинг. Сложный американский пэйролл, обучение и тд. СЕО и продажи –в США, разработка – в СНГ. На момент моего трудоустройства в команде разработки было около 15 человек, из них 5 работали уже 7 лет с самого начала.
Меня взяли как продакта/бизнес-аналитика. На тот момент бизнес-анализом занимался СЕО и разработчики, которые писали спеки. Все вопросы были адресованы СЕО, но ответы приходили примерно в 50% случаев. С одной стороны, команду мотивировали на креатив и принятие решений, однако, за любой промах ругали. Когда я к ним пришла, почти на любую фразу слышала: «Давай спросим у СЕО как правильно, а то нам снова влетит». Команда была в силах выпустить только небольшие доработки, большей частью которых никто из клиентов не пользовался. В то же время, планы у компании стояли амбициозные – начать выпускать крупные фичи, обеспечить рост и привлечь инвесторов.
Методология разработки: Kanban (для багфикса), Scrum (для новых фич).
Трудности:
Команда демотивирована: никто не хочет принимать решения и брать на себя ответственность. Наличие постоянно висящих вопросов к СЕО;
Frontend работает отдельно от Backend’а, фичи не проверяются разработчиками совместно– отсюда куча багов и поехавшая верстка;
У команды отсутствует видение продукта и перспектив его развития – работа больше похожа на тушение пожаров;
Постоянные переключения между задачами. Запросы от клиентов и внутренних стейкхолдеров часто обрабатываются по принципу «кто громче кричит и сильнее просит, тому сделаем в первую очередь»;
Большое количество переделок, потому что сделали для одного клиента, а другим не подошло.
Какие практики применяли:
СЕО компании был противником встреч, считал, что это пустая трата времени и денег. В итоге, удалось выбить по 2 часа в неделю на грумминги бэклога.
На груммингах команда смотрела на уже готовую спеку, так как фичи были крупные, проводила анализ бизнес-кейсов, конкурентов и готовила мокапы, схемы и описания до встречи с командой.
Все вопросы тут же фиксировались прямо в спеке. Если ответ был длинный – РО брал тайм аут, но к встрече для оценки фич все ответы были предоставлены.
На груммингах собиралась вся команда, которая будет заниматься разработкой новых фич, это помогло объединить Frontend, Backend и QA, таким образом под каждую фичу формировалась микро-команда.
Результат:
Команда перестала срывать сроки релизов, что позитивно отразилось на отношениях с клиентами и партнерами компании.
Был обновлен дизайн приложения на более актуальный.
Раз в квартал команда выпускала 2-3 сложные фичи, которые затрагивали весь продукт.
QA отметили, что качество кода осень сильно выросло и снизило нагрузку на них.
Выводы
Самое главное в мотивации команды – каждый её участник должен понимать, что мы делаем и зачем. Идеальная ситуация – продакт оунер в отпуске/на больничном – работа не встает, посовещавшись команда может принять правильное продуктовое микро-решение.
Достичь этого можно с помощью следующих инструментов:
Онбординг для каждого члена команды в самый первый день его работы. Инвестиция – час, а результат – самостоятельная замотивированная боевая единица;
Участие в дейликах, освещение всех новостей (ну или почти всех);
Бэклог-грумминги, а также другие практики SCRUM на регулярной основе;
Спрашивайте мнение команды по тому или иному вопросу в рамках их компетенций, организуйте мозгоштурмы и дискуссии, но следите за тем, чтобы это было продуктивно и не подрывало ваш авторитет;
Создавайте микро-команды под большие сложные фичи;
Будьте евангелистом своего продукта, любите его и заражайте этой любовью свою команду!
Одна из топовых книг по созданию продуктовой команды – “Вдохновленные” (“Inspired”), Марти Кагана.
Встречались ли вы с подобными кейсами и как справлялись с мотивацией команды? Какие практики используются в вашей команде?
