Как применить систему «сделал-измерил-узнал» для успешного развития продукта. Последний год мне довелось в качестве продуктового дизайнера работать над потребительским мобильным приложением. Когда я присоединилась к команде, проект был на стадии готовности к масштабированию и оптимизации, поэтому нам нужна была система, которая помогла бы это организовать. Я работала в команде разработчиков платформы с бизнес-аналитиком, владельцем продукта и менеджером по продукту. Мне интересно всё, что касается процессов и эффективности, поэтому хотелось иметь широкий взгляд на наши методы работы — и в итоге всё это сложилось в систему, о которой я и расскажу. Вообще говоря, внедрить систему «сделал-измерил-узнал» можно огромным количеством способом, а при работе в гибкой среде приходится подстраиваться. Поэтому считайте эту статью набором общих принципов, которые помогут успешно развивать продукт, — это как приготовление пищи вообще и конкретно выпечка. Вы — шеф-повар, а конечная цель — сделать продукт, который понравится и к которому пользователи захотят вернуться. Сделал. Определите задачу: что, зачем и как нужно сделать. Измерил. Отслеживайте результаты работы, выпущенной в релиз. Узнал. Принимайте решения по результатам мониторинга работы. OKR — цели и ключевые результаты. RACI — Responsible, Accountable, Consulted, Informed. См. матрицу RACI. JFDI — неизбежное «Just F*cking Do It». Например, обнови брендинг. Критерии утверждения — соответствие концепции продукта. Критерии готовности — задача готова к передаче разработчикам. Критерии завершенности — задача «готова» на этапе разработки. Критерии релиза — задача готова к релизу. Мы работаем по двухпотоковому процессу исследования и доставки. Если коротко, это происходит примерно так: В бэклог исследования Джиры добавляется идея (функция, оптимизация). Владелец продукта или менеджер по продукту определяет приоритет работ, включенных в спринт исследования. Дизайнер и бизнес-аналитик вместе изучают и уточняют эпики. Как только критерии утверждения выполнены, задача может быть перемещена в бэклог доставки. Окончательные доработки и удовлетворение критериев готовности. Определение приоритета и перевод в спринт доставки. Удовлетворение критериев завершенности. Удовлетворение критериев релиза. Отслеживание результатов работы. Отчетность. Ниже подробно описано то, что мы делаем на каждом этапе. Идея может исходить откуда угодно (менеджеры по маркетингу, разработчики, пользователи, заинтересованные лица, анализ данных и т. д.) и должна быть основана на надежных качественных и количественных данных. В первую очередь мы стремимся понять, в чем заключается идея и почему ее нужно рассмотреть. Идеи добавляются в бэклог исследования как эпики: Эпики позволяют разбивать функции на пользовательские истории — и таким образом увеличивать полезность продукта в каждом спринте. Эпики добавляются в бэклог по следующему шаблону:  Гипотеза Мы считаем, что [идея] для [пользователя] повысит [показатель], потому что [ожидаемый результат].  История Как [пользователь], когда я [ситуация], я хочу [мотивация], чтобы я [ожидаемый результат].  Дизайн Ссылка на прототип (Overflow, Invision, Figma и т. д.).  Показатели успеха Какие будут показатели успеха? Например: повысить удержание пользователей на 5%, увеличить конверсию на 10%.  Контрольный список ✅ Подпись заинтересованного лица. ✅ Уточнение в команде.  Критерии утверждения ✅ Ясное понимание цели. ✅ Измеримые показатели. ✅ Соответствие концепции проекта.  Чтобы довести задачу до спринта исследования, «гипотеза» должна быть полной — так менеджер по продукту сможет определить приоритет элементов в бэклоге исследования. Для расстановки приоритетов работы мы используем следующие методы: Дорожные карты продукта. Разнесение новых эпиков и историй по следующим категориям: 20% — поддержка, 20% — оптимизация, 60% — функции. JFDI задачи. Матрица приоритезации. OKR для определения будущих функций. Запросы заинтересованных лиц.  Когда менеджер по продукту решает, что конкретно нужно внести в спринт исследования, задача переход на канбан-доску. Выглядит это вот так: Для уточнения эпика используется сочетание следующих методов: Изучение аудитории по бережливой методике. Анализ данных. Рабочие группы. Уточнение в «отрядах». Мнение заинтересованных лиц. Быстрое прототипирование. …и многие другие.  Методы проектирования и исследования могут быть самыми разными и зависят от предмета исследования, поэтому я не буду перечислять их все. При выборе метода мы действуем согласно общепринятым правилам.  Перед началом работы необходимо выполнить следующие требования:  ✅ Ясное понимание цели. Потребности бизнеса и клиентов должны быть ясны, количественно оценены и подтверждены. ✅ Измеримые показатели. Задача оценивается измеримыми показателями известным образом. ✅ Соответствует концепции продукта. Задача очевидным образом соответствует концепции продукта.  Когда критерии утверждения выполнены, эпик может быть перемещен в бэклог доставки в Джире. Если требования не выполнены, мы не беремся за эту задачу. После перемещения эпика в бэклог доставки заполняется следующий контрольный список, благодаря которому проверяется соответствие критериям готовности для будущего спринта доставки:  ✅ У задачи есть пользовательская история, условия приемки и она была уточнена. ✅ Риски, предположения и зависимости задокументированы на уровне истории. ✅ Дизайн полностью закончен, привязан на уровне истории и проверен на удобство пользования. ✅ В дизайне учтено мнение разработчиков и он подписан владельцем продукта или менеджером по продукту. ✅ Вся команда провела оценку истории. ✅ Подзадачи назначены и привязаны к истории. ✅ Команда понимает цель работы. Перед планированием спринта команда исследования встречается и определяет приоритеты того, что будет в следующем спринте доставки. Благодаря этому сеанс планирования спринта с командой доставки, который происходит на следующий день, идет эффективно. Мы используем матрицу приоритезации и методы, аналогичные тем, что упоминались при планировании исследования. Также для спринтов доставки мы разбиваем работу по схеме «20% — поддержка, 20% — оптимизация, 60% — функциональность». Перед релизом задачи, которая перешла в спринт доставки, должны быть выполнены следующие условия:  ✅ Выполнены все условия приемки. ✅ У кода надлежащий уровень покрытия тестами. ✅ Если появляется технический долг, он должен быть зарегистрирован и отрефакторен позже. ✅ Пользовательская история подписана контролем качества. ✅ Протестированы теги событий в Firebase Analytics. ✅ Присутствует достаточное журналирование новых функций (BE). ✅ Задача одобрена отделом дизайна. Мы отделили этот шаг от предыдущего, поскольку в них участвуют разные люди. Кроме того, чтобы обеспечить возможность релиза, нужно выполнить дополнительные требования:  ✅ Добавлены панели мониторинга (визуализация аналитики). ✅ Проведено нагрузочное тестирование. ✅ Одобрен запрос на изменение. ✅ Утверждены внутренние документы. ✅ Обновлен контент в App Store (скриншоты, описание, раздел "Что нового"). ✅ Проведено регрессионное тестирование. ✅ Протестировано обновление приложения. В спринте доставки используются один или несколько из следующих инструментов для отслеживания выпускаемой в релиз задачи: Facebook Analytics. Sumologic. Power BI. Firebase.  После выпуска задачи в релиз эпик остается в столбце «Мониторинг» на доске дизайна (исследования). Выглядит это примерно так: Заинтересованные лица дважды в неделю получают на электронную почту рассылку с ключевыми показателями. В конце каждого спринта проводится обзор в рамках команды со всеми «отрядами» и заинтересованными лицами. Демонстрационный показ задач, реализованных в спринте. Продуктивность спринта (количество баллов истории, диаграммы выгорания). Если делается отчет по большому объему работы, можно подготовить для заинтересованных лиц презентацию с выводами. Решение о том, кто отвечает за отчетность, принимается в зависимости от того, кто изначально отвечал за задачу. Тут может быть также полезна матрица RACI. Раз в две недели — контрольные встречи по отчетности с командой исследования, на которых для отслеживания работы используются таблицы. Когда есть статистическая значимость*. Конкретного графика нет, поскольку это сильно зависит от отслеживаемой функции или оптимизации. * Если результаты неубедительны, это всё равно полезные данные, поскольку мы доказали ошибочность гипотезы. Успех — это не всегда достижение показателя успеха. Главное — узнать о пользователях что-то новое.  Наша система постоянно развивается и совершенствуется. В ее рамках используются и другие методики — например воронка AARRR и Google HEART. Понятно, что не я одна придумала используемый нами подход «сделал-измерил-узнал» — вместе со мной работала превосходная команда, которая и обеспечила успех нашего продукта. Перевод статьи выполнен в Alconost. Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов. Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.