Как построить процессы Discovery и Delivery

Недавно вышел интересный пост Лены про то, как идеи ломаются на экзекьюшене, если не подключить проджекта вовремя.

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

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

DISCOVERY
1️⃣ Идея
Скорее всего это одна строчка в эксель, которая была быстро записана, чтобы не забыть. Или стикер на доске после стратегической сессии.

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

3️⃣ Запланировали проверку гипотезы в квартал
У всех разное планирование, у нас квартальное. Здесь приоритизуем гипотезу в бэклог квартала на основании разных факторов, у каждого они свои, но глобально — алайниться ли гипотеза с текущей стратегией бизнеса.

4️⃣ Взяли в бизнес-анализ и дизайн
Здесь опишу не детально, так как не суть поста, но я адепт Double Diamond в работе команды Дискавери.
4.1 Проводим исследование и собираем данные.
4.2 Синтезируем их и определяем главную проблему, которую будем решать.
4.3 Формируем верхнеуровневые бизнес-требования (БТ), рисуем концепт макетов.
4.4 Если это что-то новое, в чем мы вообще не уверенны, — приносим на kick-off команде разработке, чтобы сразу собрать вопросы, тех. ограничения, корнеры и всё то, что повлияет на решение.
У нас даже когда-то появился в команде термин «Ощипывать курицу» — это когда ты отбрасываешь все бантики и делаешь самое MVPшное MVP.
Если это что-то типовое, то сразу идем к след. пункту.
4.5 UX-тесты с пользователями.
Проверяем, насколько пользователю вообще понятно то, что мы придумали. Если не очень, то переделываем макеты и на новый круг тестов.
4.6 Грумим с командой финальные БТ и макеты. Продолжаем ощипывать:)
4.7 Если есть в команде такая роскошь, как системный аналитик, то проводим груминг на уровне системного анализа. И тут финальное ощипывание нашей «курицы».

DELIVERY
5️⃣ Разработка
Если возникают какие-то вопросы — обсуждаем на дейлике или в чатах.
6️⃣ Тестирование
То же самое, потому что своевременная синхронизация — наше всё.
7️⃣ Релиз
Обычно проводим демо до релиза, а дальше исследуем, насколько наша гипотеза оказалась верна. И в ходе исследования получаются инсайты и идеи для нового круга итерации под названием «Жизненный цикл фичи».

Хоть процесс описывается линейно, но пока проходит Discovery фичи Б, ребята делают Delivery фичи А — два параллельных трека. Чтобы избежать проблем, про которые говорила Лена, подключайте команду к решению как можно раньше! Во-первых, они со своим технологическим взглядом накидают вам полезного дополнительного контекста, а во-вторых, станут со-творцами решения и вовлекутся в фичу.

А как у вас выстроен производственный процесс? Какие в нём этапы и роли?

Автор: 🐆 Сабина Алигьери — систематизирую хаос разных теорий, чтобы ДЕЛАТЬ КАК НИКТО