Discovery-процесс в продукте: из подземелья незнания — к лучшим решениям

Привет! Я Аля — продакт-менеджер в Selectel. Сегодня расскажу про наш Discovery-процесс в команде выделенных серверов. Он описывает, как мы подходим к вопросам, что нам нужно реализовать в продукте и действительно ли это нужно.

Недавно исполнился год, как мы перешли на Discovery- и Delivery-спринты. В тексте пройдемся по лабиринтам именно Discovery-процесса: расскажу, с какими «монстрами» мы столкнулись, пока выстраивали работу, и как с ними боролись. Спойлер: суммой цифр на игральных костях с ними не справиться.

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

Дисклеймер

Чуть больше года назад мы в выделенных серверах разделили процессы на Delivery («доставка» ценности, разработка) и Discovery (исследование).

Discovery в первую очередь отвечает на вопросы «Надо ли делать?» и «Что делать?». Сюда попадают как большие и сложные штуки, разработка которых займет много времени, так и небольшие с точки зрения разработки фичи, но с высокими рисками — репутационными, финансовыми и т.д.

Примеры задач, которые попадают в Discovery:

• Предоставить всем клиентам безлимитный интернет-трафик с каналом 1 Гбит/с. С одной стороны, мы предполагаем, что это позволит привлечь новых клиентов, а также удержать часть текущих клиентов. С другой — существует целый ряд сетевых и финансовых рисков.
• Дать клиентам возможность апгрейдить фиксированные конфигурации, то есть менять ряд комплектующих сервера без миграции с арендованной машины. В данном случае нам было важно перекрыть «канибализацию» более премиального продукта — кастомные серверы, в которых такая возможность уже есть. Также мы хотели понять, что именно клиенты хотели бы апгрейдить в первую очередь — диски, память, процессоры или что-то еще.
• Добавление оплаты по потреблению (pay-as-you-go). Это фича, которая хорошо знакома клиентам облака, но довольно редкая для выделенных серверов. Поэтому мы хотели посчитать целесообразность добавления нового биллинга для наших клиентов.

В Discovery-команду в первую очередь входят продакт-менеджеры, продакт-аналитики и UX-проектировщики. Если же задачи технические, то подключаются тим-лиды и другие технические специалисты.

Delivery отвечает на вопрос «Как сделать?» и включает в себя все этапы разработки — от подготовки макетов до выхода в прод и поддержания фичи.

В Delivery-команду входят тимлид, фронтенд- и бэкенд-разработчики, тестировщики и UX-проектировщик, а также у каждой команды есть продакт-менеджер.

Delivery-часть в данной статье я описывать не буду — оставлю это тимлидам и командам разработки 🙂

Зачем мы вообще сделали разделение?

1. У нас много идей и гипотез как внутри команды, так и от других отделов. Также мы хорошо и много общаемся с клиентами и получаем разнообразный фидбэк от них. Да и рынок не стоит на месте — за ним мы тоже регулярно следим. При этом ресурсы команды разработки ограничены, поэтому мы хотим приносить максимум пользы нашим клиентам, оставаясь при этом финансово успешным продуктом.
2. Команда росла — становилось все больше продактов, проектировщиков и аналитиков, которые проводили исследования. Хотелось добавить прозрачности и синхронизации в исследовательской части, чтобы как минимум не дублировать друга друга и делиться знаниями и экспертизой.

В первую очередь разделение на Delivery и Discovery работает для клиентских стримов, а именно — для направлений, задача которых — добавление новой ценности для клиентов и улучшение пользовательского опыта. Но пару месяцев назад к нам присоединилась Internal команда, которая отвечает за опыт внутренних пользователей Selectel — инженеров, менеджеров по продажам, менеджеров услуг и т.д. Теперь ребята тоже проходят через похожие процессы.

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

Прежде чем погрузиться в Discovery-процесс, покажу, как выглядит наш D&D-процесс целиком. На схеме ниже он представлен крупными этапами, внутри Jira статусы движения задач по процессу разбиты более мелко.


