Как мы перешли на Discovery-процесс в продукте и что из этого вышло

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

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

Дисклеймер

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Retro

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

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

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

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

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

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

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

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

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

Заключение

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