Scrum доказал, что является эффективным способом управления продуктом практически для всех областей. Организация команды согласно фреймворку помогает поставлять продукт быстро и качественно. Один момент — он также хорошо подходит для эффективной поставки совсем не того продукта.
Ахиллесова пята этого фреймворка — этап исследования продукта. По Scrum Guide, владелец продукта чудесным образом определяет, куда лучше всего направить scrum-команды, управляя бэклогом продукта. Как это должно происходить, нигде не описано, так как в Scrum этап исследования и поставки продукта разделены (что в современных реалиях тяжело сделать в Scrum-команде).
Пытаясь заполнить пробел в discovery-этапе, организации регулярно обращаются к другим гибким фреймворкам, типа lean startup или дизайн-спринты. Каждый идёт кто во что горазд (хотя перечисленные примеры выше не в коем случае не плохи), что рождает на свет анти-паттерны.
В этой статье мы собрали часто встречающиеся, повторяющиеся ошибки при исследовании продукта.
Основные причины проблем с Discovery-этапом
Причины анти-паттернов часто могут вызываться одной или несколькими из этих причин (если можете добавить ещё что-то — рады прочитать в комментариях):
- организационные дисфункции, например, когда в компании есть независимые отделы, которые трудно так просто привлечь к разработке идеи,
- культура личного лидерства и главенства личных целей над общими,
- многоуровневая структура отчетности, которая задерживает поток информации и тормозит принятие решений,
- бюджетирование конкретных проектов, а не постоянных команд, которые могут генерировать ценность и дальше.
Поехали, самые частые ошибки...
Анти-паттерны при исследовании продукта
- Знаем, что разрабатывать — без взаимодействия с пользователями и клиентами, бэклог продукта наполняется косвенно. Обычно, это мнение менеджеров по работе с клиентами, личные предпочтения бизнес-заказчиков и прочее, не подкреплённое реальными данными в основе.
Как исправить: важно, чтобы команда имела как можно меньше посредников между конечными пользователями и запросом. Go-and-see стратегия.
- Неприкосновенное решение — то же самое, что ошибка выше, но усугубляется тем, что команда не готова слушать критику решения и авторизовывать успех или неудачу.
Как исправить: верить в проблему, а не своё решение.
- Концепция продукта вокруг персон, а не реальных пользователей — команда серьёзно подходит к этапу исследования и создаёт пользовательские персоны, но затем.. Это потенциальная ошибка, так как опора на персоны может искажать пользовательские тесты или их интерпретацию.
Как избежать: сначала наблюдение за конечными пользователями, затем прототип для подтверждения гипотезы и персонажи. Их характеристики также должны проходить постоянный пересмотр.
- Продукт-винегрет — организация не делает никаких попыток чем-то ограничить видение продукта и поставить чёткую цель. Заинтересованные стороны просто накидывают запросы, слабо связанные между собой, что, как минимум, усложняет прогнозирование и рефайнемент на уровне scrum-команд.
Как исправить: привлечь заказчиков работать с командой, как вариант, провести штурм и составить User Story Mapping.
- Дизайн не принадлежит команде — UX / UI-дизайнеры находятся где-то вне scrum-команды. Это достаточно частая проблема, которая препятствует скорости и качеству работы команды.
Как исправить: мы знаем, что нам нужны кросс-функциональные команды, но это будет слишком розовый мир, если сказать: "Дайте по специалисту в каждую команду". Быстрый совет — договориться с отделом о выделенном специалисте и ввести его в команду на ограниченный срок, в самый жаркий период исследования.
- Пользовательские тесты не принадлежат команде. Ситуация и совет аналогичен пункту выше. Плюс, компетенция должна быть передана в команду, чтобы исследование пользователей проводилось без прокси между юзерами и разработчиками.
- Разработчики не должны делать ничего, кроме разработки — организация считает, что время разработчиков очень дорого, чтобы тратить их на side-work (в их понимании). Будто бы легче нанять хорошего UX/UI дизайнера, чтобы закрыть компетенцию. Это не совсем верная ментальная модель. Чем раньше разработчики примут участие в исследовании проблемы, тем выше будет отдача инвестиций. Вообще, эта изоляция разработчиков выходит дорого: время на простой, на ошибку интерпретации, на переделывание и прояснение требований...
- Техподдержка не относится к проектной команде — в организации есть изолированные центры техподдержки, и scrum-команды не участвуют в этом процессе (или участвуют только опосредованно, через уже обезличенные задачи). Но именно работа в техподдержке — эффективный способ обнаружить боли клиента.
Как исправить: ввести принцип из разработки, ориентированной на поддержку — каждый в команде тратит 5% своего времени на поддержку клиентов (включая ответы клиентам!). Идея с UserConf ещё 2012 года:
- Карго-культ вокруг исследования продукта — компания получает готовые идеи, а не проблемы от клиентов, или же спрашивает клиентов о том, какие у них есть проблемы, или же собирает конкретные требования от конечных пользователей,
Как избежать: первое правило — Go and See. Владелец продукта должен понимать проблему и вместе с командой находить решение, а не конечный пользователь.
- Отсутствует процесс сбора идей и обратной связи. Хорошая идея — создать процесс, который активно вовлекает заинтересованные стороны и членов организации в процесс исследования продукта. Это вряд ли задача одного scrum-мастера, но это точно повод подать идею HR-департаменту или отделу корпоративной культуры.
- Пункт выше может быть закрыт, но рождать еще один анти-паттерн — процесс сбора идей и обратной связи есть, но команда разработки не вовлечена в него. Менеджеры решают сами, что отсеять, и не оставляют команде шанса на эксперимент.
Выводы
Процесс исследования и доставки продукта должен быть целостным и лежать в основе любой организации, которая внедряет Scrum. Закрывать этап исследования продукта — это необходимость.Для этой цели есть множество гибких фреймворков и практик. Примите к сведению перечисленные выше анти-паттерны, чтобы следить свой продукт чуть успешнее.
Какие ещё частые ошибки встречаются в организациях? Может быть, паттерны с KPI или бюджетами? Будем рады, если в комментариях вы дополните статью своим опытом.
