Температура успеха: как X5 Tech измеряет эффективность развития IT-продуктов

Привет, Хабр! На связи команда ad-hoc аналитики X5 Tech. Если вы работаете в IT, то знаете как непросто оценивать результативность развития IT-продуктов и команд. А теперь представьте, что таких продуктов у вас десятки, и решения по ним нужно принимать оперативно, ведь речь идёт о миллиардах рублей в год. В этой статье мы покажем, как в таких условиях можно быстро сориентироваться и внедрить системное решение для контроля эффективности развития продуктовых активностей. Мы назвали его “Продуктовый градусник”. Статья будет полезна продуктовым менеджерам, аналитикам, разработчикам и руководителям, которые хотят улучшить свои продукты, процессы и команды, основываясь на проверенных практиках и data-driven подходе.

Цели продуктового градусника
Важно отметить, что мы стремились создать не просто инструмент для измерения эффективности продуктов, а полноценного помощника в управлении продуктами. Мы выделили четыре направления, в которых он помогает:

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

2. Определение вектора развития для продуктов. Мы не просто выявляем проблемы и точки роста продукта, но и предлагаем ценные рекомендации по процессам, что помогает владельцу продукта сформировать план продуктового развития. Это возможно благодаря нашему опыту в ad-hoc аналитике и лучшим практикам компании, которые мы перенимаем при оценке продуктовых активностей.

3. Выявление системных проблем, которые нужно решать на уровне всей компании. Похожие проблемы могут возникать в разных продуктах, и их решение на глобальном уровне будет более эффективным по затратам и результатам.

С учётом этих целей инструмент используют как владельцы продуктов и delivery-менеджеры, так и CTO (технические директора), и топ-менеджмент.

Зачем нужен «Продуктовый градусник», если продукт и так себя окупает?

Показатели окупаемости (IRR, NPV, ROI) показывают только факт возврата инвестиций. Но по ним нельзя судить, достиг ли продукт своего максимального потенциала.

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

Именно поэтому мы выделили 7 блоков, по которым оцениваем продукт:

1. Бизнес-здоровье

2. Атмосфера в команде

3. Роадмап

4. Взаимодействие команды с владельцем продукта

5. Оценка архитектуры данных

6. Бизнес-анализ

7. Эксплуатация ML-моделей в продукте

Блоки 2, 3, 4 относятся к группе Delivery и помогают оценить, насколько качественно устроены процессы в продукте.

Для наглядности раскроем подробнее каждый блок на синтетическом примере продукта «Доставка товаров на дом» для торговой сети с физическими магазинами. 

Блок 1. Бизнес-здоровье

Он позволяет комплексно оценить бизнес-эффективность продукта, проверяя три его ключевых составляющих:

• корректность замера и экстраполяции эффектов на финансовые метрики;

• риски негативного влияния на финансовые или ключевые показатели компании;

• репрезентативность продуктовых метрик по отношению к бизнес-целям продукта и наличие их мониторинга.

Всё это кажется очевидным, но в каждом из этих пунктов скрываются свои тонкости оценки. 

Начнём с вводных, которые нам предоставил владелец продукта «Доставка товаров на дом». Допустим, что схема расчёта финансового эффекта для продукта выглядит следующим образом: 

• Year-over-Year выручка в приложении «Доставка товаров на дом». 

• Системы разделения клиентов на группы для тестирования фичей нет.

Также владелец продукта считает репрезентативным следующий набор продуктовых метрик:

• Общая база пользователей приложения

• DAU/MAU

• Конверсия из посещения приложения в заказ

• Средний чек клиента в приложении

• Рейтинг приложения в магазинах приложений

• NPS пользователей приложения

Мониторинг продуктовых метрик в BI-инструментах отсутствует. Система оповещений о значимых отклонениях метрик не настроена.

Очевидная бизнес-цель заключается в увеличении выручки за счёт покупок в приложении. Допустим, владелец продукта отчитывается о хороших результатах, показывая рост выручки онлайн-заказов Year-over-Year. Однако, можем ли мы ответить на два вопроса:

• Точно ли этот прирост обусловлен развитием продукта?

• Получает ли компания дополнительную выручку в целом?

