Как это устроено: продуктовый отдел, разделённый на 15 команд

Директор по продукту Учи.ру Иван Себедаш – о том, как работа небольших автономных проектных команд внутри компании способствует развитию продукта, обеспечивает рост основных бизнес-метрик в 2-2,5 раза каждый год, а также о том, как организовать такую рабочую структуру.

Гибкие (agile) команды – это глобальный корпоративный тренд. Крупные игроки на западе в последние годы берут на вооружение тактику создания автономных команд, чтобы быстро открывать новые направления и конкурировать с более гибкими инновационными компаниями за лидерство на рынке.

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

Подобные agile-команды, состоящие в среднем из 10 специалистов из различных профессиональных областей, обладая достаточной свободой принятия решений и (иногда) собственным бюджетом, добиваются большей эффективности, гибкости и скорости реализации проектов, чем если бы этим занимались крупные отделы в рамках классической корпоративной оргструктуры.

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

На Учи.ру практика автономных команд очень востребована, так как на платформе существует множество видов функционала для очень разных групп пользователей. С 2018 года в Учи.ру работает несколько независимых продуктовых команд, каждая из которых состоит из закреплённых за командой разработчиков, дизайнеров, тестировщиков, аналитиков и продакт-менеджера. Таким образом, в каждой команде сосредоточены все необходимые компетенции для развития продукта.

Самостоятельные команды, которыми руководят продакт-менеджеры, в Учи.ру занимаются развитием того или иного «участка» взаимодействия пользователя с платформой. Задача каждой группы – сделать пользовательский опыт качественнее на каждом конкретном этапе. Например, одна из команд занимается первой сессией ученика, стараясь сделать так, чтобы ребенок заинтересовался, увлекся процессом обучения и зашел на платформу вновь. Другая команда разрабатывает и внедряет соревновательные механики. Еще одна – занимается личным кабинетом учителя, в котором должно быть удобно смотреть статистику учеников, составлять и рассылать домашние задания. Индикатор эффективности работы каждой команды – достижение четких и измеримых KPI.

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

Поэтому в компаниях создаются выделенные команды, объединенные общей бизнес-целью, и (что очень важно) в любой момент времени обладают всеми необходимыми ресурсами для реализации проекта – т.е. могут не «стоять в очереди» за нужным специалистом.

Однако, и здесь есть своя крайность. Можно перестараться и сделать так, что в команде будет свой специалист на каждую бизнес-функцию: не только дизайнер и разработчик, но и юрист, и HR. Практика показывает, что не всем специалистам можно гарантировать полную занятость в рамках одной команды. Поэтому важно искать разумный баланс: кто-то может быть «на аутсорсе». К примеру, у нас в каждой такой команде есть свой аналитик. Все решения мы основываем на данных, поэтому очень много работаем с ними.

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

Процесс работы каждой автономной команды над улучшением своей части продукта состоит из нескольких этапов. Сначала мы формулируем как можно больше гипотез о том, как именно добиться улучшений. Источниками могут быть внутренние мозговые штурмы, анализ действий конкурентов, обратная связь от пользователей, обращения в техподдержку. Каждый член команды – дизайнер, аналитик, тестировщик – может предложить свою идею.

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

Есть различные варианты, как это сделать не расходуя слишком много ресурсов, например:

Чтобы точно измерить, какое из предлагаемых командой изменений в продукт дает результат, команда делает А/В-тестирование - когда новый функционал доступен, к примеру, группе B пользователей, а группе A при этом недоступен. Это дорогостоящий способ измерения, поэтому до него должны доходить только тщательно отобранные гипотезы.

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

Помимо запуска A/B-тестирования конкретных гипотез имеет смысл выделять так называемую «вечную контрольную группу», чтобы измерить эффект не от одного теста, а от всех вместе. Это даёт понимание эффективности работы команд на длительном промежутке.

Например, с сентябрь по май, за время учебного года, мы проводим много экспериментов: какие-то идут параллельно, какие-то следуют друг за другом. Допустим, эксперимент в октябре увеличил целевую метрику на 5%, эксперимент в ноябре – на 3%, а декабрьский – на 6%. К маю у нас накопился десяток успешных экспериментов, каждый из которых показал прирост в несколько процентов. Если сложить их арифметически, то может получиться прирост в 50% по метрике – однако, такая методика подсчета некорректна.

Если можно так сказать, у каждого пользователя есть «емкость» – он может совершить целевое действие (скажем, вернуться на платформу) только один раз, и сделать это по итогам лишь одного из экспериментов, даже если мотивировать его это сделать несколькими способами. И это только одна из причин, из-за которой суммарный эффект всех экспериментов обычно меньше, чем их простая арифметическая сумма.

Чтобы измерить чистый суммарный эффект деятельности команды, полученный в результате всей ее работы за год, и нужна «вечная контрольная группа». Это небольшая аудитория, которую на протяжении всего года мы намеренно не включаем ни в один эксперимент и не выкатываем на нее даже победившие варианты функционала. По ней мы смотрим, какой суммарный эффект дает вся работа по тестированию гипотез.

Если не выделять «вечные контрольные группы», то не будет достоверно известно, как работают улучшения в целом – это можно только предполагать на основе отдельных A/B-тестов. В прошлом учебном году «вечная контрольная группа» показала, что деятельность команд значительно увеличила основные бизнес-метрики и, благодаря этому мы смогли твердо обосновать увеличение количества ресурсов, выделяемого на развитие продукта.