Статьи

16 команд продуктовой разработки: страшный сон наяву или необходимость для бизнеса?

Усилия монопродуктовых компаний сосредоточены вокруг одного продукта или сервиса. Однако не ждите, что команда мечты появится у вас уже завтра по щелчку пальцев. Для слаженной работы над продуктом важен грамотно подобранный состав участников, правильное распределение ролей в процессе разработки, а также четко продуманный набор компетенций для каждого. Каким образом организовать работу, если у вас 16 продуктовых команд, и все они работают над созданием и развитием одного проекта? Сейчас расскажу.

Одна, две или много?

При организации процесса продуктовой разработки можно пойти тремя путями:
  • Создать одну scrum-команду. Стоит иметь в виду, что она не сможет справиться с большой нагрузкой. Поэтому такой вариант подойдет, например, стартапам или начинающим компаниям с маленьким сервисом или продуктом.
  • Если компания обладает достаточным количеством ресурсов, в первую очередь, человеческих, то в рамках продуктовой разработки можно разделить команду на департаменты и отделы. Каждый из них будет отдельно отвечать за бизнес и IT: первые формулируют задачи, а вторые их выполняют. К сожалению, такая структура работает только на бумаге, а в реальности мы получаем баги, неточности в интерфейсе и постоянные откаты назад. Кроме того, страдает скорость выпуска новых фич, а также их качество из-за необходимости постоянных согласований и отсутствия возможности креативить у разработчиков. В процессе разработки важна синергия всех участников процесса, ведь чем ближе условные постановщик и исполнитель задачи друг к другу, тем лучше. Другими словами, чем быстрее происходит коммуникация, тем быстрее решаются задачи и тем лучше продукт получится на выходе.
  • Создать кросс-функциональные команды. «Лига Ставок» пошла именно по этому пути. Базовая ячейка компании — продуктовая команда до 15 человек (лучше 12). В ней сосредоточены все роли и компетенции со стороны как бизнеса, так и разработки, поэтому участники могут самостоятельно вносить улучшения в продукт. У каждой команды есть определенная зона ответственности и метрика, над которой она работает. В кросс-функциональных командах достаточно синергии между участниками, существует свобода творчества и самовыражения, все объединены общей целью и решают одну задачу.

Как понять, что кросс-функциональные команды вам необходимы?

Создать и поддерживать эффективную работу нескольких кросс-функциональных команд сложно. Но если напротив каждого из пунктов ниже вы поставите галочку, возможно, это ваш вариант.
  • Вы — крупная компания, работающая над созданием и развитием масштабного продукта или сервиса, который требует больших затрат с точки зрения бизнеса и стека технологий.
  • Высококонкурентный рынок диктует свои условия: нужно действовать быстро, а любая задержка может привести к потере клиентов. Например, это относится к беттингу и индустрии развлечений: «Лига Ставок» в этом году добавила раздел ЧМ по футболу с разницей всего в несколько часов со своим прямым конкурентом.
  • В своем продукте или сервисе вы научились разделять путь клиента на отрезки, каждому из которых соответствует бизнес-метрика, на которую можно влиять. Важно понимать, как улучшения того или иного показателя можно выразить в конечном размере прибыли для компании.

Определение состава и распределение ролей

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

В чем сложности?

