Почему данные могут лгать — и как узнать правду о продукте с помощью гембы
Привет, я Андрей Осягин — менеджер продуктов в направлении Недвижимость от Авито. Иногда мы можем строить неверные гипотезы на основе корректных данных.
Чтобы вы не совершали таких ошибок, расскажу, как нестандартным способом найти проблемы и точки роста для продукта. Узнаете, что такое гемба, как её проводить и почему при разработке B2B-продукта нужно обязательно выходить и тестировать продукт там, где с ним работают. Статья будет полезна менеджерам в сегменте B2B, продактам, проджектам, и C-level руководителям.
Гемба или гэмба (яп. 現場) — понятие, которое означает, что для принятия верного решения нужно лично прийти на место работы с продуктом. Задача: увидеть всё своими глазами, чтобы найти ошибки и проблемы, а затем разобраться с ними.
В каких ситуациях выход «в поле» — важная часть разработки
Многие продукты рождаются и развиваются в «пузыре» — из удалёнки или офисного кабинета. Это не очень здорово, потому что с таким подходом многие решения могут опираться на ошибочные предположения. Дашборды и графики покажут проблему, но не причину, поэтому выглядеть всё будет отлично, но пользователи будут страдать. Объясню на примерах.
Проблема есть, но дашборды не помогают. Например, у нас был случай, когда аналитика не показывала реальных проблем в работе агентов по недвижимости. Продукт — кабинет, в котором проходят сделки. У нас был дашборд, с помощью которого отслеживали эффективность работы. Примерно такой ↓
Дашборд показывал, что процесс идёт и проблем нет. Но в какой-то момент показатели изменились и столбцы дашборда приняли странную форму. Какие выводы сделали бы вы, если увидели такое состояние? ↓
Если бы мы начали решать проблему из офиса, то опирались бы на ошибочную гипотезу, что не так с конверсией из нового лида во встречу. Вместо этого поехали в агентство, чтобы на месте разобраться, в чём дело.
Выяснилось, что менеджеры в агентстве недвижимости нашли способ искусственно переводить сделку из одного этапа в другой. Так они получали возможность связаться с клиентами напрямую, а конверсия во встречу оказалась на уровне 99%.
Авито стремится максимально защищать данные клиентов, поэтому стало ясно, что подход надо пересмотреть: закрыть существующую лазейку для менеджеров, и при этом не создать новых.
💧Пользователи как вода, найдут обходной путь и реализуют такой нежелательный сценарий, что найти его можно только через гембу. Сценарий может произойти случайно либо умышленно, ради дополнительной выгоды.
Проблемы нет, но есть неочевидные точки роста. Например, мы проводили исследования на месте, когда запускали онлайн-сделки с недвижимостью. Было известно, что менеджеры тратят на подготовку к сделке два часа и проводят её за 40 минут. Казалось, что это нормальные показатели, но мы хотели удостовериться в этом.
Мы приехали в офис к менеджерам и несколько дней наблюдали за их работой. За это время стало ясно, что показатели очень далеки от нормы. На столе у каждого менеджера стояло по два монитора, на которых в разных системах и браузерах были открыты десятки вкладок, параллельно менеджеры умудрялись что-то делать в смартфонах. У одного из сотрудников был блокнот, в который он вписывал ID сделки, дату и время, когда надо связаться с клиентом. И это при том, что у него есть доступ к автоматизированной CRM!
После гембы мы собрали список с заметками и конкретными действиями, проскорили его и смогли сократить время на подготовку с 2 часов до 30 минут, а на сделку с 40 до 15 минут.
Как общаться с пользователями на интервью
Гемба подразумевает, что исследователь будет разговаривать с пользователями на тему проблем и недовольства интерфейсами. И, конечно, пользователи могут отзываться о продукте грубо, поскольку будут высказывать претензии.
Очень важно держать в голове, что все слова относятся к продукту, а значит, надо не принимать их близко к сердцу и оправдываться, а продолжать расспрашивать. Более того, неприятные высказывания — это признак, что вам говорят правду, а это главное. Правда поможет исправить продукт и сделать его лучше.
Иногда пользователи начинают жаловаться не только на ваш продукт, но и на всю платформу в целом, поскольку воспринимают вас как представителей компании. Их можно понять, нужно выслушать и зафиксировать проблемы, но не стоит принимать на свой счёт всё услышанное.
Эффект наблюдателя. Это понятие из физики, которое гласит: наблюдение за объектом изменяет его. Такое может происходить во время гембы. Пользователи могут по любой причине попытаться скрыть сложности и сделать вид, что всё хорошо. Не переживайте на этот счёт. Если процесс не оптимизирован — это будет видно. Вы заметите неестественное напряжение и «тупку» в работе.
Чтобы уловить нюансы, которые отражают мелкие неудобства, нужно тренировать насмотренность. Возможно, первые одна-две гембы пройдут чуть сложнее и напряжённее, чем хотелось бы, но в дальнейшем вы научитесь видеть такие вещи с лёгкостью.
Как правильно проводить гембу и обрабатывать результаты
Если провести процедуру неправильно, можно поссориться с коллегами и не получить никаких инсайтов. Чтобы этого не произошло, делюсь некоторыми рекомендациями.
Идеальное время. Существует несколько благоприятных периодов для выезда «в поле»:
📌 Перед или после внедрения серьёзных изменений. Это позволит убедиться, что всё работает так, как вы задумали.
📌 Если в продукте возникли проблемы по неизвестной причине. Гемба поможет разобраться: кто виноват и что делать.
📌 Когда вы запустили новый продукт — это возможность увидеть, что им пользуются так, как вы задумывали или открыть для себя новые сценарии.
Также я рекомендую выезжать «в поля» с некоторой регулярностью, чтобы не отрываться от реальности.
Гембу лучше проводить в первой половине дня, потому что все ещё бодры, а пользователь готов к сотрудничеству. Исследованию можно уделить не более 1,5–2 часов. Можно потратить их сразу, либо разбить на спринты по 50 минут. Затем надо сворачиваться, потому что внимание притупляется и дальнейшая работа будет неэффективной.
Оптимальный коллектив. «В поле» лучше ехать группой не более 3—4 человек, иначе гемба превратится в балаган, и сфокусироваться на проблеме не получится.
Обработка результатов гембы. В первую очередь нужно быстро сделать выжимку из материалов, потому что примерно через неделю вы не вспомните, почему пользователи ругались на эту кнопку и ту форму.
Самый простой способ ускорить обработку, это воспользоваться помощью искусственного интеллекта. Я всегда записываю встречи на диктофон и пишу видео, затем отдаю всё на транскрибацию и в конце суммаризирую текст. Так быстро получаю выжимку.
Рекомендую вам поступать также, но предварительно обязательно спрашивать у пользователя разрешение на съёмку и запись аудио.
❗ Гемба — это работа с объективными данными. Поэтому в записях важно избегать интерпретаций. Не «менеджер медленно работает», а «менеджер делает семь кликов». Если описать своё видение проблемы вместо фактов, можно потерять причину проблемы.
Подведение итогов. Всю информацию, которую вы выжали из материалов, а также остальные заметки нужно обязательно структурировать. Если этого не сделать, обязательно часть информации потеряется, а вы начнёте действовать хаотично.
Чтобы структурировать результаты, я рекомендую собрать таблицу. Запишите туда всё, что заметили во время гембы, отметьте, почему это важно, и прикрепите атрибуты — фото и видео. Также зафиксируйте идеи и к каждому пункту назначьте ответственного.
Распределение задач и ответственности. Когда вы вернётесь с гембы — у вас будет множество заметок, из которых вы сформируете список действий и приоритизируете их. При этом не все замечания будут относиться к вашей команде. Например, баг в интерфейсе — это вопрос к разработчикам, дырявый процесс — к продуктовой команде, проблемы с данными — к аналитикам. Это значит, что просто забрать всё себе не получится — придётся договариваться и доносить информацию до других команд.
Люди страшно не любят, когда их учат, как надо жить. Особенно если это делает человек, слабо знакомый с их работой. Поэтому, если вы просто подойдёте к разработчику и скажете, что у него корявый код, в лучшем случае на вас странно посмотрят. Чтобы такого не было, делюсь двумя способами, как корректно донести до других команд, что в продукте есть проблемы по их части.
📌 Общая встреча. Собираем всех вовлечённых коллег и вместе разбираем находки гембы. Так вы быстро увидите реакцию и распределите ответственных по задачам.
📌 Через руководителей. Вы встречаетесь с тимлидами и рассказываете о проблемах им, а дальше все задачи спускаются к исполнителям.
Главное на этом этапе — чтобы напротив каждой заметки в вашей таблице появились имя, фамилия и статус по задаче. Если этого не сделать — таблица так и останется сборником заметок в столе, а не шагом к действию. Важно регулярно возвращаться к таблице и проверять статусы по задачам. Вы можете делать это самостоятельно, в качестве драйвера инициативы, а можете делегировать проектному офису, если он есть у вашей компании.
Бонус: как не поссориться со всеми
Чтобы не испортить отношения с коллегами и не спровоцировать конфликт, надо действовать аккуратно. Рекомендую следующий метод.
Заранее находите в своих заметках чувствительные моменты. Затем наедине обсуждаете их с владельцем процесса в стиле: «Заметили, что вот это решение работает вот так, как ты считаешь, как это можно исправить?»
Так вы переходите в область совместного поиска решений и уходите от негативной коннотации — критики. Задача — объяснить, что ваша цель — улучшать продукт, а не раскритиковать текущее решение. Если проблема мешает пользователю и бизнесу, её надо решить, даже если это неудобно.
Не надо сглаживать углы, если проблема мешает пользовательскому опыту или ухудшает бизнес-показатели, но важно преподнести информацию аккуратно. Если сделать это грамотно — команды не будут сопротивляться, а захотят принять участие в решении проблемы. Гемба будет восприниматься не как докучливое обязательство, а как шаг к позитивным изменениям в продукте.
Вместо резюме
👉 Гемба — отличный метод, чтобы найти проблемы в продукте. Он позволяет увидеть то, что не могут показать дашборды.
👉 Во время проведения гембы нужно сфокусироваться на проблеме, но при этом не принимать негатив на свой счёт.
👉 Чтобы правильно провести гембу, нужно выбрать оптимальное время, затем быстро обработать результаты исследования и назначить ответственных для решения выявленных проблем.
👉 Сообщать о проблемах нужно аккуратно, иначе можно поссориться с коллегами.
Уже пробовали эту практику у себя в компании? Расскажите в комментариях, как это было? ↓