Все наши идеи, фидбэк и задачи попадают в бэклог, который мы разбираем на регулярной встрече (Sorting). На встрече мы решаем, куда отправить конкретную идею (item) — в Discovery, Delivery или вообще в Rejected (сюда уходят задачи, которые мы точно не будем брать в работу в ближайшие 3-6 месяцев).

После того как задачи попадают в Discovery Backlog или Delivery Backlog, мы их приоритизируем и в соответствии с приоритетами берем в работу. Подход к приоритизации в Discovery и Delivery отличается, дальше расскажу про приоритизацию Discovery чуть подробней — это был, пожалуй, одна из самых «веселых» частей выстраивания процесса.

После окончания работ в Discovery мы принимаем решение, что делать с задачей дальше — отправить ее в Delivery или в «корзину» (rejected). Иногда задача уходит обратно в Discovery, если полученных результатов недостаточно для принятия решения и требуется что-то доисследовать.

Что внутри Discovery-процесса

В Discovery мы живем спринтами, средняя продолжительность спринтов — примерно три недели в зависимости от месяца.

В отличие от привычных Scrum-спринтов мы оставляем несколько дней между спринтами Делаем это, чтобы скорректировать процессы, научиться чему-то новому и просто перевести дух после спринта.

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

Хочется также отметить, что мы во многом вдохновились продуктовыми процессами Авито, особенно Discovery-процессами, которые круто описаны в их блоге на Хабре.

Итак, что же внутри нашего Discovery-спринта.

Pre-planning

Наш Discovery-спринт начинается со встречи Pre-planning.

Цель встречи: отобрать шорт-лист исследований для дискавери-спринта, а также определить ответственных за эти исследования.

Как проходит встреча. Все члены команды приносят свои исследования и питчат их на встрече. В зависимости от стрима требования к обоснованию исследования отличаются. Также на pre-planning попадают исследования, которые мы не успели завершить в прошлом спринте.

На данный момент у нас четыре стрима, или направления исследований:

• Revenue stream. В этот стрим входят задачи, влияющие на выручку. Обоснование исследования должно строиться через метрики, а именно — как мы потенциально сможем вырастить основную метрику. Как минимум должна быть представлена логическая связь. Но круче и наглядней, если инициатор идеи представит салфеточные расчеты.
• UX stream. Сюда входят задачи, влияющие на клиентский опыт. Обоснование должно включать ответ на основной вопрос: почему мы считаем, что это важно для пользователей? В качестве обоснований могут использоваться фиды от клиентов, выводы из других исследований (например, интервью, где мы часто слышали, что пользователям что-то неудобно), анализ решений конкурентов, общепринятые паттерны и т.д. Мы предполагаем, что данный стрим напрямую не влияет на выручку, поэтому обоснование может не включать эту метрику. Здорово, если такая связь все-таки показана, — это особенно ценно для крупных исследований и потенциальных изменений.
• Strategic stream. В этот стрим входят задачи, направленные на формирования стратегического видения продукта, а именно — исследования трендов, конкурентов, новых клиентских сегментов и т.д. Для обоснования задачи из этого треда необходимо рассказать, почему мы видим это исследование важным в разрезе стратегического развития продукта. Например, если мы исследуем новый сегмент, то отвечаем на вопрос, почему мы вообще видим важным его исследовать, что нам это может дать и т.д.
• Internal stream.Тут рассматриваются задачи, результатами которых пользуются сотрудники Selectel. Для обоснования необходимо рассказать, на какие группы сотрудников ориентировано исследование и почему мы вообще считаем важным его провести.

На какие грабли мы успели наступить в этой части процесса

