Когда вам говорят, что теперь разработка вашего продукта будет идти по Scrum, одним из первых вопросов часто бывает, как разделить продукт на команды, численностью от 3 до 9 человек.
Когда вы переходите к работе по Scrum Если над вашим продуктом работает более одной Scrum-команды часто стоит выбор: разделить продукт на части, над каждой из которых работает отдельная команда, либо работать без специализации команд. У каждого из выборов есть свои плюсы и минусы, и, выбирая, нужно просто понять, что конкретно вам важнее.
⚧ Давайте начнём с варианта разделения на подпродукты. Выгоды тут очевидны: каждая команда фокусируется на небольшой части бизнес-функциональности и через какое-то время хорошо начинает в ней разбираться, от чего качество и скорость разработки растёт.
Но есть достаточно много подводных камней, большую часть из которых удаётся увидеть, только проработав некоторое время.
🫅 Из того, что видно сразу — далеко не всегда есть возможность найти в каждую команду человека на роль Владельца Продукта, который бы достаточно хорошо понимал бизнес и мог сам принимать решения по приоритетам продукта.
Из того, что может проявиться несколько позже: у команд возникают зависимости, как технические, так и продуктовые, когда нет смысла или нет возможности выпустить фичи одной команды без фичей другой команды. Например, пока команда, занимающаяся лимитами кредита, не выпустит свою функциональность, команда, занимающаяся выдачей кредита, не может выпустить свою.
🔥 Наименее очевидная для команд мысль, что в какой-то момент, может оказаться, что одна из команд делает самые приоритетные фичи из своего Бэклога, но самые НЕприоритетные фичи с точки зрения всего бизнес-продукта. Например, одна команда делает премиальные фичи для вкладчиков, которые по статистике использует не более 5% всех вкладчиков, а другая команда, которая реализует открытие вкладов в удалённых каналах, что гораздо более приоритетно с точки зрения бизнеса. То есть с перспективы всего продукта «Вклады» гораздо важнее сделать сначала достаточно качественно открытие вкладов, а уже потом переходить к второстепенным функциям продукта, таким как премиальные фичи. Иногда, когда руководство продукта это замечает, оно может переквалифицировать эту команду на другую часть продукта. Но в большинстве случаев приоритеты могут меняться между частями продукта достаточно часто. В более худшем случае руководство перебрасывает отдельных людей между командами. Это, с одной стороны, повышает стресс «перекидываемых» сотрудников, а, с другой, препятствует выработке доверия и взаимопомощи в команде из-за нестабильности состава команд, что в свою очередь не позволяет достичь максимальной производительности команд.
🛣 Давайте рассмотрим другой вариант, когда мы не закрепляем за каждой из командой конкретную часть продукта. В этом случае каждая команда может разрабатывать любой элемент Бэклога, что автоматически приводит к тому, что на все команды продукта есть только один Бэклог Продукта, который распределяется по командам только на Планировании Спринта. И тогда мы можем гарантировать, что в каждый Спринт каждая команда берёт самые приоритетные элементы из Бэклога. Таким образом, если у нас нет отдельных Бэклогов Продуктов у команд, то и не нужен человек занимающийся их приоритезацией, т.е. не нужны Владельцы Продукта в каждой из команд, а нужен только одни на весь продукт. И тут уже вам решать, плюс для вас это или минус: либо здорово, что вам не нужно искать Customer Journey Expert в каждую команду, либо вы не знаете куда деть всех этих людей, которых вы наняли на роли «Владельцев команд». Во втором случае, если люди действительно ценные, вы наверняка найдете им применение либо в Change-командах, либо в Run-деятельности вашего продукта, а вот если это были просто «надсмотрщики» команд, то расставайтесь с ними без сожаления.
🐘 Есть ещё один момент, который может остановить от использования таких универсальных команд. Чем больше продукт, тем сложнее каждому участнику разбираться в каждой из частей этого продукта, поэтому, как правило, скорость разработки в таких командах несколько ниже, чем в узкоспециализированных. И тут взвешивая все «за» и «против» всегда помните:
1 Насколько вариативен ваш Бэклог с точки зрения бизнес-компонент? Если вы уверены, что без ущерба бизнес-приоритетам вы можете зафиксировать команды на разных частях бизнес-функционала, то лучше так и сделать. В противном случае лучше сделать универсальные команды пусть даже с некоторым снижением средней скорости разработки, зато вы всегда будете делать самое важное.
2 На какой срок вперед вы точно знаете, что нужно сделать по продукту. Например, если у вас нерыночный продукт, вам по какой-то причине неважна обратная связь от заинтересованных лиц по вашему продукту, вам выпускать релиз только через год и вы можете зафиксировать требования на весь этот срок, то вы можете посадить каждую команды делать свою часть функциональности и под конец проекта просто перебалансировать их, если вдруг одна из команд сделала быстрее свою часть, чем остальные. Если же у вас нет хотя бы одной из этих возможностей, гораздо предусмотрительнее сделать команды универсальными и иметь возможность менять требования и приоритеты в ходе разработки.
И так, если вам важно иметь возможность дополнять Бэклог Продукта, менять требования и/или их приоритеты в ходе работы над продуктом, то скорее всего вам подойдёт подход, когда у вас есть единый Бэклог Продукта на несколько команд, один Владелец Продукта, приоритезирующий этот Бэклог, и команды готовые брать любой из элементов этого Бэклога. LeSS Framework как раз описывает совместную работу Scrum-команд над одним продуктом с одним бэклогом.