Привет, читатель! Меня зовут Артём Сайгин, я веду телеграм-канал Growth lab, в котором делюсь опытом роста IT-продуктов.

В этом материале вы узнаете о методе построения эффективного и непрерывного конвейера экспериментов. Метод я разрабатывал и тестировал на протяжении шести лет, работая с growth-командами и сам будучи growth-менеджером — он создавался постепенно из огромного количества проб и ошибок.

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

Приступим.

Дисклеймер

Метод создан с целю роста IT-продуктов через рост velocity (число экспериментов в единицу в времени) и не применим под другие цели, как разработка продукта и т.д.
В данном материале я не углубляюсь в детали (как проводить митапы, планирования, как балансировать нагрузку и т.д ), полагая, что читатель поймет куда копать, так как основной набор фреймворков будет дан. Если будет необходимо —> подготовлю дополнительные материалы.

VelocityBoost

VelocityBoost — это метод, объединяющий три модуля в единый цикл, цель которого — увеличить количество и качество проводимых экспериментов, влияющих на рост вашего продукта.

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

Давайте рассмотрим глоссарий основных «сущностей» VelocityBoost, то из чего он состоит.

Из чего состоит метод:

module — совокупность фреймворков, процессов и правил для работы над выделенным блоком.
idea — процесс непрерывной генерации идей, объединяющий разные методики и инструменты.
ideas hub — инструмент работы с идеями в growth-команде.
hypothesis — процесс валидации и скоринга гипотез.
expt — структурированное хранилище проведённых экспериментов, а также здесь выполняются основные работы с гипотезами: приоритезация, фиксация статусов и результатов.
workspace — набор инструментов планирования и коммуникации внутри команды.
status — площадка, где регулярно публикуются результаты команды для всех заинтересованных лиц (смежников, заказчиков и т.д.).
growth cycles — ограниченные временные периоды, в течение которых команда фокусируется на достижении цели. Подразделяется на два цикла — long и short.

Ознакомившись с основными «сущностями» метода, давайте посмотрим, как будет выглядеть структура данного материала.

В первую очередь подробно разберём из чего стоят модули и какой инструментарий имеют, далее обозначим основные трудности, с которыми вы можете столкнуться при их реализации. И в завершение посмотрим как модули и инструменты взаимодействуют в рамках short growth cycle.

Но прежде чем перейти к разбору модулей, поближе познакомимся с циклами.

Growth cycle

Long growth cycle — шестимесячный отрезок времени, во время которого команда целенаправленно движется к поставленной цели в выбранном перед стартом направлении.

Шесть месяцев — достаточный срок, чтобы показать значимый эффект в росте продукта от всех проведённых экспериментов и достаточный для эффективной и сконцентрированной работы команды.

Перед стартом long-цикла:

Выбирается направление (к примеру, работа с новыми пользователями продукта), в котором будет развёрнут конвейер экспериментов.
Определяются метрики — North Star для всей команды и декомпозиция метрик (проксиметрики) под каналы.
Фиксируется количественная цель (target) на время long-цикла — target должен быть связан со стратегическими целями продукта/компании, т.е команда не должна начинать работу над ненужной компании целью.
Формируется выделенная под проект growth-команда или собирается v-team (т.е сотрудники, которые не 100% времени работают над вашим проектом, а делят его с другим направлением).
Настраиваются инструменты и готовится инфраструктура.

Long growth cycle включает в себя 12 short growth cycle и 1 freeze-период, давайте подробнее разберём что это:

Short growth cycle

Двухнедельный цикл, в рамках которого команда проходит путь от первого к третьему модулю. Не все эксперименты завершаются в том же short-цикле, где и запустились (в среднем от запуска до завершения проходит 3 недели) — это нормально.

Концентрируемся на запуске новых экспериментов, а как завершится предыдущий — изучаем результаты, интерпретируем (масштабируем или откатываем) и ищем новые точки роста в полученных данных.

Short growth cycle (first)

Первый из двенадцати short-циклов отличается от остальных и поэтому выделяется отдельно. Отличие состоит в том, что в нём неактивен блок «status» из третьего модуля.

В первые две недели работы «конвейер экспериментов» только запускается, и показывать обычно нечего, т.к результаты первых экспериментов начинают поступать к 3-4 неделе, как раз ко второму short-циклу.

