Как применить систему «сделал-измерил-узнал» для успешного развития продукта.

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

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

Определение «сделал-измерил-узнал»:

Сделал. Определите задачу: что, зачем и как нужно сделать.

Измерил. Отслеживайте результаты работы, выпущенной в релиз.

Узнал. Принимайте решения по результатам мониторинга работы.

В статье используются следующие термины и сокращения:

OKR — цели и ключевые результаты.

RACI — Responsible, Accountable, Consulted, Informed. См. матрицу RACI.

JFDI — неизбежное «Just F*cking Do It». Например, обнови брендинг.

Критерии утверждения — соответствие концепции продукта.

Критерии готовности — задача готова к передаче разработчикам.

Критерии завершенности — задача «готова» на этапе разработки.

Критерии релиза — задача готова к релизу.

Общий обзор

Мы работаем по двухпотоковому процессу исследования и доставки. Если коротко, это происходит примерно так:

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

Подробное описание процесса

Ниже подробно описано то, что мы делаем на каждом этапе.

1. В бэклог исследования Джиры добавляется идея (функция, оптимизация)

Идея может исходить откуда угодно (менеджеры по маркетингу, разработчики, пользователи, заинтересованные лица, анализ данных и т. д.) и должна быть основана на надежных качественных и количественных данных. В первую очередь мы стремимся понять, в чем заключается идея и почему ее нужно рассмотреть. Идеи добавляются в бэклог исследования как эпики:

Эпики позволяют разбивать функции на пользовательские истории — и таким образом увеличивать полезность продукта в каждом спринте.

Эпики добавляются в бэклог по следующему шаблону:

Гипотеза

Мы считаем, что [идея]

для [пользователя]

повысит [показатель],

потому что [ожидаемый результат].

История

Как [пользователь],

когда я [ситуация],

я хочу [мотивация],

чтобы я [ожидаемый результат].

Дизайн

Ссылка на прототип (Overflow, Invision, Figma и т. д.).

Показатели успеха

Какие будут показатели успеха? Например: повысить удержание пользователей на 5%, увеличить конверсию на 10%.

Контрольный список

✅ Подпись заинтересованного лица.

✅ Уточнение в команде.

Критерии утверждения

✅ Ясное понимание цели.

✅ Измеримые показатели.

✅ Соответствие концепции проекта.

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

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

Для расстановки приоритетов работы мы используем следующие методы:

Дорожные карты продукта.
Разнесение новых эпиков и историй по следующим категориям: 20% — поддержка, 20% — оптимизация, 60% — функции.
JFDI задачи.
Матрица приоритезации.
OKR для определения будущих функций.
Запросы заинтересованных лиц.

Когда менеджер по продукту решает, что конкретно нужно внести в спринт исследования, задача переход на канбан-доску. Выглядит это вот так:

3. Дизайнер и бизнес-аналитик вместе изучают и уточняют эпики

Для уточнения эпика используется сочетание следующих методов:

Изучение аудитории по бережливой методике.
Анализ данных.
Рабочие группы.
Уточнение в «отрядах».
Мнение заинтересованных лиц.
Быстрое прототипирование.
…и многие другие.

Методы проектирования и исследования могут быть самыми разными и зависят от предмета исследования, поэтому я не буду перечислять их все. При выборе метода мы действуем согласно общепринятым правилам.

4. Как только критерии утверждения выполнены, задача может быть перемещена в бэклог доставки

Перед началом работы необходимо выполнить следующие требования:

✅ Ясное понимание цели.

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

✅ Измеримые показатели.

Задача оценивается измеримыми показателями известным образом.

✅ Соответствует концепции продукта.

Задача очевидным образом соответствует концепции продукта.

Когда критерии утверждения выполнены, эпик может быть перемещен в бэклог доставки в Джире. Если требования не выполнены, мы не беремся за эту задачу.

5. Окончательные доработки и критерии готовности

После перемещения эпика в бэклог доставки заполняется следующий контрольный список, благодаря которому проверяется соответствие критериям готовности для будущего спринта доставки:

✅ У задачи есть пользовательская история, условия приемки и она была уточнена.

✅ Риски, предположения и зависимости задокументированы на уровне истории.

✅ Дизайн полностью закончен, привязан на уровне истории и проверен на удобство пользования.

✅ В дизайне учтено мнение разработчиков и он подписан владельцем продукта или менеджером по продукту.

✅ Вся команда провела оценку истории.

✅ Подзадачи назначены и привязаны к истории.

✅ Команда понимает цель работы.

6. Определение приоритета и перевод в спринт доставки

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

Мы используем матрицу приоритезации и методы, аналогичные тем, что упоминались при планировании исследования. Также для спринтов доставки мы разбиваем работу по схеме «20% — поддержка, 20% — оптимизация, 60% — функциональность».

7. Удовлетворение критериев завершенности

Перед релизом задачи, которая перешла в спринт доставки, должны быть выполнены следующие условия:

✅ Выполнены все условия приемки.

✅ У кода надлежащий уровень покрытия тестами.

✅ Если появляется технический долг, он должен быть зарегистрирован и отрефакторен позже.

✅ Пользовательская история подписана контролем качества.

✅ Протестированы теги событий в Firebase Analytics.

✅ Присутствует достаточное журналирование новых функций (BE).

✅ Задача одобрена отделом дизайна.

8. Удовлетворение критериев релиза

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

✅ Добавлены панели мониторинга (визуализация аналитики).

✅ Проведено нагрузочное тестирование.

✅ Одобрен запрос на изменение.

✅ Утверждены внутренние документы.

✅ Обновлен контент в App Store (скриншоты, описание, раздел "Что нового").

✅ Проведено регрессионное тестирование.

✅ Протестировано обновление приложения.

9. Отслеживание результатов работы

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

Facebook Analytics.
Sumologic.
Power BI.
Firebase.

После выпуска задачи в релиз эпик остается в столбце «Мониторинг» на доске дизайна (исследования). Выглядит это примерно так:

10. Отчетность

Какая предоставлять отчет заинтересованным лицам?

Заинтересованные лица дважды в неделю получают на электронную почту рассылку с ключевыми показателями.
В конце каждого спринта проводится обзор в рамках команды со всеми «отрядами» и заинтересованными лицами.
Демонстрационный показ задач, реализованных в спринте.
Продуктивность спринта (количество баллов истории, диаграммы выгорания).
Если делается отчет по большому объему работы, можно подготовить для заинтересованных лиц презентацию с выводами.
Решение о том, кто отвечает за отчетность, принимается в зависимости от того, кто изначально отвечал за задачу. Тут может быть также полезна матрица RACI.
Раз в две недели — контрольные встречи по отчетности с командой исследования, на которых для отслеживания работы используются таблицы.

Когда делается отчет?

Когда есть статистическая значимость*. Конкретного графика нет, поскольку это сильно зависит от отслеживаемой функции или оптимизации.

* Если результаты неубедительны, это всё равно полезные данные, поскольку мы доказали ошибочность гипотезы. Успех — это не всегда достижение показателя успеха. Главное — узнать о пользователях что-то новое.

Заключение

Наша система постоянно развивается и совершенствуется. В ее рамках используются и другие методики — например воронка AARRR и Google HEART. Понятно, что не я одна придумала используемый нами подход «сделал-измерил-узнал» — вместе со мной работала превосходная команда, которая и обеспечила успех нашего продукта.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Система «сделал-измерил-узнал»