Определение продукта в Scrum влияет на следующие аспекты:
- Организационные элементы: люди, компоненты, процессы и системы.
- Владелец продукта: определяет, кто отвечает за управление продуктом и его развитие.
- Бэклог продукта: наполнение и объём задач, которые нужно выполнить.
- Команды: количество и состав команд, работающих над проектом.
- Готовность (DoD): определяет, когда работа считается завершённой.
- Пользователи продукта: те, кто использует готовый продукт или услугу.
Как понять, что есть настоящий продукт
Используйте чек-лист для определения продукта
- Есть пользователи на рынке (за пределами организации).
- Есть ключевые фичи, которые закрывают потребности пользователей.
- Есть бизнес-модель (независимый P&L).
- Продукт поддерживается системами людей, процессов и компонентов.
Коммерческие организации создают продукты и сервисы для пользователей на рынке. Часто мы забываем об этом и придумываем искусственные понятия “внутренних продуктов” или “внутренних сервисов”. Настоящие продукты и сервисы имеют бизнес-модель и создают бизнес—ценность: «Выгода для организации, выраженная в деньгах, возникшая в результате эксплуатации сервиса или продукта.»
Какие бывают “продукты” в организациях
На опыте работы с разными Скрам-командами и продуктами, вокруг которых они организованы, получилась вот такая классификация:
- Компонент: “шина”, “платформа”, “CRM BnB”.
- Бизнес процесс: “кредитный конвеер”, “открытие счетов”.
- Канал: “сайт”, “мобильный банк Android”, “мобильный банк iOS”.
- Мульти-канал: мобильный банк (Andoid, iOS).
- Полноценный продукт: ипотека, займы, сервис облачного ритейла.
“Ctrl-C Ctrl-V” Скрам
Когда организации определяют продукты вокруг компонентов, внутренних бизнес-процессов или каналов, я это называю “Ctrl-C Ctrl-V” Скрамом. Создается большое количество фейковых “Владельцев Продукта”, которые управляют фейковыми “Бэклогами Продукта”.
Это вызывает негативные последствия для организаций:
- Зависимости между командами.
- Вынужденную синхронизацию между “Владельцами Продуктов” и с фокусом на разрешении зависимостей.
- Как следствие, дополнительные митинги.
- Оторванность разработчиков от рынка и сниженная мотивация.
- Лишние координационные роли (менеджеры, координаторы фич и т.д.).
- Лишние выделенные группы (команда интеграции, бизнес-аналитики).
- Отсутствие понимания, что же происходит на самом деле из-за дефрагментации организации.
- Сниженную доставленную ценность, потому что команды не догадываются, что самое ценное в данный момент может находиться в “Бэклоге Продукта” соседней команды.
- Как следствие всех предыдущих пунктов, высокий Time 2 Market и сниженная организационная гибкость.
Широкое определение продукта
Скорость и организационная гибкость возникают в случае широкого определения продукта. Чаще всего, для больших организаций это значит переход к масштабируемому Скраму (LeSS). Этот процесс нелегкий и требует реинжиниринга структур и процессов компании, обучения людей.