Со второго short-цикла активируем «status» и оповещаем всех заинтересованных о запуске — теперь результаты growth-команды можно будет отслеживать там.

Freeze

Двухнедельный интервал перед началом нового long-цикла. Команда останавливает все модули и «перезагружается» — проводятся ретро-встречи, рефакторинг процессов и командные growth-сессии, направленные на определение новых направлений, где будет «развёрнут» VelocityBoost (возможно, направление останется прежним).

Если после окончания первого long-цикла направление меняется, к примеру, сменился фокус работы с новых пользователей на предотток, или с b2c на smb и т.д., то freeze может быть продлён до момента готовности команды к запуску.

Под новое направление готовится инфраструктура, пересобирается команда. Команда обычно состоит из 5 человек. В ней обязательно есть growth-менеджер, отвечающий за весь процесс и также «работающий руками» над экспериментами, как и другие участники команды.

Остальные участники собираются под нужные направлению компетенции, к примеру, это могут быть: crm-маркетолог, performance-менеджер, аналитик, дизайнер, фронтенд-разработчик и др.

Для получения большего эффекта от VelocityBoost я рекомендую проводить два long-цикла на одном «направлении».

С циклами разобрались, перейдём к модулям.

module I

Цель первого модуля — настроить непрерывный поток генерации идей с постоянным улучшением их качества.

Сложность (или преимущество — как посмотреть) работы с первым модулем VelocityBoost заключается в том, что чем дольше вы работаете в данной методологии, тем сложнее будет «добывать» новые идеи, но с каждым новым циклом идеи будут всё лучше и нетривиальнее.

Из личной практики знаю, что за первые месяцы работы с VelocityBoost вы израсходуете все «запасы» идей, и если не выстроить грамотную работу в данном модуле, то через некоторое время возникнет дефицит идей, а в конечном счёте и остановка всего «конвейера экспериментов».

Инструментарий

Ideas Hub — единое пространство для работы с идеями, выделенной growth-команды. Ниже подробнее разберём инструмент.
Брейнштормы под отдельные категории идей (к примеру шаги в воронке, каналы и т.д.) — 1-часовая встреча раз в 2 недели, к которой участники предварительно готовятся.
Ideas slot — осознанное выделение времени на обдумывание и поиск новых точек роста каждым членом команды. Подразумевает под собой выделенный еженедельный слот в календаре и договорённость о числе идей от каждого участника за N-период времени (к примеру, каждый должен добавлять в хаб идей по 1-2 идеи в неделю).
Cleanup meeting — ежемесячная командная встреча для актуализации идей в ideas hub.
ideas frame — небольшой фрейм, помогающий структурировать процесс генерации идей. Он охватывает порядка 99% всех источников новых идей для роста вашего продукта. Ниже кратко опишу инструмент, т.к под полное его описание нужно выделять полноценную статью.

ideas frame

Я долго собирал закономерности в процессе генерации идей, и в конечном счёте получилась такая «рамка» (ideas frame), как попытка снижения хаоса и упорядочивания процесса.

Ideas frame состоит из трёх основных «сущностей», которые отражают подход к поиску идей — кратко опишу их:

Source №1 — первый источник, объединяющий три блока, которые генерируют порядка 99% всех идей:

Exchange of experience — обмен опытом с командами из других продуктов/подразделений/агентств и т.д.
Marketing/Product Data — всевозможные данные, собранные из качественных и количественных исследований (касдевы, маркетинговая/продуктовая/поведенческая аналитика, пользовательский фидбэк и т.д.).
Industry Information — конференции, блоги, статьи на релевантных площадках и т.д.

Review — валидация идей на качество перед добавлением в хаб идей.

Source №2 — источник, объединяющий два косвенно связанных с генерацией идей блока, более влияющих на их качество:

Foundational science — не добавляет новых идей, но напрямую влияет на review, а также расширяет спектр возможностей в блоке «Marketing/Product Data».
Возьму для примера изучение мат. статистики — на review повлияет тем, что вы научитесь лучше интерпретировать проведённые ранее эксперименты и тем самым улавливать больше новых закономерностей и аномалий, что приравнивается к новым точкам роста.
А одним из плюсов для блока «Marketing/Product Data» станет то, что вы сможете выбирать подходящие именно в вашем случае статистические методы (как пример, переход от частотного метода к байесовскому и т.п.).
Related industries — идеи, заимствованные из смежных отраслей (к примеру, в командах ML, маркетинговых аналитиков, brand и т.д.)