• На Pre-planning были приглашены только продакт-менеджеры. От этой идеи мы отказались, так как у других участников команды не оставалось пространства для продвижения своих идеи (если только через описание в Jira). Это сильно влияло на мотивацию вообще что-либо предлагать.
• Не было никаких инструкций для подачи идеи своего исследования. Ребятам было сложно обосновать актуальность своего исследования, так как были непонятны ожидания, которые к ним предъявлялись. В итоге мы очень много реджектили из-за слабого обоснования, а это снова снижало мотивацию что-либо предлагать. Поэтому мы добавили небольшие описания с примерами, как можно подать свою идею. В результате количество идей исследований и качество обоснований существенно выросли.
• На этой же встрече мы сразу старались максимально проработать дизайн исследования. Поняли, что это неэффективно, так как в исследовании участвует обычно 1-3 человека, а Discovery-команда в разные моменты времени достигала 10+ участников. В итоге получалось, что большая часть команды теряла заинтересованность, пока 1-3 человека вели жаркую дискуссию в части методологии и других технических деталей. Так у нас появились отдельные встречи — Research Team Discussion, на которых рабочие группы готовят дизайн исследование, а после презентуют дизайн на Planning. Про обе встречи я расскажу подробней.

Так, стоп, а где приоритизация?

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

Почему же все-таки не фреймворк? Мы попробовали ICE и RICE в чистом виде, модернизировали их под себя, пробовали Кано и еще ряд других фреймворков. Но все они не учитывают зависимости, которые так или иначе нам важны. В случае со скоринговыми моделями получалось, что нам стоит работать над маленькими и понятными изменениями, а большое и сложное нужно оставить на потом. Не всегда хороший подход, особенно если мы хотим быть лучшими в своем деле.

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

Идеи по улучшению

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

Research Team Discussion

Цель встречи: подготовить дизайн исследования и сформировать таймлайн.

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

Обычно у рабочих групп есть 2-4 дня на обсуждения. При необходимости группы могут собираться больше одного раза, но обычно хватает одной встречи.

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

На какие грабли мы успели наступить в этой части процесса

• Оставляли всего один день на обсуждение. Этого не хватало, так как. один человек может быть вовлечен сразу в несколько исследований. Кроме того, у нас также есть задачи и встречи по Delivery. Так что теперь мы закладываем 2-4 дня на дизайн исследований.
• Очень расходимся в понимании того, что такое «гипотеза» и как какие гипотезы проверять. Нам еще предстоит пофиксить эту часть. Как минимум планируем запилить воркшоп, на котором потренируемся формулировать гипотезы и отличать гипотезы от фактов и идей.

Идеи по улучшению

Из ближайших планов — воркшоп по формулированию и работе с гипотезами.

Planning

Цель встречи: зафиналить набор исследований, или скоуп, дискавери-спринта и запустить спринт.

Как проходит встреча. Каждая мини-группа презентует дизайн исследования, а команда испытывает его на прочность: задает вопросы по дизайну, выбранному методу исследования, целевой аудитории и т.д. В итоге формируется обновленная версия дизайна исследования. После чего мы смотрим на весь наш скоуп и определяем, сможем ли мы это сделать или нужно что-то выкинуть из скоупа. Для полноты картины мы также на встрече подсвечиваем, какие задачи из Delivery объемные и затрагивают нашу производительность в рамках Discovery.

После встречи. Владелец исследования создает необходимые задачи в Jira. После того как задачи созданы, запускаем спринт.

На какие грабли мы успели наступить в этой части процесса

• Оставляли слишком много задач, даже если понимали, что скорей всего не успеем. Сейчас жестче режем скоуп, ограничивая число исследований. Лучше качественно сделать одно, чем начать три и не закончить.
• Брали в спринт плохо проработанные исследования. Например, пару раз мы потратили около 3 месяцев на огромные исследования, которые ни к чему не привели, потому что мы плохо обозначили цели и не проработали методологию. В итоге пришли ко встречам Research Team Discussion, где продумываем дизайн исследования, а также стали чаще отправлять дизайн исследования на доработку, а не брать в спринт со словами «По ходу разберемся».
• Игнорировали Delivery задачи. В итоге брали сильно больше, чем можем совокупно сделать. Сейчас мы при планировании также учитываем и Delivery задачи, в которых участвуют члены команды Discovery.

Идеи по улучшению

Думаем попробовать прикрутить оценки, чтобы точней оценивать реалистичность скоупа. Но, возможно, мы стабилизируем процесс, и оценка будет излишней.

