Как организовать Discovery-процесс в работе над продуктом. Опыт Selectel
Привет! Я Аля, продакт-менеджер команды выделенных серверов. Год назад мы перешли на новый подход к выполнению исследований в продукте — Discovery-спринты. В статье расскажу об основных этапах этого процесса, трудностях при формировании методологии и идеях по ее улучшению.
Используйте навигацию, если не хотите читать текст полностью:
С чего мы начали
Чуть больше года назад мы в выделенных серверах разделили процессы на Delivery («доставка» ценности, разработка) и Discovery (исследование).
Discovery на вопросы «Надо ли делать?» и «Что делать?». Сюда попадают как большие и сложные штуки, разработка которых займет много времени, так и небольшие с точки зрения разработки фичи, но с высокими рисками — репутационными, финансовыми и т.д.
Примеры задач, которые попадают в Discovery:
- Предоставить всем клиентам безлимитный интернет-трафик с каналом 1 Гбит/с. С одной стороны, мы предполагаем, что это позволит привлечь новых клиентов, а также удержать часть текущих клиентов. С другой — существует целый ряд сетевых и финансовых рисков.
- Дать клиентам возможность апгрейдить фиксированные конфигурации, то есть менять ряд комплектующих сервера без миграции с арендованной машины. В данном случае нам было важно перекрыть «канибализацию» более премиального продукта — кастомные серверы, в которых такая возможность уже есть. Также мы хотели понять, что именно клиенты хотели бы апгрейдить в первую очередь — диски, память, процессоры или что-то еще.
- Добавление оплаты по потреблению (pay-as-you-go). Это фича, которая хорошо знакома клиентам облака, но довольно редкая для выделенных серверов. Поэтому мы хотели посчитать целесообразность добавления нового биллинга для наших клиентов.
В Discovery-команду в первую очередь входят продакт-менеджеры, продакт-аналитики и UX-проектировщики. Если же задачи технические, то подключаются тим-лиды и другие технические специалисты.
Delivery отвечает на вопрос «Как сделать?» и включает в себя все этапы разработки — от подготовки макетов до выхода в прод и поддержания фичи.
В Delivery-команду входят тимлид, фронтенд- и бэкенд-разработчики, тестировщики и UX-проектировщик, а также у каждой команды есть продакт-менеджер.
Delivery-часть в данной статье я описывать не буду — оставлю это тимлидам и командам разработки 🙂
Зачем мы сделали разделение
На это было несколько причин:
- У нас много идей и гипотез как внутри команды, так и от других отделов. Также мы хорошо и много общаемся с клиентами и получаем разнообразный фидбэк от них. Да и рынок не стоит на месте — за ним мы тоже регулярно следим. При этом ресурсы команды разработки ограничены, поэтому мы хотим приносить максимум пользы нашим клиентам, оставаясь при этом финансово успешным продуктом.
- Команда росла — становилось все больше продактов, проектировщиков и аналитиков, которые проводили исследования. Хотелось добавить прозрачности и синхронизации в исследовательской части, чтобы как минимум не дублировать друга друга и делиться знаниями и экспертизой.
В первую очередь разделение на 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-процессами, которые круто описаны в их блоге на vc.ru.
Итак, что же внутри нашего 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, а делимся знаниями и экспертизой друг с другом.
Проходили ли вы подобный путь? Поделитесь своей историей в комментариях и подпишитесь на блог Selectel, чтобы быть в курсе последних кейсов и новостей из мира IT.
Читайте также:
а на сколько увеличился time to market после появления discovery stage? как и где тестируете прототипы? Насчет оценки и приоритезации задач - RICE лучше переводить в деньги или ROI, даже если это assumption. Плюс я поняла, что в любом случае надо 20-30% спринта отдавать на техдолг и вылизывание интерфейса, потому что при любой модели скоринга такие задачи всегда будут в конце списка и останутся кладбищем тасков.
Инна, спасибо за ваш интерес к тексту!
В зависимости от задач time to market вырос примерно в два раза.
Верхнеуровневые прототипы мы можем тестировать как в рамках discovery, так и delivery. На этапе delivery, наверное, все-таки чаще. Для тестирования обычно используем User Day (подробнее о UX-исследованиях в Selectel рассказали по ссылке: https://vc.ru/services/657323-kak-obshchenie-s-polzovatelyami-pomogaet-nam-uluchshat-servisy-3-primera-svezhih-izmeneniy-ot-rebrendinga-do-novyh-fich), а также юзабилити-тестирования и коридорки.
Благодарим за совет про assumption! Возможно, чуть позже вернемся к скоринговым моделям и попробуем считать именно так. Но да, у скоринговых моделей действительно есть проблема, которую вы описали. Сейчас мы оставляем 20-30% delivery-спринта на баги, техдолг и технический ресеч. На скоринговую, как и на любую другую модель приоритизации, полагаться на все 100% вряд ли получится, т.к. у каждой есть свои преимущества и недостатки.