Работа с ideas frame довольно проста — в первую очередь нужно проанализировать как вы работаете и работаете ли вовсе с блоками, что указал выше.

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

Далее периодически возвращаться к фрейму, как к некому компасу, проверяя не упускаете ли из виду какой-то из блоков.

Ideas Hub

Ideas Hub — единое рабочее пространство команды, куда все её участники заносят идеи по росту продукта. Хаб помогает централизовать работу с идеями, заменив личные списки идей из заметок, избранного в телеграме и т.д.

Цель хаба — повысить качество работы с идеями (к примеру, перестать тратить время на дублирование идей, улучшить валидацию) и усилить генерацию новых за счёт постоянного обмена идеями внутри команды — единая платформа и её открытость создаст почву для этого.

Выглядеть хаб может по-разному: таблицей, списком чек-поинтов, agile-бордом — тут решать вам, главное его наличие и функционирование.
Я же рекомендую использовать наиболее простой инструмент — таблицу.
В моём варианте (иллюстрация выше) используется таблица с пятью столбцами:

idea — предположение, что некоторое действие приведёт к улучшению X метрики. Обычно это неструктурированные мысли без оценок.
category — то, что объединяет идеи в небольшие группы при работе.
comments — небольшой комментарий для команды, если нужен.
priority — субъективная оценка важности данной идеи от её автора.
author — собственно сам автор идеи.

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

Чтобы инструмент прижился в команде и приносил реальную пользу, он должен быть прост в заполнении и всегда находиться под рукой (быть кроссдевайсным и иметь общий, облачный доступ к редактированию), как вариант — таблица в Notion.

Вы можете подметить: «но в твоём примере 5 столбцов, таблица не очень-то проста в заполнении» — на самом деле все столбцы, кроме idea, заполняются за несколько секунд, т.к накликиваются из выпадающих списков.

Трудности реализации module I

Расфокусировка внимания команды — команде выделяется мало времени для полноценной работы над ростом продукта/направления, и ее «дёргают» под другие задачи. Это часто случается при работе с v-team, когда нет выделенных growth-команд.
Работа с идеями на дальних этапах, когда всё уже протестировали, и кажется, что больше ничего не придумать (наступит через несколько месяцев работы с VelocityBoost) — один из самых сложных и стрессовых моментов, но именно тут и начинается настоящая работа.
Немотивированность сотрудников и сопротивление переменам — сотрудника ранее работавшего долгое время в своей привычной методологии и делавшего 1 эксперимент в месяц-два порой бывает невозможно перевести на новый метод со скоростью 10 экспериментов в месяц из-за некой закостенелости и боязни переменам.
Пренебрежение процессом — после внедрения VelocityBoost сотрудники продолжают работать по старинке, полностью или частично игнорируя инструментарий и процессы первого модуля, но при этом ожидая результат, как от полноценной работы с методом.

module II

Если первый модуль обеспечивает непрерывный поток идей и наполненность бэклога, то второй модуль отвечает за работу с гипотезами, а именно: перевод идей в гипотезы, скоринг, приоритезацию, интерпретацию результатов и работу с базой экспериментов (expt).

Без качественной проработки второго модуля вы перестанете понимать, зачем тестируете те или иные гипотезы, и как они влияют на ключевую метрику (и влияют ли вообще), какую гипотезу брать первой в работу, а какую вообще не стоит рассматривать.

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

Важно отметить, что цель VelocityBoost — не экспериментирование ради самого экспериментирования, а рост продукта через увеличение количества и качества проводимых экспериментов.

Инструментарий