Sync

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

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

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

На какие грабли мы успели наступить в этой части процесса

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

Demo

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

Как проходит встреча. Владельцы исследований по очереди презентуют результаты и рассказывают про дальнейшие шаги. Участники демо задают уточняющие вопросы или дают рекомендации.


Часть презентации с последнего Demo.

На какие грабли мы успели наступить в этой части процесса

• Было сложно найти записи и презентации демо. Чтобы это исправить, собрали их в одном месте. Сделали страницу в Confluence, где есть краткое описание исследований, представленных на демо, а также ссылки на презентацию и запись. Теперь любой заинтересованный сотрудник может быстро найти интересующие его материалы.
• Не было структуры презентации: команде было сложно готовить презентацию, а слушателям — понять контекст и выводы. Как решение, сформировали шаблон презентации, в который добавили базовые слайды с описанием, которые должны быть представлены в любом исследовании — например, контекст и предпосылки, выводы, дальнейшие шаги.

Идеи по улучшению

Начать делать анонсы до демо и звать больше продакт-менеджеров, проектировщиков и аналитиков из соседних команд.

Retro

По завершению спринта мы проводим ретро — еще одна хорошо знакомая многим церемония.

Цель встречи: поделиться впечатлениями и обсудить прошедший спринт — что было хорошо, а что не очень и нужно исправить.

Как проходит встреча. Ретро начинается с обзора прошлых action item. Что мы сделали, что не сделали и почему, все ли идеи до сих пор для нас актуальны — контекст мог поменяться, а item — перестать быть важным.

Далее говорим спасибо людям, которые особенно помогли в этом спринте, а также делимся на доске Miro, что, на наш взгляд, было круто и хочется оставить, а что было не очень и хотим исправить. После мы группируем все стикеры из «было не очень и хотим исправить» и голосуем за самые важные и горящие. Обычно у каждого человека есть 2-3 голоса.

Голосуем мы только тогда, когда есть довольно большое количество штук, которые надо бы исправить, но обсудить и тем более поправить мы все не сможем. Далее для стикеров с наибольшим количеством голосов обсуждаем action items, или по-русски — как можно поправить, а также выбираем ответственных и определяем сроки.

На какие грабли мы успели наступить в этой части процесса

• Обсуждали все и сразу. В самом начале процесс был максимально далек от идеала, так что проблемных мест было так много, что мы не успевали обсудить и пофиксить их. В итоге пришли к голосованию (по сути приоритизации) проблем. Это помогло сфокусироваться на самых важных и болезненных моментах и исправить сначала их.
• Забивали на определение ответственных и сроки у action items. Очень быстро поняли, что так не работает, и начали выбирать ответственных и обозначать сроки. Сейчас мы редко теряем action items — не забываем и не забиваем на них.
• Ретро были какие-то пластиковые и одинаковые. В итоге добавили часть со «спасибо». Также на каждом ретро разными способами «оцениваем» прошедший спринт — например, с каким фильмом/сериалом он у нас ассоциируется. Стараемся добавлять небольшим забавные элементы и разнообразить ретро.

Что происходит после ретро. Как и писала выше, мы оставляем себе несколько дней после ретро на восстановление, выполнение action items и поиск вдохновения для нового спринта. В роли action items могут выступать самые разные вещи: подготовить шаблон презентации для демо, посмотреть всей командой полезную лекцию по JTBD, перейти на новый формат документации. В общем, все, что делает наши процессы лучше из спринта в спринт.

После этого начинается новый спринт с pre-planning.

Полезные статьи

   

Заключение

Несмотря на то, что наш Discovery-процесс все еще далек от идеала, мы успели сделать много классных исследований, которые помогли нам сделать упор на важном и ценном для клиентов, в том числе запустить целую кучу полезных экспериментов, которые раньше казались нам нереальными в нашем B2B. Также прозрачность в части исследований значительно выросла — теперь мы не проводим исследования в своих приватных пространствах в Confluence, а делимся знаниями и экспертизой друг с другом.

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