Изучая User Story и отчеты исследований, разработчики не видят за ними реальных пользователей с их переживаниями, потребностями и образом жизни — в итоге получаются фичи, которые не попадают в целевую аудиторию. Дмитрий Соловьев, Research Lead в QIWI и автор канала «soloveev: простые вещи», рассказал, как подружить пользователей с разработчиками, распределить функции исследователей между всеми участниками команды и научиться делать полезные продукты.
Оглавление
- Зачем привлекать к исследованиям продуктовую команду
- Как подготовиться к Product Backlog Refinement с пользователями
- Что такое хорошо и что такое плохо на Product Backlog Refinement
- Выводы
Зачем привлекать к исследованиям продуктовую команду
QIWI — это экосистема, состоящая из финансовых продуктов в сфере B2C и B2B. Одна из аудиторий, с которой мы работаем — это самозанятые: водители такси, слесари, веб-мастера, программисты. Те, кто зарабатывает на жизнь, не привязываясь к одному работодателю и сам организует свой заработок. По оценкам разных экспертов они генерируют от 10 до 20% ВВП России.
Когда мы начали разрабатывать продукт для этой целевой аудитории, то столкнулись с двумя проблемами:
- Самозанятые — очень разные.
- Они не похожи на нас, потому что мы работаем в офисе, а они — сами на себя. Их поведение, потребности и мироощущение совсем не похожи на наши.
Мы не особо понимали, им нужно в продукте. Конечно, каждый легко может придумать пару десятков продуктовых функций для самозанятых — и если вы не знаете, что им нужно, это еще не означает, что у вас будет пустой бэклог. Менеджер продуктов может сказать: «Я тут недавно пил карамельный латте и вдруг придумал отличную фичу для таксистов». И здесь есть проблема — мир менеджера продуктов сильно отличается от мира водителей такси.
В среде исследователей такие идеи называются галлюцинациями. Чтобы меньше галлюцинировать, нужно понять аудиторию. Придумать фичу не сложно — сложно придумать то, что будут использовать.
Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.
Если продуктовая команда осознает эту проблему, она решает провести исследования. Однако на этом пути тоже есть проблемы:
- Время. Исследования можно делать достаточно долго — и даже увязнуть в них.
- «Испорченный телефон». Агентство или отдел внутри компании проводят исследования и приносят красивый отчет, но разработчики все равно не смогут прочувствовать и понять боли пользователей.
Между пользователями и разработчиками слишком длинная цепочка «посредников», в каждом звене которой искажается или теряется часть информации. Поэтому перед созданием любой новой фичи разработчики будут просить «опять поисследовать» — ведь они так и не смогли понять пользователей по отчетам. Это похоже на колесо сансары, из которого не выбраться.
В QIWI есть самостоятельные команды, которые работают над продуктом — фича-тимы. Вклад каждого участника очень важен — команды сами принимают много решений, а не ждут согласований от менеджера продуктов. Менеджер продуктов ставит задачу, объясняет зачем все это нужно, а команда разбирает задачу на составляющие и придумывает, как достичь цель. Очень круто, если разработчик лично выслушивает критику от пользователей, особенно когда они уходят к конкурентам и с этим нужно что-то делать. Благожелательные отзывы тоже полезно слушать и понимать, что ты все сделал правильно.
Мы в QIWI выступаем за то, чтобы исследование из отдельной специальности трансформировалось в необходимый каждому навык, который распределен по всей команде. Хорошо, когда этим навыком в равной степени обладают менеджер продуктов, программист и дизайнер. Навык исследователя — это не только умение брать интервью, но и способность принимать решение на основе данных (качественных и количественных), понимание методов, их сильных сторон и ограничений.
Для непрерывного выпуска фич команде разработки нужно понимать пользователей. Но как найти время на исследования и вовлечь коллег? Если вы придете к своей команде разработки, то им сложно будет сказать с порога: «Ребята, пойдемте проводить интервью». Скорее всего, скажут: «Интервью? Что это вообще? Зачем оно нам?» — потому что есть некая инерция и непонимание.
Решение выглядит просто и знакомо почти всем — это Product Backlog Refinement (PBR), стандартный инструмент Scrum. Многие забывают, что один из стейкхолдеров в нем — пользователь. Клиентов редко зовут на груминги, потому что это долго и дорого, но мы в QIWI считаем PBR с пользователем золотым стандартом. Этот формат позволяет очень быстро систематизировать фичи: отобрать рабочие и избавиться от ненужных.
Иногда стоит проводить большие PBR, на которых совместно с пользователями оценивается и разбирается несколько фич из беклога. Такой PBR длится 1–2 дня и в нем участвует команда разработки. За это время можно опросить 15 пользователей. Что это дает?
- Формат позволяет экономить время на исследования — обычно они длятся 3–4 недели.
- Команда становится более самостоятельной и осознанной: быстро разрешаются вопросы из серии: «Почему мы делаем то или это?». Да и каждый менеджер продуктов мечтает о самостоятельной команде.
- На выходе вы получите фичи с требованиями к реализации, которые одобрили пользователи. Их можно брать на следующий спринт и делать. При этом важно, что они будут разные: интерфейсные, клиентские — и даже идеи для новых продуктов.
Как подготовиться к Product Backlog Refinement с пользователями
Провести PBR несложно, главное — подготовиться. Для этого нужно подумать о 3 вещах: команде, пользователях и месте.
Пользователи. Мы поняли, что лучше приглашать только один сегмент, иначе вместо валидированных понятных проблем получится хаос. Зато очень классно, если вы делите сегменты на подтипы. Например, можно привлекать геймеров, которые платят на разных платформах, а на воркшоп с таксопарками мы позвали и генеральных директоров, и водителей такси, потому что решение касалось всех.
Мы пришли к выводу, что пользователей должно быть не больше, чем разработчиков — лучше даже немного меньше. В среднем от 8 до 16 пользователей при 16 членах команды — это нормальное количество.
У нас за поиск пользователей отвечал один человек, но ему помогала вся команда. Минимальное необходимое количество пользователей — 8, поэтому мы искали с запасом, 16 человек. Если бы пришли все, мы бы все равно справились с интервью. Мы платили пользователям в 2 раза больше, чем за обычное интервью, поскольку у самозанятых дневной доход достаточно солидный по сравнению со среднестатистическим человеком. Еще мы оплачивали такси до Подмосковья (воркшоп был выездной и проводили его еще до пандемии). Кстати, не стоит бояться, что пользователи из-за денег станут говорить приятные для вас вещи — они в любом случае расскажут о своих болях.
Оплатой вы компенсируете их время, помогаете добраться до места проведения интервью. Платить за участие в подобных мероприятиях — нормальная практика. Хотя некоторые приверженцы CustDev говорят, что платить респондентам ни в коем случае нельзя, на этот вопрос нет единственно верного ответа. Если ваши пользователи готовы прийти без оплаты — приглашайте их без оплаты или дарите сувениры. Однако иногда проще заплатить пользователю деньги — ведь он проведет с вами целый день, а это все-таки его время. Действуйте по ситуации, многое зависит от вашей аудитории. При этом важно, чтобы решение было единым для всех пользователей, участвующих в воркшопе — лучше не допускать, что одни получат деньги, а другие придут бесплатно.
Пользователей искали разными способами — от собственной базы до соцсетей. Очень важно искать вовлеченных людей, которые готовы делиться своими переживаниями, пользовательским опытом. Лучше перед самим мероприятиям, на этапе рекрута, провести небольшое телефонное экспресс-интервью с пользователями об особенностях использования вашего продукта. Это может быть даже пятиминутный разговор-анкетирование с вопросами о характере использования продукта, основными сложностями.
Благодаря такому интервью вы определите тип каждого пользователя и сможете отсеять тех, кому совсем нечего рассказать из-за слабого вовлечения в продукт. Молчуны вам не нужны и отсеять их на этом этапе достаточно просто — подходящие респонденты сразу начинали атаковать: «Так, сейчас я вам расскажу свои проблемы. Давайте, записывайте». Кого-то даже приходилось останавливать: «Нет-нет, подождите, приедете и расскажете».
Еще два важных момента:
- Мы сразу рассказывали, что это будет за формат, как он будет проходить, для чего это нужно.
- Мы объясняли, что это не публичная конференция, где надо выступать на сцене, а камерный формат с командой разработки. Обещали, что все будет конфиденциально и об особенностях, секретах их бизнеса никто кроме нас не узнает. Поэтому пользователи чувствовали себя в безопасности.
Команда. Мы собрали четыре команды по 4–6 человек — мини фича-тимы. В них входили разработчики, Q&A, дизайнеры, менеджеры продуктов. Они несли ответственность за решения, которые принимали, могли их реализовывать и видели продукт с разных точек зрения. Важно было привлечь вовлеченных людей, готовых к экспериментам — в первый раз они даже не совсем понимали что их ждет, но были настроены решительно.
Собирая фича-тимы, необходимо учитывать, что у вас должен быть единый бэклог, а не отдельные изолированные «дизайнерский», «технический», «бэклог пользовательского опыта» — иначе все будут говорить только о своем кусочке. На одном из наших PBR у команды не было единого бэклога — в результате за целый день мы дошли только до обсуждения проблем пользователей, но не успели найти решения. Тогда мы так и не пришли к единому знаменателю. Так что если у вас еще нет единого бэклога, будьте готовы к тому, что сможете найти проблемы, но не решения.
Место. С местом всё очень просто — это 2–3 дня вне офиса, так что просто забронируйте хорошую площадку. Учтите, что там должны быть подходящие помещения: маленькие переговорки для интервью и большой зал для общих обсуждений.
Что такое хорошо и что такое плохо на Product Backlog Refinement
Опасно выдавать разработчикам набор инструкций о проведении мероприятия. Например, мы могли сказать: «Ребята, мы придумали сценарий. Завтра вы с 10 до 12 проводите интервью, потом делаете вот это, а потом вот то». И что обычно происходит, когда вы подробно рассказываете разработчикам, что они должны делать? Они сидят с покорным взглядом: «Да, давайте, расскажите мне, как я буду дальше работать», — в итоге они просто снимают с себя ответственность.
Мы же пошли на эксперимент и сказали: «Ребята, у нас есть вот такая цель. Подумайте, как можно ее достичь», — то есть переложили ответственность за результат на команды. Им нужно было придумать собственный план, по которому они будут действовать. Конечно, мы ответили на все вопросы, обсудили главную цель. А потом произошло вот что: вдруг все ощутили личную ответственность за результат. И это немного включило команды — ребята поняли, что завтра приедут пользователи, и начали придумывать, как им с ними работать.
Это хорошо сработало, и следующий день был «заряженным». Здесь нужно понимать, что не все станут работать с таким подходом. Мы сразу всех предупреждали: «Ребята, это эксперимент», — и были готовы к тому, что нам ответят: «Нет, мы не хотим ничего сами придумывать. Мы лучше поедем домой. Спасибо, это была хорошая гостиница».
В итоге вышло наоборот — все включились в процесс, хотя некоторым командам все-таки пришлось помочь составить план дня. Когда они составляли планы, мы обсуждали их, давали обратную связь, говорили, что получится, а что — нет.
Обязательно давайте командам возможность совершить ошибки. И тут чем больше PBR вы проводите, тем лучше. Пусть лучше команда ошибется на первом из них и сама извлечет урок, чем будет ждать, когда вы скажете, что делать, а чего не делать. А после мероприятия проведите ретро, обменяйтесь опытом: что получилось, что нет — чтобы в следующий раз сделать лучше.
Всем командам мы дали единую информацию, рассказали про бизнес-модели, пользователей и организовали небольшой тренинг о том, как проводить интервью — 90% участников никогда этого не делали. Этого не надо бояться, потому что все люди так или иначе общаются со своими знакомыми — значит, смогут поговорить с пользователями, надо только немного направить их, дать ориентир.
Ошибки в интервью у тех, кто редко ими занимается, будут всегда. Первый раз его нельзя провести идеально. Поэтому хорошо, если в командах будут люди с опытом ведения — но даже если таких сотрудников нет, ничего страшного. Можно перед мероприятиям провести тренировочные интервью, хотя даже это не обязательно. Конечно, от качества проведенного интервью, зависит глубина и точность полученных проблем и желаний пользователей. Однако если и вы, и команда помните, что делаете проект не разово и у вас есть долгосрочная цель — уменьшить зазор между пользователями и разработкой — то это просто путь, который вы проходите вместе и на котором набираетесь опыта. Поэтому, если вы только начинаете проводить такие воркшопы, лучше начинать с простой аудитории и постепенно усложнять себе задачу.
В день воркшопа план у всех был примерно одинаковый: первую половину все брали интервью, вторую — придумывали фичи в командах, размышляли над проблемами вместе с пользователями и собирали обратную связь. Одна из команд на этом этапе совершила ошибку: стала подробно прорабатывать решения, составлять Use Story Map — из-за этого они не успели обсудить все фичи. Излишняя детализация не нужна, лучше в общих чертах накидать варианты решений, провалидировать их с пользователями, а потом в офисе доделать конкретные решения.
Еще одна ошибка — проводить фокус-группу вместо интервью. Фокус-группа — сложный формат для первого раза. И не все продукты можно обсудить на фокус-группе. Если ваш продукт предполагает индивидуальный опыт использования — как практически все digital-продукты — лучше проводить интервью. Фокус-группы хорошо работают для массовых понятных продуктов, где у пользователей есть общий опыт и детализации не так много, как в digital. Обычно это касается опыта потребления FMCG-продуктов.
Неопытность на фокус-группе приведет либо к тому, что один пользователь будет говорить, а остальные — молчать и скучать, либо все начнут выступать одновременно, и наступит хаос. Начинающему модератору сложно вести такие исследования, поэтому интервью должны идти параллельно минимум по часу.
Интересная выгода от PBR — этот формат работает как способ диагностики для всей команды. Вы поймете, каких инструментов вам не хватает, на каких процессах команда спотыкается, куда стоит добавить коммуникацию и как сформулировать общую цель. Воркшопы помогают выделить слабые зоны, а потом прокачать их, чтобы команда стала более осознанной и в следующий раз работала эффективнее.
Выводы
- Чтобы создавать полезные для пользователей фичи, нужно проводить исследования, но у них есть две основные проблемы: затраты по времени и отсутствие прямой связи между пользователями и разработчиками.
- В идеал навык исследований должен быть распределен по всей команде: от менеджеров продуктов до разработчиков и дизайнеров. Навык исследователя — это не только умение брать интервью, но и способность принимать решения на основе данных — качественных и количественных — понимание методов, их сильных сторон и ограничений.
- Самый простой способ объединить разработчиков и пользователей — организовать Product Backlog Refinement, на котором все будут работать в маленьких группах, находить боли и решения, а также получать обратную связь о продукте.
- Пользователей должно быть не больше, чем разработчиков. Исходите из того, что за день можно обработать 15 респондентов.
- Командам надо давать самостоятельность и возможность ошибаться — так они с большей готовностью берут на себя ответственность и быстрее учатся.
- PBR с пользователями полезны и для самой команды, потому что помогают обнаружить слабые места и сделать ее более осознанной и продуктивной.
Благодарим за подготовку статьи редактора Елену Егину.
Дмитрий ведет телеграм-канал «soloveev: простые вещи», в котором рассказывает о продуктовых исследованиях, мышлении и футурологии.
