Усилия монопродуктовых компаний сосредоточены вокруг одного продукта или сервиса. Однако не ждите, что команда мечты появится у вас уже завтра по щелчку пальцев. Для слаженной работы над продуктом важен грамотно подобранный состав участников, правильное распределение ролей в процессе разработки, а также четко продуманный набор компетенций для каждого. Каким образом организовать работу, если у вас 16 продуктовых команд, и все они работают над созданием и развитием одного проекта? Сейчас расскажу.
При организации процесса продуктовой разработки можно пойти тремя путями:
Создать и поддерживать эффективную работу нескольких кросс-функциональных команд сложно. Но если напротив каждого из пунктов ниже вы поставите галочку, возможно, это ваш вариант.
К этим задачам нужно подходить с двух сторон: продукта и стека технологий в компании.
Во-первых, стоит понять, на какие смысловые части можно разделить продукт: подумайте, какие этапы клиентского пути можно выделить. Далее за каждой продуктовой командой закрепите определенный отрезок, за который она будет отвечать.
К примеру, в нашем случае CJM начинается с этапа активации, то есть с момента скачивания и установки приложения до первой ставки. Следующая команда ведет пользователя от первого до третьего пари, другая отвечает за возвращение клиента на седьмой день. Можно подумать о детализации. Например, мы отдельно выделили команду социальных механик, так как в нашем продукте присутствует функциональная составляющая.
Во-вторых, может существовать несостыковка между фронтендом и бэкендом с технической точки зрения: появляется набор систем и компонентов, которые нужно улучшать. В этом случае становится понятно, специалист какого профиля необходим, к примеру, на этапе активации.
GetCourse: что это такое и как работать
Казалось бы, достаточно разделить разработчиков на кросс-функциональные команды во главе с product owner, определить их состав, распределить роли, — и готово. Но не все так просто.
Существуют сложности во взаимодействии между командами. В процессе внедрения Agile-подхода на уровне одной команды, даже если их 400, все понятно. Большинство крупных компаний ломаются, когда пытаются масштабировать свой подход к взаимодействию команд.
Во-первых, могут возникнуть технические трудности. Важно развести команды так, чтобы они могли работать изолированно друг от друга. Продукт не должен быть монолитной базой, ведь в этом случае ошибка одной из продуктовых команд может затронуть зону ответственности другой. Займитесь изолированной архитектурой по блокам: регистрация пользователей, платежи, заключение пари и так далее. В этом случае каждая команда будет существовать в зоне своей ответственности, и микросервисная архитектура не позволит сломать весь продукт, если кто-то ошибется в рамках своего модуля.
Во-вторых, непродуманные инженерные практики могут помешать качественному клиентскому опыту. Решите, каким образом происходит сборка, какие ветки используются, по каким тестовым контурам идет проверка.
«Наша DevOps команда с нуля создала новую инфраструктуру с тремя разными средами разработки. Каждая из них находится на собственном Kubernetes кластере. Сегодня для создания новой среды разработки нам требуется 2 часа, конечная цель — сделать это в один клик. В центре разработки находятся принципы двенадцати факторов и Cloud Native (программный подход к созданию, развертыванию и управлению современными приложениями в средах облачных вычислений). Наша QA-команда (quality assurance-команда / команда по обеспечению качества) старается максимально автоматизировать процесс тестирования, так как сложность и глубина проверок разработки в средах отличается. Большое внимание уделяется нашему CI/CD (Непрерывная интеграция / Непрерывное развертывание), который совершенствуется день за днем. Отмечу, что в разработке не существует конечного этапа, после которого можно считать, что команда добилась успеха. Постоянное развитие — то, что драйвит и заставляет двигаться вперед », — комментирует Марин Путникович, главный архитектор компании «Лига Ставок».
«Наша DevOps команда с нуля создала новую инфраструктуру с тремя разными средами разработки. Каждая из них находится на собственном Kubernetes кластере. Сегодня для создания новой среды разработки нам требуется 2 часа, конечная цель — сделать это в один клик.
В центре разработки находятся принципы двенадцати факторов и Cloud Native (программный подход к созданию, развертыванию и управлению современными приложениями в средах облачных вычислений). Наша QA-команда (quality assurance-команда / команда по обеспечению качества) старается максимально автоматизировать процесс тестирования, так как сложность и глубина проверок разработки в средах отличается. Большое внимание уделяется нашему CI/CD (Непрерывная интеграция / Непрерывное развертывание), который совершенствуется день за днем.
Отмечу, что в разработке не существует конечного этапа, после которого можно считать, что команда добилась успеха. Постоянное развитие — то, что драйвит и заставляет двигаться вперед », — комментирует Марин Путникович, главный архитектор компании «Лига Ставок».
В-третьих, непонимание взаимосвязи между метриками может помешать качественной оценке. В случае монопродуктовой компании сложно изолированно понять степень влияния релиза одной фичи на один конкретный показатель, поэтому важно научиться считать эффективность каждой команды. Изначально нужно хотя бы на бумаге обозначить метрики и зоны ответственности и внедрить практику проверки фич. Этот процесс должен быть организован только через A/B-тестирование. Проверяться должны все показатели на определенный процент аудитории. Кроме того, каждую из команд стоит оценивать независимо.
Самоощущение каждого человека в отдельности так же важно, как и эффективность работы всей команды в целом. Нужно понимать, что тунеядству и лени в продуктовых командах места нет. Важно получать фидбэк от каждого члена команды, чтобы держать руку на пульсе и грамотно оценивать, насколько комфортно и эффективно взаимодействие между людьми.
Именно поэтому каждый месяц мы собираем обратную связь от команд по нескольким тезисам:
Скриншот ежемесячного опроса продуктовых команд
На каждый из вопросов предусмотрено три варианта ответа: «Да», «Нет» и «Не взаимодействовал». По результатам опроса продакты могут поставить вопрос об эффективности работы того или иного человека. Но никакой речи о схеме ТВ-программы «Последний герой» из нулевых не идет. Если вдруг так получилось, что в команде кто-то не прижился, чаптер-лид попытается интегрировать его в другой коллектив. Но есть условие: потенциальные коллеги должны быть готовы принять новичка.
Зачастую сыгранность оказывается важнее hard skills, именно поэтому мы выступаем за то, чтобы в рамках решения определенной задачи состав команды не менялся. Общими усилиями в комфортной атмосфере новички, по нашим наблюдениям, могут добиться бóльшего, чем разрозненные профессионалы, которые вынуждены постоянно находить общий язык с новыми коллегами.
Постоянное развитие продуктовых команд — вызов для любой компании. На первый взгляд может показаться, что если вы уже разделили клиентский путь на несколько отрезков, то дальше детализировать его невозможно. Нужно помнить о том, что чем короче этот отрезок, тем более точно можно влиять на определенную метрику, связанную с ним напрямую. В этом направлении работа в компании планируется в первую очередь. Таким образом поступательно увеличится количество продуктовых команд, а их зона ответственности будет уже.
Закон Меткалфа гласит, что полезность сети пропорциональна половине квадрата численности ее пользователей. Иначе говоря, в системе из 4 человек могут образоваться 8 типов взаимосвязей между участниками, а в цепочке с 12+ людьми количество коммуникаций переваливает за 100. В этом случае менеджерить цепочки взаимодействий становится очень сложно. Поэтому мы работаем над тем, чтобы зафиксировать число людей на 12 и не превышать предел управляемости.
Хочу получать интересные новости блога
29 декабря 2022
16 января 2023
Нажимая на кнопку, вы даете согласие на обработку своих персональных данных