Когда никто не отвечает за исследования, но они нужны

В маленьких продуктовых командах обычно все делают всё. Один дизайнер рисует интерфейсы, параллельно занимается дизайн‑системой. Продукт менеджер «тонет» в операционке с разработкой. Исследования? Да, конечно, нужны. Но почти всегда «потом».

тот самый Кот, который считает себя экспертом, и оставляет все исследования на "потом". — тот самый Кот, который считает себя экспертом, и оставляет все исследования на «потом».

Тем временем пользователи сталкиваются с непонятными флоу, отваливаются на ключевых этапах и пишут в поддержку: «А как мне создать подключение?»

Но что, если наладить исследовательский процесс без отдельного человека, без денег и без долгих согласований? Это возможно — и именно об этом эта статья.

Я расскажу, как мы внедряли Research Ops в Клаудмастер и чего удалось добиться. Всё началось с моей инициативы: я начал продвигать идею Research Ops внутри команды. На следующий день от CPO Клаудмастер приходит сообщение:

«Абби, а чего у нас там по исследованиям? Как будем дискавери внедрять?»
— Станислав Быков, CPO, Клаудмастер

Продукт существует на рынке 5 лет, но в текущем виде — последние 2 года, с момента моего присоединения к команде. Потребность в исследованиях возникла естественно: отсутствие клиентов в продукте = невозможность пройти этап Problem‑Solution Fit. Клиенты заходили в триал, но продукт их потребности не закрывал. Надо было выяснить: что не так и чего им не хватает.

Три хаоса в исследованиях, которые мешают маленькой команде развиваться

Пример стратегии по исследованиям. Повторяющимся, стабильным и запланированным.

Если перед вами стоит задача получать инсайты из разных типов исследований (стратегических, тактических, операционных), нужно выйти из режима «хаоса». Вот что чаще всего мешает:

1. Знания теряются
Вы уже проводили интервью, смотрели метрики, общались с клиентами. Но всё разрозненно. В результате вы исследуете одно и то же каждый раз заново.

2. Всё начинается с нуля
Нет шаблонов. Каждый созвон или тест — как экспромт. Это пугает и тормозит процесс. Исследования откладываются, потому что «сложно».

3. Выводы не влияют на продукт
Фидбек где‑то есть, но он не превращается в гипотезы и задачи. Команда продолжает работать интуитивно.

Что такое Research Ops и почему это не только для корпораций.

Я опираюсь на модель Research Ops от Nielsen Norman Group. В отличие от Re+Ops, популярной в сообществе ResearchOps.community (и работающей в условиях масштабных команд и целых департаментов), подход NN/g позволяет выстраивать инфраструктуру в условиях ограниченных ресурсов.

Research Ops по NN/g включает:

Управление рекрутингом и фидбеком — где и как искать респондентов.
Хранение знаний — как и где систематизировать результаты.
Шаблоны и инструменты — шаблоны интервью, опросов, карточек синтеза.
Пропаганда инсайтов — как команда узнаёт про выводы исследований.

Главное — не «делать ресерч ради ресерча», а создать простую инфраструктуру, где фидбек превращается в инсайты, а инсайты — в решения.

Research Ops от Nielsen Norman Group — **Research Ops от Nielsen Norman Group**

Что можно сделать уже сегодня: минимальный Research Ops

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

1. Сформируйте пространство для планирования задач

Мы использовали Kaiten. Сделали свимлайны: «Проблема» и «Решение». Задача начинала путь с формулирования ценности проблемы, затем валидировалась, превращалась в гипотезу ценности решения, и после проверки — в PBI, а затем уже на PBR к команде или превращалась в несколько новых задач, которые проходили такой‑же путь.

Путь проблемы от идеи до сформированной и подтверждённой гипотезы, трансформированной в гипотезу решения и провалидированная, готовая как PBI

2. Создайте простое хранилище знаний

Вместо сложных баз данных подойдёт:

Notion или Confluence;
Miro или FigJam;
Google Docs.

Пример структуры:

Реализуйте подобную структуру в любом удобном для вас инструменте.

Важно: пусть всё будет просто. Не оформляйте как «на конференцию». Главное — чтобы это работало как база знаний для команды.

3. Завести шаблоны

Шаблоны — это не бюрократия, а способ снять лишнюю нагрузку в подготовке.

Примеры:

Шаблон интервью — с типовыми вопросами и вводной.
Шаблон синтеза инсайтов — «Что узнали?», «Почему это важно?», «Как это может повлиять на продукт?».

Список форматов фидбека — юзабилити‑тест, интервью, фидбек из чатов, саппорт и т. д.

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

Один шаблон = минус 3 дня подготовки и стресса с согласованиями.

4. Делитесь результатами.

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

«Инсайт недели» в корпоративном чате
Карточка задачи в таск‑трекере с цитатой из интервью
Один слайд на ревью спринта
Раз в 2 недели — дайджест: что узнали, на что это повлияло

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

Как не скатиться в бюрократию

Маленькая команда — не повод заводить «реестр интервью.xlsx» или протоколы созвонов. Чтобы не создать монстра:

Не документируйте всё подряд. Только то, что влияет на решения.
Делайте отчёты в любом удобном формате: скрины с аннотациями, голосовые, mind map — главное, чтобы команда поняла.

Как убедить команду, что это важно

Настоящий Кот-эксперт, пришёл к команде с аргументами. — Настоящий Кот‑эксперт, пришёл к команде с аргументами.

Аргумент 1: Мы экономим время

Исследование не отнимает время — оно экономит время. Один инсайт может «похоронить» 3 фичи из беклога за ненадобностью клиентам.

Аргумент 2: У нас будет чем объяснить решение

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

Аргумент 3: Мы быстрее выходим на результат

Меньше гипотез — больше проверенных идей. Клиенты получают то что действительно закрывает их потребность. Команда работает осознаннее и увереннее.

Кейс: как мы сделали Research Ops “на коленке”

Постепенно на протяжении нескольких спринтов мы начали плавное внедрение Research Ops и стали получать уже первые результаты, поняли как скорректировать процесс, как улучшить методики. Оставалось дело за малым, искать респондентов среди DevOps и CTO IT‑компаний, но это наверное оставлю для следующей статьи, там «спецэффекты» были не менее интересные.

Так вот результаты через месяц работы:

Настроенный трекинг гипотез проблем и решений;
Собрано единое хранилище знаний в Confluence;
Начали распространять инсайты команде.

И ещё через месяц:

Команда начала сама запрашивать инсайты;
Фидбек стал аргументом в планировании;
Один из инсайтов (по рекомендательной системе для Yandex Cloud) помог утвердить мнение о целесообразности реализации и приоритизировать фичи, которые увеличили Retention;
Получили много других инсайтов, которые помогли сделать продукт консистентнее, а также привлечь внимание и сконвертировать респондентов в клиентов продукта.

Вывод: Research Ops — это привычка, а не должность

Минимальный исследовательский процесс может быть:

неформальным
дешёвым
асинхронным

Но он должен быть.

Храните знания. Делайте шаблоны. Делитесь выводами.
И уже через месяц вы перестанете работать вслепую.

Research Ops в маленькой команде: как наладить процесс без бюджета и отдельной роли