Как применить систему «сделал-измерил-узнал» для успешного развития продукта.
Последний год мне довелось в качестве продуктового дизайнера работать над потребительским мобильным приложением. Когда я присоединилась к команде, проект был на стадии готовности к масштабированию и оптимизации, поэтому нам нужна была система, которая помогла бы это организовать. Я работала в команде разработчиков платформы с бизнес-аналитиком, владельцем продукта и менеджером по продукту. Мне интересно всё, что касается процессов и эффективности, поэтому хотелось иметь широкий взгляд на наши методы работы — и в итоге всё это сложилось в систему, о которой я и расскажу.
Вообще говоря, внедрить систему «сделал-измерил-узнал» можно огромным количеством способом, а при работе в гибкой среде приходится подстраиваться. Поэтому считайте эту статью набором общих принципов, которые помогут успешно развивать продукт, — это как приготовление пищи вообще и конкретно выпечка. Вы — шеф-повар, а конечная цель — сделать продукт, который понравится и к которому пользователи захотят вернуться.
Определение «сделал-измерил-узнал»:
Сделал. Определите задачу: что, зачем и как нужно сделать.
Измерил. Отслеживайте результаты работы, выпущенной в релиз.
Узнал. Принимайте решения по результатам мониторинга работы.
В статье используются следующие термины и сокращения:
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.