Expt — единая база экспериментов в команде и пространство для работы с гипотезами: приоритезация, фиксация статусов и результатов. Ниже подробнее остановимся на работе с expt.
Методология скоринга гипотез для всей команды — подробнее про ICE-score и его применение писал в этой статье. Рекомендую не останавливаться на ICE-score, а поизучать разные варианты скоринга и выбрать подходящий именно вам.
Единая методология работы с экспериментами — выглядит как один или несколько документов, зафиксированных во внутреннем вики команды, в которых указано, как дизайнить эксперименты, на какие метрики или прокси-метрики смотреть и т.д.
Понимание мат. статистики — это конечно не инструмент, а навык, но всё же вы будете работать с экспериментами, а эксперименты без статистики невозможны — стоит хотя бы базово подтянуть знания. Если не знаете как подступиться к изучению — начните с «гайда для новичков».
Технические инструменты для работы с экспериментами — встроенный функционал А/Б с возможностью быстрого запуска экспериментов, а также быстрого (и стабильного) интерпретирования, калькуляторы для расчёта выборки и SRM, калькуляторы для постанализа и выявления стат.значимых результатов.Если вы не сильны в мат.статистике — рекомендую на первых этапах подключить аналитиков, чтобы настроить грамотный процесс.
Маркетинговая/продуктовая аналитика — подключены и настроены (есть все нужные ивенты, корректно передаются данные и т.д.) все нужные для работы аналитические системы.
Scoring meetup — встреча для валидации (обсуждения и питчинга идей) и скоринга новых гипотез, проходит раз в две недели, но можно сделать и чаще, если есть надобность.

Expt

Пример, как может выглядеть таблица expt

Помимо функции «единой базы завершённых экспериментов», expt является основным инструментом планирования и приоритезации гипотез.

Чтобы идея из Ideas Hub попала в Expt и далее встала в очередь на реализацию, она должна пойти тяжёлый путь валидации (можно назвать этот этап «питчинг» — краткая защита гипотезы её автором перед командой) и скоринга — проходит на scoring meetup.

Рассмотрим, какие данные заносятся в Expt:

Каждой гипотезе присваивается уникальный expt-id (столбец # expt), далее этот id пробрасывается непосредственно в эксперимент (тикет, рекламную кампанию, креатив, title продуктового эксперимента и т.д.) — делается это для сквозной аналитики и быстрого поиска по экспериментам.
В столбец title вписываем краткое, но понятное название гипотезы.Это нужно для беглого понимания, что мы тестируем без погружения в детали эксперимента.
Столбец prediction показывает, какой результат мы ожидаем от эксперимента, если тот будет успешным. Указанная цифра должна быть подкреплена данными и логикой, которой следовал автор при указании предикта — всё это расписывается в тикете.
Столбец ice — отражает общекомандный скор гипотезы, нужен для дальнейшей приоритезации.
ST — место для ссылки на тикет, в котором указана вся подробная информация по эксперименту: дизайн эксперимента, номер спринта, фиксация статуса и финального результата.
Start указывает на дату запуска эксперимента, а End — на дату его фактического завершения.
Когда эксперимент завершён — фиксируем финальный результат в столбец result. Чем больше экспериментов вы проведёте, тем точнее будут прогнозные данные (столбец prediction) к фактическим.
Scale — финальная оценка проведённого эксперимента — раскатываем эксперимент на «всех» пользователей или нет.

Трудности реализации module II

Крайне трудно, а порой и вовсе невозможно, реализовать работу с экспериментами, если в компании отсутствует data-driven культура.
Будьте готовы к тому, что придется столкнуться со всевозможными проблемами при разработке и дальнейшей работе с инфраструктурой под эксперименты: баги, проблемы с рандомизацией, не учтён srm, не учтены нужные метрики или считаются неправильно, недостаточная чувствительность тестов и т.д.
Низкое знание мат.статистики у сотрудников growth-команды может свести на нет все усилия интеграции второго модуля. Если базовых знаний недостаточно — стоит инвестировать ресурсы в обучение сотрудников.
Никуда не исчезнет, но нужно постараться минимизировать, базовую халатность и человеческий фактор — неверная интерпретация результатов, ошибки при дизайне экспериментов и т.д.
Низкая вовлечённость (или полное избегание) сотрудников в работу с экспериментами — особенно у тех, кто ранее не работал плотно с ними.
Также вы столкнетесь с тем, что большая часть гипотез (порядка 70-80%) не будет успешной, и это нормально. Снижение успешных гипотез пропорционально тому, как долго вы работаете в постоянном и быстром темпе экспериментирования, так что чем дольше вы работаете с VelocityBoost, тем сложнее найти новые успешные гипотезы.

module III

С помощью первого и второго модуля вы настроите грамотный growth-процесс — гипотезы «польются» стабильным потоком, velocity пойдёт вверх.

Но это продлится недолго — velocity начнёт падать, ресурсов будет выделяться всё меньше, как и внимания к процессу, а вам, как менеджеру, придётся всё больше и больше вкладывать свои силы в то, чтобы процесс продолжал хоть как-то функционировать, а количество экспериментов перестало падать.

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

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

Инструментарий

Growth meeting — регулярная, еженедельная встреча команды для планирования экспериментов.
Workspace — общекомандное пространство для планирования short-циклов и недельных спринтов (работает в связке с Agile Board), а также для фиксации договорённостей по процессам, статусов, драфтов дайджестов и комментариев к гипотезам и идеям.
Agile Board команды и работа по еженедельным спринтам — планирование ресурсов на growth-задачи, инфраструктурные, закрытие технического долга и рутинные задачи, а также для проведения ретроспектив.
Status — выделенная площадка, где публикуются регулярные (еженедельные или двухнедельные) дайджесты growth-команды с результатами экспериментов за прошедший отчётный период, планы на следующий, а также инфраструктурные доработки. Далее подробнее остановимся на инструменте.
Weekly sync — 15-минутная встреча growth-команды в конце недели для фиксации статусов по экспериментам. Нужна для оперативного подключения и распределения ресурсов, если у кого-то имеются трудности с экспериментами.

Workspace

Упрощенное и схематическое изображение реализации workspace

Workspace — это «движок» всего процесса, связывающий в единый работающий механизм все модули конвейера экспериментов.

Он выполняет важную организационную функцию — делает так, чтобы процесс работал стабильно: члены команды эффективно коммуницировали друг с другом и грамотно распределяли нагрузку.

Workspace, при всей его важности, является простым инструментом и может выглядеть как тикет в вашей системе управления проектами и совместной работы (Yandex Tracker, Jira и т.п.), куда добавлены все члены команды.
Workspace можно реализовать и в том же Notion — всё зависит от вашего подхода и связанности инструментов в компании.

В описании тикета, для быстрого доступа, размещаются основные инструменты команды:

Методология работы с экспериментами.
Ссылка на ключевые дашборды или встроенные чарты в само описание (зависит от системы, в которой будете работать).
Ссылка на OKR продукта/компании и цели long-цикла.
Ссылка на таблицу Expt и Ideas Hub.
Ссылка на Agile Board и Status.

Также к workspace линкуются все задачи, что делает команда в рамках long-цикла, как гипотезы, так и рутинные и инфраструктурные задачи, что позволяет в дальнейшем лучше оптимизировать работу команд (как growth, так и смежных).

В самом тикете происходят базовые рабочие процессы: комментарии по гипотезам и идеям, фиксация договорённостей, драфты дайджестов и планирование, плавно перетекающее в Agile Board.

Упрощенное и схематическое изображение реализации Agile Board

Работая по методологии VelocityBoost, через 2-3 short-цикла вы столкнетесь с проблемой планирования рабочей нагрузки в команде — сотрудники будут перегружать (или недогружать) себя задачами, терять фокус и тратить большую часть спринта на рутинные задачи, незапланированный рефакторинг и т.д. — то есть на что угодно, только не на задачи, ведущие напрямую к результату.

И если с такой трудностью вы неизбежно столкнётесь даже при работе с выделенной growth-командой, то про остроту проблемы при работе с v-team, я уже и не говорю.

Задачу балансировки нагрузки помогает решить Agile Board — схематически изображена в примере выше. В примере я его намеренно упростил для донесения сути без отвлечения на детали (в реальном варианте вам понадобятся: теги, статусы, ответственные, критерий важности, выведенный в карточку ice score и т.д.).

Суть такая: есть сотрудник у которого задачи (рутинные, инфраструктурные и экспериментальные) распределяются по спринтам с указанием нагрузки в Story Points (1 sp в моём примере = 1 человеко-час).

Понимая, сколько у сотрудника есть SP, и как сбалансирован спринт по типу задач, вы можете эффективнее выстроить планирование как для самого сотрудника, так и для процесса в целом.

Планирование спринтов проходит еженедельно на Growth meeting.

Workspace и Agile Board неразрывно связаны с ещё одним важнейшим инструментом третьего модуля — площадкой «Status».

Status

Пример еженедельной публикации в status (N - введена для упрощения примера, обозначает пункт, который нужно заменить на реальное значение)

Status схож по реализации с workspace — находится в той же системе совместной работы, имеет вид тикета (или другой формат, зависит от вашего выбора системы), в описании так же фиксируются все важные ссылки и метрики.

Но, в отличии от workspace, в status добавлены все ключевые участники проекта (менеджеры, лиды смежных команд и т.д.), и тут публикуются только регулярные отчёты, пример которого я проиллюстрировал выше.

А теперь подробнее разберём, зачем вообще нужен этот инструмент, и каковы его цели.

Первая цель

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

Уделив несколько минут в неделю на чтение дайджеста на платформе status, все будут знать актуальный статус, а также, когда будет время и желание, смогут детально изучить проведённые и планируемые эксперименты.

Конечно, формат не заменит встречи со смежниками и заказчиками, но сделает их более эффективными с фокусом на актуальные проблемы или точки роста, но не на дублирование информации из платформы «status».

Публикация-дайджест состоит из четырёх основных блоков:

Хедер публикации— в самом начале дайджеста показываем, как движемся к цели, поставленной перед стартом long-цикла. Обычно это вставка дашборда с выведенным таргетом и небольшой пояснительный комментарий к графику.
Завершённые эксперименты — указываем результаты экспериментов, которые завершились ко дню публикации дайджеста.
Планируемые эксперименты — эксперименты, которые берём в работу на следующий спринт. Является полезной для команды практикой, так как позволяет ещё раз провалидировать ценность гипотез взятых в работу, а также полезна коллегам для понимания, куда фокусирует силы growth-команда.
Инфраструктура — тут мы доносим инфраструктурные изменения, если те имеют важность для широкого круга менеджеров, как появление нового дашборда и т.д.

Вторая цель

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

Когда завершится первый short-цикл, growth-команда активирует блок «status», то есть делает первую публикацию на платформе и анонсирует запуск на всех заинтересованных лиц с коммитом на регулярность публикаций (к примеру, указав, что публикации на платформе «status» будут выходить каждую неделю по вечерам вторника).

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

Выделю несколько важных моментов, без которых status не приживётся у смежников и заказчиков —> его просто не будут читать:

Заказчики, смежники и др. должны знать, как связан процесс (что мы реализуем) с большой целью продукта/компании, куда мы идём и зачем делается поток экспериментов. Ни для вас, ни для смежников нет выгоды от реализации метода ради самого метода — должна быть явная цель.
Также все заинтересованные сотрудники должны иметь доступ к expt (где смогут отслеживать проранжированные по скору гипотезы), к Ideas Hub и к таргету long-цикла. Процесс должен быть максимально прозрачным.
Публикации должны выходить регулярно в один день и в одном месте — все заинтересованные менеджеры будут понимать, где и когда ждать информацию по процессу.
Публикуемая информация должна быть качественной — то есть не иметь спорных тезисов, ошибочных выводов и упущений в анализе, из-за которых вывод становится невалидным. Постоянные ошибки в публикациях будут дискредитировать команду и закономерно приведут к игнорированию публикаций в status.
Публикации должны быть ёмкими и информативными — сделайте ограничение на число строк для каждого тезиса. Не превращайте дайджест в огромную нечитаемую «портянку».
В status публикуем небольшое превью, так, чтобы читатель без погружения в детали увидел основную информацию, из которой смог бы сделать выводы, а если захочет углубиться в детали — мог найти дополнительную информацию по ссылке.
Периодически напоминайте коллегам, что есть «status», и там публикуется вся нужная информация — приготовьтесь, обучение коллег чтению дайджеста дело небыстрое, понадобится терпение, несколько месяцев и периодические напоминания. Обычно ко второму long-циклу такой проблемы уже не наблюдается.

Трудности реализации module III

Неготовность участников growth-команды выделять время на донесение своих результатов — положительных и, тем более, отрицательных.
Не проведены обучение и методическое напоминание всем участникам о том, где можно отслеживать результаты команды — из-за этого третий модуль не даёт ожидаемый результат и не делает процесс прозрачным.
Методичные ошибки в интерпретации результатов могут загубить весь процесс — никто не захочет узнавать про результаты экспериментов, если они, с большей вероятностью, будут ошибочны.
Нежелание участников работать в недельных спринтах и с Agile Board — станет причиной, почему не получается выстроить стабильный процесс экспериментов.

Short growth cycle в детализации по неделям

Из материала вы узнали, из чего состоит метод VelocityBoost, познакомились с модулями и их инструментарием — пришло время перейти к заключительной, организационной, части — понять, как всё это функционирует в рамках short growth cycle и спринтов.

Сперва посмотрим, как выглядит short-цикл с выставленными основными встречами, теми, что были указаны в описании модулей. Схематически их изобразил на рисунке выше.

Конечно появятся и другие встречи, множество дополнительных регулярок и процессных встреч, но встречи, указанные на рисунке (и cleanup meeting, что проходит после двух полных short-циклов) являются фундаментом VelocityBoost.

Поняв, как верхнеуровнево выглядит short-цикл, рассмотрим его поближе — поймём, как инструменты взаимодействуют в рамках одного недельного спринта.

Взаимодействие в рамках недельного спринта

Схематическое изображение работы внутри недельного спринта

В этой главе я не буду останавливаться на базовых процессах и встречах — как проводить brainstorm, weekly sync и другие, т.к они мало чем отличимы от общепринятых в it, а лучше подробнее расскажу про growth meeting, так как он является краеугольным инструментом VelocityBoost.

И прежде чем перейти к теме, скажу ещё пару слов про спринты. Знаю, что многих переход на недельные спринты пугает, но при грамотной настройке процесса вы увидите только преимущество от работы в спринтах — начнёте лучше балансировать нагрузку и адекватно подходить к ресурсам (в виде времени), а также снизите неопределённость в работе сотрудника и всей команды.

На иллюстрации всего процесса (рисунок выше) я попытался схематически изобразить, как проходит growth meeting, далее детальнее разберём каждый из блоков.

Завершённые эксперименты прошлых спринтов

Из описания третьего модуля вы знаете, что неотъемлемым инструментом growth meeting является workspace — с него и начинается встреча команды.

Команда собирается вместе, офлайн или онлайн не столь важно, далее growth manager (может быть как тимлид, так и один из участников) шерит workspace, и, в первую очередь, начинается обсуждение завершённых экспериментов и небольшой ретроспективы прошедшего спринта.

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

Завершённые эксперименты должны быть зафиксированы в expt до growth meeting, важно делать это заранее, чтобы не отнимать время встречи на это.

Тут же команда обсуждает, не появились ли за прошедший спринт важные инфраструктурные доработки и, если появились, то отправляют в дайджест в раздел «инфраструктура».

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

Планирование текущего спринта

Планирование следующего спринта проходит в Agile Board, и если это не первый ваш short-цикл, то большая часть задач уже будет добавлена в спринт, так как на growth meeting мы планируем на два спринта вперёд.

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

К тому же за неделю появятся разные рутинные/оптимизационные и инфраструктурные задачи, которые также добавляются в спринт. Далее спринт сотрудника/команды балансируется, а планируемые эксперименты отправляются в дайджест, раздел «планируемые эксперименты».

Планирование следующего спринта

В предыдущих блоках указывал, что стоит планировать хотя бы на два спринта вперёд (в идеале — три), а делается это для того, чтобы члены команды понимали загруженность и заранее закладывали ресурсы, а также заблаговременно могли отследить, что гипотезы начинают иссякать, и нужно активнее включать модули 1 и 2.

Сам же процесс планирования следующего спринта мало чем отличается от планирования текущего — логика та же. Гипотезы отранжированные по скор берутся из expt. Если же есть непроскоренная идея в Idea Hub, и команда верит в неё, то скоринг может пройти на планировании, не дожидаясь Scoring meetup, но такое случается нечасто.

Запланированный спринт остаётся в Agile Board, дожидаясь, чтобы его взяли в работу на следующей неделе (предварительно провалидировали) и опубликовали на платформе Status.

Заключение

На этом всё. Надеюсь, VelocityBoost окажется полезным (а главное применимым) и принесёт кратный рост вашему продукту.

Не забудьте поделиться методом с теми, кому он может быть важен.

Рост продуктов с помощью метода VelocityBoost — создаём «конвейер экспериментов»