Исследование потребностей пользователей в заказной разработке

Как показывает опыт, 1С начинает активно вкладываться в идею прототипирования, работы с discovery, исследованием пользователей и их мышлением. При этом я неоднократно слышал мнение от специалистов 1С, что CustDev – это просто глубинные интервью. Коллега вовсе однажды сказал, что CustDev – это «маленький рот и большие уши». И это правда, но не вся.

Продуктовое мышление как ключ к клиенту

Выделяют несколько видов мышления: системное, проектное, продуктовое. В чем смысл продуктового мышления как явления?

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

Есть несколько основных подходов к разработке продуктов:

• Продукториентированные подходы: System engineering, Technology readiness level, жизненный цикл инноваций

• Сквозные: Waterfall, Agile, Scrum…

• Клиенториентированные подходы: дизайнерское мышление, Lean Startup и, наконец, СustDev.

Мы поговорим именно про Customer Development.

Что такое CustDev

Считается, что саму идею CustDev создали Стив Бланк – в большей степени; и Эрик Рис, который дополнял. Сама технология описана в двух книгах: «4 шага к озарению» и «Бизнес с нуля». В первой Бланк описывает идею Customer Development, а Рис расширяет ее с точки зрения lean-стартапа, бизнес-моделирования и т. д.

В основе CustDev заложены следующие принципы:

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

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

3. В технологии четыре итерации – discovery, validation, creation, building. Для каждой из стадий есть свои инструменты. О том, как проходит стадия discovery – расскажу в кейсе.

4. В офисе нет фактов – всё, что вы предположили, вы предположили у себя в голове. Это значит, что идеи нужно идти и проверять.

CustDev не ограничивается собственно Customer Development. Это большая структура, когда мы от идеи или проблемы нашего клиента создаем минимально жизнеспособный продукт (MVP), проверяем его на клиентах, строим бизнес-модель и масштабируемся. 

В реальности CustDev не совсем методика работы с пользователями, это методика создания бизнеса. В этом плане в Силиконовой долине огромное количество стартапов, которые разрослись, в том числе до стадии единорогов. То есть компаний, которые привлекают миллиардные инвестиции. И они шли ровно по этим стадиям.

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

В CustDev есть понятие «pivot» – когда думали, что продукт будет направлен на одно, а он оказался совершенно про другое. Например, изначально YouTube планировался как сайт знакомств. Вероятно, разработчики предположили, что пользователи будут загружать видеоролики, чтобы посмотреть на потенциального партнёра. Но оказалось, что пользователям стало интереснее загружать свои видео и смотреть ролики других пользователей. Разработчики сделали «pivot», перепроверили MVP и в итоге пришли к тому продукту, который существует сейчас.

Традиционно в рамках 1С мы крутимся на позиции стартапа. Если же заказное решение, превращается в полноценный, развивающийся и масштабируемый продукт, то мы идем на стадии, которые касаются Customer Creation и Company Building, но пока нас интересуют первые две стадии.

Когда нужен CustDev

СustDev – это не только интервью, не только выявление «боли» клиента. Это более широкая система создания бизнеса на основе тех самых первичных проблем пользователей.

CustDev пригождается нам в нескольких ситуациях:

• При создании продукта на уже существующем рынке. Вам надо понять, что это за рынок, кто ваши потенциальные клиенты, и что у них болит;

• При создании продукта на новом рынке. Это ситуация, когда рынка еще нет. Например, когда создавался 1С-Коннект, на рынке не было похожего продукта: так, чтобы вставить флешку в компьютер и удаленно подключаться к техподдержке. Нужно было понять, насколько это взлетит у потребителей ;

• Продукт уже есть, и его нужно улучшить. Представьте, что у вас уже есть продукт, «1С:Бухгалтерия», 1С:ERP, и теперь нам нужно адаптировать продукт под клиента.

Для начала мы выявили заинтересованные стороны, стейкхолдеров с позиции приближенности к продукту с помощью фреймворка Onion model («Луковица).

В центре находится продукт. Далее – поддерживающая система и ожидания тех, кто будет эту систему поддерживать. Клиент должен отнести сюда службу поддержки, IT и т. д.

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

А дальше начинается этап исследования.

Исследование аудитории

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

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

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

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

Проблемные интервью

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

Есть несколько базовых правил:

1. Определить, кто является целевой аудиторией.

2. Составить план интервью. Аналитик часто приходит к клиенту, взаимодействует с ним, но интервью проходит хаотично. У него нет плана, не на что опираться. Когда мы сравниваем интервью с разными группами пользователей, то часто выясняем, что собрали некоррелируемые между собой данные, так нельзя.

3. Количество интервью (в идеале 8-10).

CustDev подразумевает, что нам не нужны ожидания пользователей от системы, нам нужны общие боли пользователя. Вот вам лайфхак, простой, как две копейки: вопросы в таком интервью должны начинаться со слов: «Опишите», «Поделитесь», «Объясните», «Расскажите мне». Ключевая задача – понять, что за проблему клиент хочет решить.

Проблемное интервью – это долгие беседы, в среднем 40-60 минут. Столько времени нужно, чтобы вытащить больше инсайтов.

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

Решенческие интервью

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

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

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

Итак, решенческие интервью помогают определить, готов ли клиент использовать продукт с предложенной вами функциональностью.

Еще одна хорошо работающая вещь – A/B-тесты

Мы выбрали часть целевой аудитории и разделили ее на два блока. Первой показывают один интерфейс, второй – другой. Каждая группа тестирует «свой» интерфейс, а затем, по ряду параметров, голосованием выбирают лучший. «Победителя» запускают в работу.

Количественные опросы

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

Если вы помните, мы внедряли 1С:ERP в компании, которая работала в нескольких регионах России. Мы внедряем решение в одном подразделении, а потом выясняем, как оно будет работать в других регионах и подразделениях, с другими пользователями.

На этом этапе можно работать с опросниками. Для этого мы использовали три метрики:

• NPS – приверженность продукту. Мы узнаем у пользователя, стал бы он советовать нашу систему в соседних компаниях, и как бы он ее оценил. Если оценка на уровне максимальной – спросите, что понравилось. Если средняя – узнайте, что можно улучшить. Если оценка неудовлетворительная – узнайте, почему оценка оказалась такой низкой.

• CSI – насколько важны для клиента характеристики продуктов.

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

На основании этих данных мы можем развивать наш MVP, выпустить продукт и тиражировать его на остальные подразделения.

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART Анализ & Управление в ИТ-проектах.

Также рекомендуем посмотреть мастер-класс.