Недавно вышел интересный пост Лены про то, как идеи ломаются на экзекьюшене, если не подключить проджекта вовремя.
У меня никогда не было проджектов в команде, и все идеи от осознания до релиза доводила я, поэтому захотелось поделиться своим взглядом, как выстроить рабочий производственный процесс. В этом посте расскажу про кейс, если фича только в вашей команде, про кросс-функциональный проект — во второй части. Итак, погнали:)
Когда-то я увидела схему 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 фичи А — два параллельных трека. Чтобы избежать проблем, про которые говорила Лена, подключайте команду к решению как можно раньше! Во-первых, они со своим технологическим взглядом накидают вам полезного дополнительного контекста, а во-вторых, станут со-творцами решения и вовлекутся в фичу.
А как у вас выстроен производственный процесс? Какие в нём этапы и роли?
Автор: 🐆 Сабина Алигьери — систематизирую хаос разных теорий, чтобы ДЕЛАТЬ КАК НИКТО
Дискуссия