Шаг за шагом: Agile-процесс валидации продукта с использованием картирования влияния

Работая над различными ИТ-проектами, я понял, что, несмотря на все эти движения по «бережливой» разработке продуктов, многие компании по-прежнему сталкиваются с серьезными проблемами в плане валидации продукта. Другими словами, людям трудно понять, является ли разрабатываемый ими продукт тем, что нужно рынку.

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

Что такое валидация продукта?

Давайте начнем с ответа на фундаментальный вопрос: что такое валидация продукта?

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

Одна из самых известных схем в этой области была представлена в книге «Бережливый стартап» Эрика Риса (вы можете найти ее в нашем списке обязательных книг для технического директора). Он предлагает следовать следующим шагам:

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

2. Измерьте результат эксперимента.

3. Извлеките урок, а затем проведите следующий эксперимент.

Что мне нравится в этом подходе, так это то, что Эрик показывает, что для того, чтобы извлечь пользу из цикла, вы должны планировать его в обратном порядке. Сначала вам нужно понять, что вы хотите узнать о своих пользователях. Затем следует подумать о том, как вы будете это измерять. И только в конце вы должны попытаться понять, как построить самый быстрый и дешевый эксперимент для получения этих знаний.

Взгляд изнутри на процесс валидации продукта в нашей команде

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

Как выглядит наш процесс валидации?

1. Фаза предварительной разработки: «как измерить?»

a) Владелец продукта (ВП) добавляет свою идею валидации к пользовательской истории.

(Не знаете, чем занимается владелец продукта? Прочитайте нашу статью об обязанностях владельца продукта). Каждый раз, когда наш PO добавляет новую пользовательскую историю в бэклог продукта, он должен заполнить поле «как измерить?». Такой подход помогает им проанализировать, до начала дальнейшего обсуждения, как определить, является ли изменение, которое мы собираемся внести, тем, что нужно нашим пользователям, и достаточно ли у нас инструментов для проверки пользовательских историй. См. снимок шаблона нашей истории пользователя ниже — это «планирование» нашей структуры.

б) Идея валидации обсуждается с другими людьми во время еженедельного совещания.

На встрече должны присутствовать владелец продукта, UX-дизайнер, Scrum-мастер и представитель клиента (по желанию).

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

2. Фаза разработки

На этом этапе не проводится никакой работы по валидации. Это «сборка» в рамках концепции бережливого стартапа.

3. Фаза после разработки: валидация продукта

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

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

Что такое карта влияния и как мы ее используем?

Помимо Jira, упомянутой в примере выше, мы используем еще один инструмент для визуализации статуса проверки продукта — карту влияния.

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

(Мы были очень рады увидеть, как сам Гойко Аджич ретвитнул эту статью вскоре после ее публикации).

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

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

Используя термины картографирования воздействия, вы должны определить 4 элемента:

1. Цель

Решите, чего бы вы хотели достичь с точки зрения бизнеса. Может быть, вы хотите достичь определенного объема продаж за определенный период времени, а может быть, вы предпочитаете сосредоточиться на количестве новых зарегистрированных пользователей. Какой бы ни была ваша цель, постарайтесь определить ее как можно точнее.

2. Действующие лица

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

3. Воздействие

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

4. Результаты

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

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

Пример того, как выглядит наша карта воздействия

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

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

Цвета результатов несут дополнительную смысловую нагрузку:

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

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

Каковы преимущества картирования воздействия?

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

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

Заключительные мысли

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

• Создание карты влияния помогает команде оставаться сосредоточенной на бизнес-целях, то есть на действиях, которые действительно создают доход.
• Она позволяет вам увидеть весь ландшафт всех возможных путей достижения вашей бизнес-цели — включая более быстрые, простые и экономически эффективные пути, которые вы могли упустить.
• Картирование воздействия открывает возможности для более творческого принятия решений; вы можете посмотреть на целые участки карты и понять, какие из них были эффективными, а каким следует уделить больше внимания.
• Всегда можно найти другой участок карты, на котором можно сосредоточиться.
• Мышление с помощью карты помогает вам оставаться мотивированными. Надеюсь, этот пост поможет вам организовать процесс проверки продукта в вашей команде. Удачи, и дайте нам знать, как все идет!