Конечно, использовать Year-over-Year очень рискованно, так как на прирост влияет множество факторов помимо развития продукта, а именно: органический рост сети и e-commerce, активность конкурентов и т. д. Более того, оценивая эффективность только по онлайн-заказам, мы не ответим на второй вопрос. Положительный прирост выручки онлайна мог быть обусловлен перетеканием клиентов из офлайн-магазинов, что не даёт суммарной дополнительной выручки для компании.

Теперь дадим рекомендации продукту «Доставка товаров на дом» 

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

Здесь, конечно, наша команда ad-hoc аналитики окажет полную поддержку и сопровождение на каждом этапе жизненного цикла экспериментов (подробнее о том, как мы тестируем гипотезы в X5, наши коллеги рассказали в статье). Но начинать нужно с внедрения функционала разделения пользователей на группы. 

Перейдём к оценке репрезентативности продуктовых метрик

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

Напомним, что в продукте отсутствует система оповещения об аномальных значениях метрик, что может привести к серьёзным потерям. Представим такую гипотетическую ситуацию: однажды утром у части клиентов перестала работать оплата, и конверсия из посещения пользователем приложения в совершение заказа снизилась на 15%. Поскольку системы оповещений нет, проблему заметили бы только через два дня, а ещё один день потратили бы на исправление. За это время компания потеряла бы 15% заказов и столько же клиентов, что привело бы к значительным финансовым потерям и репутационным рискам. Допустим, для крупного приложения доставки товаров дневная выручка составляет 100 млн рублей. Тогда потери составили бы около 10-15 млн рублей в день или 30-45 млн рублей за время обнаружения и устранения бага приложения.

Итак, «Бизнес-здоровье» оценили, рекомендации даны, пора переходить к следующим, не менее важным блокам — Delivery.

Блок 2. Атмосфера команды

Для любого менеджера важно понимать настроение своей команды, и для этого полезны анонимные опросы. Почему же стоит тратить рабочее время на такую, казалось бы, мелочь?

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

Блок 3. Роадмап

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

Проблемы, которые могут встретиться в продуктовом роадмапе:

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

2. Отсутствие связи с таск-трекером приводит к разрыву между стратегическим планированием и повседневной работой. Это приводит к путанице, замедлению процессов и снижению эффективности.

3. Неполное покрытие направлений и стримов создаёт риск того, что важные направления развития будут упущены или недостаточно проработаны.

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

Блок 4. Взаимодействие команды с владельцем продукта

В определённый момент может возникнуть ситуация отрыва владельца продукта от своей команды — таски мутятся, значит, всё классно! К сожалению, это не всегда так. Фокусируясь на других аспектах, со временем владелец продукта может перестать:

• согласовывать цели с командой;

• обсуждать роадмап и связь выполняемых задач с ним;

• совместно планировать спринты и оценивать сроки разработки.

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

Блок 5. Оценка архитектуры данных

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

Часто никто особо не заморачивается с архитектурой данных — выгода от этого не сразу видна. Но со временем хаос в данных, источниках и ролевой модели приводит к множеству проблем:

• Растут расходы на хранение данных, разработку и исправление багов.

• Увеличиваются риски появления ошибок из-за проблем с данными.

• Высокая вероятность принятия ошибочных решений на основе недостоверных данных.

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

Оценка блока «Архитектура данных» позволяет продуктовым командам:

• Выявлять и устранять слабые места в работе с данными.

• Повышать эффективность и качество продукта.

• Снижать расходы и риски.

• Принимать более обоснованные и стратегические решения.

Блок 6. Бизнес-анализ

Блок позволяет измерить качество применения бизнес-анализа в продуктовых командах. 

Примеры критериев: понимание бизнес-аналитиком целей и метрик продукта, актуальность описания бизнес-процессов.

Какие проблемы могут быть выявлены по результатам оценки:

• Размытые зоны ответственности между командами. В этом случае границы ролей становятся неясными, что приводит к путанице в распределении задач.

• Отсутствие фильтрации и приоритизации задач перед планированием. Если задачи проходят через единую воронку, это ускоряет достижение целей.

• Бизнес-процессы либо не описаны вовсе, либо описаны только на старте продукта. 

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

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

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

 Блок 7. Эксплуатация ML-моделей в продукте

