Привет! Сегодня расскажу про чек-лист, какие процессы нужно выстроить для новой Discovery команды.
Discovery и Delivery команды могут быть разделены. В Discovery-команду могут входить продакт-лид, продакт-менеджеры, продакт-аналитики, бизнес-аналитики и UX-дизайнеры/проектировщики. Если же задачи технические, то подключаются тех/тим-лиды, архитекторы и другие технические специалисты.
Что такое Disco? Discovery в первую очередь отвечает на вопросы «Что делать?» и «Надо ли вообще делать?». Delivery - «Как делать?».
Discovery-команда занимается обоснованием и проработкой инициатив, которые затем попадают в продуктовый бэклог для последующей реализации в Delivery.
Для запуска с нуля такой команды и их процессов мы используем следующий чек-лист:
В команде нужно выделить Дискавери-мастера (им может быть Продакт, Аналитики или Дизайнер),
он прочитал Scrum Guide,
посмотрел видео про Agile,
специализированный курс для Скрам‑Мастеров и
сдал тест на 85%+
Работу над обоснованием и проработкой инициатив организовать спринтами, длительность 1 или 2 недели;
Планирование Спринта и PBR (Грумминг) проводить каждый спринт. На PBR выделяется 2 часа за 2-х недельный спринт и на этой же встрече оцениваются задачи, при этом длительность и количество PBR-ов может уменьшаться или увеличиваться в зависимости от того, достаточно ли в бэклоге продукта задач для следующего дискавери-спринта;
В самом начале планирования определять цель или цели спринта. Сначала в бэклог спринта набираются задачи влияющие на цель спринта, потом все остальное. Команда не берет в спринт задач больше, чем ее средняя Velocity (больше, чем они обычно делают). Альтернативно, цель спринта может формулироваться в конце планирования, как логическая связка набранных в спринт элементов бэклога; Цель может быть кроссфункциональной, например, «сделать решение для онбординга байеров и каждый в команде свою часть решения делает;
Команда Discovery должна тратить минимум 30% времени спринта на уточнение гипотезы о проблеме и решении;
Дейли в команде проводить регулярно (не обязательно каждый день), в одно и тоже время. На этой встрече команда всегда в первую очередь фокусируется на цели или целях спринта, проговаривает проблемы, мешающие или замедляющие достижение цели спринта;
Обзор спринта (Демо) в формате встречи проводить каждый спринт, в результате этой встречи должна быть обратная связь от ключевых стейкхолдеров. Из рассказа команды понятно каким образом цель или цели спринта связаны и сдвинули дискавери ОКРы;
Ретроспектива проводить раз в спринт. Часто, но не обязательно после каждого ретро, формулируются и заносятся в JIRA команды сформулированные Action Items. При этом Action Itеm, если команда договорилась делать его в этом спринте, берется в бэклог спринта, как отдельная задача. Проблемы, которые не могут быть решены на уровне команды, смело эскалируются на уровень выше (на уровень Unit Lead-a или Кластер Лида). На каждом ретро команда анализирует статус выполнения экшен-айтемов с прошлых ретро;
У команды в Confluence должны быть описаны и соблюдаться критерии взятия задачи в спринт (Definition of Ready или DoR);
Описать и строго соблюдать критерии качества проработки инициатив на выходе из дискавери-спринта (Definition of Done или DoD). DoD дискавери команды при этом должен быть синхронизирован с Definition of Ready (DoR) в деливери команде или командах, куда поставляются проработанные инициативы;
В каждой задаче в JIRA должны быть прописаны специфичные для нее Критерии Приемки (Acceptance Criteria) или образ результата;
В дискавери бэклоге команда каждому item должна присвоить уровень confidence и итеративно его проверить, повышая или понижая приоритет задачи в списке (другими словами использует какую-то скоринговую модель, например RICE);
У команды должен быть дискавери-роадмап на 2 спринта вперед, то есть дискавери опережает деливери минимум на 2 спринта, и не создает для деливери команды дефицит обоснованных инициатив, которые можно взять в работу;
Команда должна вести дискавери бэклог проблем и решений и бэклог дискавери-спринта в JIRA;
У команды должен быть бэклог улучшений (action items) с ретроспектив в JIRA;
Команда должна знать и уметь пользоваться всеми каналами своих пользователей (support, sales, отзывы из сторов, UX, Маркетинг итд);
У команды должно быть единое место cбора и хранения гипотез, проблем, пожеланий клиентов, приходящих из разных каналов, чтобы связывать или отмечать инсайты, которые пришли из разных каналов;
Команда должна всегда ориентироваться на Voice of Customer до и после запуска продукта;
В спринте должна быть роль, которая отвечает за разбор Voice of Customer, при этом «шапка» может переходить между участниками из спринта в сприн.
__________________________________________________________________
Discovery Sprints
Дискавери спринты идут параллельно со спринтами разработки и нужны для того, чтобы получать проработанные обоснованные инициативы в продуктовом бэклоге. По сути, это — тот же скрам с такими же событиями внутри. Дискавери спринты не тормозят выпуск инкрементов, они идут параллельно опережая спринты разработки не менее чем на 2 цикла вперёд. Хороший бенчмарк, когда задачи для команд проработаны на 2 спринта вперёд. В основе используется классическая методология Design Thinking: от симптома к спектру проблем, от них к спектру решений.
Какие проблемы решает
В скрам-гайде не написано, как именно проработанные задачи попадают в продуктовый бэклог. Именно эту задачу решают дискавери спринты;
Мало того, чтобы проработанные задачи попадали в бэклог. Важно, чтобы в бэклог попадали обоснованные инициативы;
Мы привлекаем и вовлекаем разработчиков на ранних стадиях, снижая риски того, что задачи будут недостаточно проработаны;
В спринтах разработки дизайнер, аналитик и продакт участвуют эпизодически, т.к. они напрямую не влияют на инкремент. Теперь они участвуют в спринтах на 100%.
При выборе решений и проблем начинают системно рассматриваться альтернативы, а не берётся первое попавшееся решение.
Бэклог пополняется систематически и регулярно самыми важными вещами, а не тем чем придётся.
Продакты не закапываются в детали, а системно работают над дискавери айтемами. Метрикой успеха является количество обоснованных инициатив за спринт
Между продактами, дизайнерами и аналитиками создается «кросс-опыление» и они начинают «T-шейпиться»
В ситуации, когда юнит неполностью укомплектован аналитиками, дизайнерами и продактами не нужно делать ресурсное планирование «стаканами», а все решается в едином спринте
Если нет юнит-лида, то юнит может работать дискавери-спринтами, чтобы использовать коллективный разум.
Какие сайд-эффекты и как лечить
Разработчики, так как они не в диско-спринтах, не могут принимать участие в проработке задач. Лечить: тот, кто хочет подключается к диско-спринту и есть открытый календарь событий;
Отсутствие прозрачности между спринтами диско и деливери. Лечить: делать сначала деливери-демо, а потом диско-демо; сначала деливери-стендап, а потом диско-стендап + предыдущий пункт.
Разработка ждет пока дискавери подготовит задачи. Лечить: идти с опережением в 1-2 спринта;
У продактов разные цели и они не помогают друг другу в их достижении. Лечить: общие цели на весь диско-стрим;
Дополнительные встречи. Лечить: принять, если видите от этого ценность.
Роли
Disco Master — это не человек, который заводит таймер и не секретарь для команды, а лидер команды. Он коучит и улучшает команду, заинтересован в том, чтобы проводились ретроспективы, команда училась и процесс прокачивался. Это драйвер изменений, который улучшает сам процесс.
Disco Team — Продакт, Аналитик, Дизайнер, UX-исследователь, Разработчики, TUL
События
Disco Scrum — одно или двухнедельный спринт, результат которого получить не менее одной обоснованной инициативы
Disco Planning — определить цели спринта, оценить и декомпозировать задачи
Disco Daily — убедиться, что прогресс по целям on track
Disco Retro — понять, что было хорошо и что можно сделать лучше, не менее одного улучшения взять в следующий спринт
Disco Sprint Review — получить фидбэк команды разработки и стейкхолдеров по обоснованным инициативам
Disco Grooming — понять, что мы хотим из Роадмапа взять в следующие спринты и проработать + привлечь команду разработки на ранних стадиях
Байконур — overall дискавери демо, на которое выносятся самые «жирные» или «чувствительные» инициативы для обрат��ой связи
Артефакты
OKR's
Disco Roadmap
Disco Backlog
Delivery Backlog
Discovery Definition of Done
На выходе диско-спринта мы получаем либо описание проблемы (которая будет анализироваться в будущих диско-спринтах), либо решения (которе потом пойдет в деливери). Поэтому, Definition of Done состоит из 2-х частей (проблемы и решения).
Пример для описания проблемы (Definition of Done для проблемы):
1. Какую проблему решаем?
2. В чем причина проблемы?
3. Откуда мы про нее знаем?
4. Кто сталкивается с этой проблемой? Сколько их?
5. Насколько для них эта проблема критична? Значима? блокер или нет;
6. Как мы оценим успех? Как мы заработаем на этом?
7. Кто из других юнитов связан с этой проблемой? Кого это может коснуться?
Пример. (При этом, Definition of Done команды дискавери для решения должен стыковаться с Definition of Ready для деливери-команды)
Customer Problem questions (проблемные вопросы, которые помогают сосредоточиться на потребностях и трудностях клиента)
1. Какую проблему решаем?
Просадка контактов на 1.7% при скрытии телефона
Покупатели не понимают, почему нет телефона2. В чем причина проблемы?
У продавцов появилась возможность скрывать номер телефона3. Откуда мы про нее знаем?
Сигналы из саппорта
Результаты АБ со скрытием телефона4. Кто сталкивается с этой проблемой? Сколько их?
покупатели, можно посчитать5. Насколько для них эта проблема критична? Значима? блокер или нет;
6. Как мы оценим успех? Как мы заработаем на этом?
Покупатели понимают, что с продавцом можно контактировать в мессенджере -> больше контактов через мессенджер7. Кто из других юнитов связан с этой проблемой? Кого это может коснуться?
Buyer X, Seller X
Пример для описания решения (Definition of Done для решения):
Какое решение можно предложить, не тратя наших ресурсов?
Какие решения для аналогичной проблемы предлагают конкуренты?
Почему предлагаемое нами решение лучше для компании и для пользователя, чем п1 и п2?
Как протестировать, что наше решение работает?
Что является хорошим и плохим результатом теста?
Как решение встраивается в CJM всего продукта? Откуда начинается сценарий?
Это финальная версия? Как мы видим решение в целевом варианте?
Как информировать пользователей об изменениях? Откуда они узнают про решение