Казалось бы, достаточно разделить разработчиков на кросс-функциональные команды во главе с product owner, определить их состав, распределить роли, — и готово. Но не все так просто.
Существуют сложности во взаимодействии между командами. В процессе внедрения Agile-подхода на уровне одной команды, даже если их 400, все понятно. Большинство крупных компаний ломаются, когда пытаются масштабировать свой подход к взаимодействию команд.
Во-первых, могут возникнуть технические трудности. Важно развести команды так, чтобы они могли работать изолированно друг от друга. Продукт не должен быть монолитной базой, ведь в этом случае ошибка одной из продуктовых команд может затронуть зону ответственности другой. Займитесь изолированной архитектурой по блокам: регистрация пользователей, платежи, заключение пари и так далее. В этом случае каждая команда будет существовать в зоне своей ответственности, и микросервисная архитектура не позволит сломать весь продукт, если кто-то ошибется в рамках своего модуля.
Во-вторых, непродуманные инженерные практики могут помешать качественному клиентскому опыту. Решите, каким образом происходит сборка, какие ветки используются, по каким тестовым контурам идет проверка.
«Наша DevOps команда с нуля создала новую инфраструктуру с тремя разными средами разработки. Каждая из них находится на собственном Kubernetes кластере. Сегодня для создания новой среды разработки нам требуется 2 часа, конечная цель — сделать это в один клик.
В центре разработки находятся принципы двенадцати факторов и Cloud Native (программный подход к созданию, развертыванию и управлению современными приложениями в средах облачных вычислений). Наша QA-команда (quality assurance-команда / команда по обеспечению качества) старается максимально автоматизировать процесс тестирования, так как сложность и глубина проверок разработки в средах отличается. Большое внимание уделяется нашему CI/CD (Непрерывная интеграция / Непрерывное развертывание), который совершенствуется день за днем.
Отмечу, что в разработке не существует конечного этапа, после которого можно считать, что команда добилась успеха. Постоянное развитие — то, что драйвит и заставляет двигаться вперед », — комментирует Марин Путникович, главный архитектор компании «Лига Ставок».
В-третьих, непонимание взаимосвязи между метриками может помешать качественной оценке. В случае монопродуктовой компании сложно изолированно понять степень влияния релиза одной фичи на один конкретный показатель, поэтому важно научиться считать эффективность каждой команды. Изначально нужно хотя бы на бумаге обозначить метрики и зоны ответственности и внедрить практику проверки фич. Этот процесс должен быть организован только через A/B-тестирование. Проверяться должны все показатели на определенный процент аудитории. Кроме того, каждую из команд стоит оценивать независимо.

Собираем обратную связь

Самоощущение каждого человека в отдельности так же важно, как и эффективность работы всей команды в целом. Нужно понимать, что тунеядству и лени в продуктовых командах места нет. Важно получать фидбэк от каждого члена команды, чтобы держать руку на пульсе и грамотно оценивать, насколько комфортно и эффективно взаимодействие между людьми.
Именно поэтому каждый месяц мы собираем обратную связь от команд по нескольким тезисам:
  1. Я бы взял [Фамилия и имя коллеги] на работу, если бы он устраивался в компанию сейчас.
  2. Я бы взял [Фамилия и имя коллеги] в работу над сложным и срочным проектом.
  3. [Фамилия и имя коллеги] — ценный сотрудник для нашей команды.
  4. Я бы выдал [Фамилия и имя коллеги] премию, если бы распределял бюджет на это.

Скриншот ежемесячного опроса продуктовых команд

На каждый из вопросов предусмотрено три варианта ответа: «Да», «Нет» и «Не взаимодействовал». По результатам опроса продакты могут поставить вопрос об эффективности работы того или иного человека. Но никакой речи о схеме ТВ-программы «Последний герой» из нулевых не идет. Если вдруг так получилось, что в команде кто-то не прижился, чаптер-лид попытается интегрировать его в другой коллектив. Но есть условие: потенциальные коллеги должны быть готовы принять новичка.

Зачастую сыгранность оказывается важнее hard skills, именно поэтому мы выступаем за то, чтобы в рамках решения определенной задачи состав команды не менялся. Общими усилиями в комфортной атмосфере новички, по нашим наблюдениям, могут добиться бóльшего, чем разрозненные профессионалы, которые вынуждены постоянно находить общий язык с новыми коллегами.

Планы на будущее

Постоянное развитие продуктовых команд — вызов для любой компании. На первый взгляд может показаться, что если вы уже разделили клиентский путь на несколько отрезков, то дальше детализировать его невозможно. Нужно помнить о том, что чем короче этот отрезок, тем более точно можно влиять на определенную метрику, связанную с ним напрямую. В этом направлении работа в компании планируется в первую очередь. Таким образом поступательно увеличится количество продуктовых команд, а их зона ответственности будет уже.
Закон Меткалфа гласит, что полезность сети пропорциональна половине квадрата численности ее пользователей. Иначе говоря, в системе из 4 человек могут образоваться 8 типов взаимосвязей между участниками, а в цепочке с 12+ людьми количество коммуникаций переваливает за 100. В этом случае менеджерить цепочки взаимодействий становится очень сложно. Поэтому мы работаем над тем, чтобы зафиксировать число людей на 12 и не превышать предел управляемости.
2024-01-25 16:37 Разработка и продукты