В любой крупной компании ML-модели стали неотъемлемой частью развития бизнеса. Как отмечает Владимир Салахутдинов, первый заместитель генерального директора X5 Group, дополнительная EBITDA от применения ML-моделей в компании составляет около 5 миллиардов рублей. В таких условиях управление рисками моделей становится критически важным. Основные меры для минимизации этих рисков включают:

• Стандартизацию разработки и эксплуатации ML-моделей.

• Мониторинг и управление модельными рисками.

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

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

8. Результаты применения Продуктового градусника (на примере синтетического продукта сервиса доставки)

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

 По итогу оценки всех блоков мы предоставляем владельцу продукта результаты с указанием выявленных проблем и рекомендациями по их решению в следующем формате:

Мы оцениваем результат по 100-балльной шкале по каждому из направлений. Средневзвешенная оценка всех блоков отражает интегральную оценку. В зависимости от её значения делается общее заключение касательно продукта (“плохо” — красная зона, “удовлетворительно” — жёлтая зона, “отлично” — зелёная зона).

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

Помимо владельца продукта, результаты оценки получают CTO (технические директора, у нас в Х5 Tech их сейчас 9) и бизнес-заказчики инициативы. Выполнение рекомендаций, повышение интегральных оценок продуктов и обратная связь стейкхолдеров — показатель качества методологии нашего инструмента.

9. Подведение итогов оценки всех продуктов Продуктовым градусником

По итогам каждого полугодия мы формируем сводную аналитику по всем оценённым продуктам. Для менеджмента она выглядит примерно так:

На левом графике мы видим распределение интегральных оценок по продуктам. Для красной зоны (Продукты 7, 8, 10) выстраивается план действий по корректировке критических проблем под наблюдением CTO. 

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

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

В таком случае задачу стоит решать глобально:

1. Организовать обучение владельцам продуктов по выстраиванию продуктовых гипотез и продуктовой аналитики.

2. Усилить найм продуктовых аналитиков в команды, повысив требования к компетенциям кандидатов.

3. Организовать обучающие митапы от команды ad-hoc по теме “Построение гипотез и их проверка средствами A/B-тестирования”.

4. Сформировать рабочую группу из опытных сотрудников ad-hoc, которые будут консультировать продуктовые команды по аналитике и гипотезам.

   После полугода активного использования инструмента хотелось бы поделиться результатами:

Что же нам дал “Продуктовый Градусник” ?

• Масштабное улучшение показателей: Большинство продуктов повысили свою оценку эффективности. Части продуктов “хорошистов” удалось попасть в “зеленую” зону спустя всего полгода работы над выявленными проблемами и точками роста. 

• Объединение команд и обмен опытом: Владельцы успешных продуктов стали менторами для коллег, что ускорило общее развитие и внедрение лучших практик.

• Фокус на ключевых проблемах: Анализ тепловой карты показал основные проблемы, затрагивающие большинство продуктов. Мы оперативно отреагировали,  дали необходимые рекомендации, провели обучающие митапы и спустя полгода ситуация с выявленными проблемами значительно улучшилась.

Внедрение продуктового подхода в команды. Появление Градусника привело к формированию Центра Продуктового Развития, миссией которого является путь продуктовой трансформации компании. В рамках него уже запущены сервисы по подбору продуктовых метрик, формированию гипотез, проведению discovery, и это лишь малая часть предстоящих инициатив! 

Подведём итоги

• Мы рассказали, какой инструмент позволит вам комплексно оценивать эффективность развития IT-продуктов в крупных компаниях.

• Поделились, какие блоки включает наш инструмент и объяснили на примерах важность каждого из них.

• Описали, как можно применять результаты оценки на практике как продуктовым командам, так и топ-менеджменту компании. 

• Показали, как инструмент позволяет владельцам продуктов обмениваться опытом и сутью своих инициатив. Это помогает находить новые точки роста через совместные проекты.

• Подчеркнули, что X5 Tech и команда ad-hoc придерживаются data-driven подхода и рекомендуют вам делать то же самое.

Авторы:

Гаврилова Анастасия — DA/DS X5 Tech

Полушкин Андрей — Team Lead ad-hoc X5 Tech

Сахнов Александр — Head of DA/DS X5 Tec