Product Discovery внутри фреймворка Scrum
Узнайте, как интегрировать Product Discovery в Scrum без создания изолированных отделов. Проводите эксперименты, проверяйте потребности пользователей и создавайте нужный продукт в рамках обычных Sprint.
Команды часто воспринимают Scrum как конвейер по написанию кода. Предполагается, что требования поступают полностью готовыми, а разработчики просто собирают из них программное обеспечение. Когда компании понимают, что такой подход порождает продукты, которые никому не нужны, они обычно создают отдельный процесс для дискавери. Дизайнеры и продакт-менеджеры проводят исследования в одном изолированном отделе, а затем перебрасывают задачи инженерам в другой. Это возвращает ту самую проблему передачи ответственности, для решения которой и создавался Scrum. Для Product Discovery не нужен отдельный трек. Оно должно происходить непосредственно внутри Sprint.
Заблуждение о предварительной фазе Discovery
Руководство по Scrum 2020 года говорит прямо: существует только одна Scrum Team, сосредоточенная на одной Product Goal одновременно. Внутри этой команды нет подкоманд или иерархий. Разделяя тех, кто исследует, и тех, кто разрабатывает, вы теряете технический контекст и эмпатию к пользователю. Инженеры понимают технические ограничения и возможности лучше, чем кто-либо другой. Если инженер присутствует на интервью с клиентами, он часто замечает решения, о которых дизайнер или продакт-менеджер даже не подумали бы.
Предварительное исследование также исходит из предпосылки, что знания устаревают медленно. В разработке требования меняются в тот момент, когда реальные пользователи начинают взаимодействовать с интерфейсом. Потратить три месяца на проверку макетов до написания первой строчки кода, это обычный Waterfall, замаскированный под современный продуктовый менеджмент. Настоящая проверка гипотез происходит тогда, когда работающее программное обеспечение сталкивается с реальным поведением пользователей.
Включение задач Discovery в Sprint Backlog
Sprint Backlog полностью принадлежит Developers. Он содержит Sprint Goal, элементы Product Backlog, выбранные на Sprint, и понятный план их реализации. Ничто в Scrum не мешает включить исследовательские активности в этот план. Если команде необходимо ответить на критически важный вопрос пользователя для достижения Sprint Goal, такое исследование считается полноценной работой.
Зрелая Scrum Team сочетает задачи по разработке с задачами по исследованию. Работа в рамках Discovery может принимать разные формы в зависимости от того, что именно команде нужно узнать:
- Проведение пяти интервью с пользователями с использованием кликабельного прототипа для проверки навигации.
- Создание временного архитектурного спайка для проверки задержек внешнего платежного шлюза под нагрузкой.
- Запуск теста fake door для оценки реального спроса клиентов на предполагаемую функцию экспорта аналитики.
- Внедрение трекинга событий на существующем экране для фиксации базового процента оттока пользователей перед его редизайном.
Sprint Review как инструмент для Discovery
Многие команды сводят Sprint Review к односторонней демонстрации. Они показывают закрытые задачи и ждут вежливых аплодисментов. Scrum Guide определяет это событие иначе: инспекция Increment и адаптация Product Backlog. Это событие задумано как совместная рабочая сессия со стейкхолдерами.
Если относиться к Sprint Review как к исследованию, вы опираетесь на реальные данные об использовании. Вы показываете то, что было создано, делитесь пользовательскими метриками, собранными за время Sprint, и обсуждаете неожиданные выводы команды. Стейкхолдеры и Developers вместе оценивают текущий рыночный контекст. Результатом качественного Sprint Review становится обновленный Product Backlog, который отражает реальность, открытую в ходе работы, а не просто изначальный роадмап.
Отказ от работы как полноценный результат
Самое сложное в проведении Product Discovery внутри Scrum заключается в принятии потерь другого рода. В команде, нацеленной исключительно на поставку, написание кода, который потом удаляется, воспринимается как провал. В эмпирической команде отказ от функции из-за доказанной исследованием бесполезности становится огромной победой. Вы сберегли месяцы будущей поддержки и не накопили технический долг.
Scrum предоставляет короткие, четко очерченные циклы обратной связи. Каждый Sprint дает возможность получить надежные доказательства. Когда Product Owner и Developers относятся к каждому элементу бэклога как к проверяемой гипотезе, а не как к прямому распоряжению, исследование и поставка объединяются в единую, слаженную дисциплину.