Путь Product Owner`а. От факапов до

успешного продукта

Мандрика Андрей, CSPOProduct owner,

«Product Owner». Кто это такой?«Владелец продукта (Product Owner) - проектная роль в методологии Scrum, ответственная за сбор требований к продукту, документирование требований в форме пользовательских историй, задание приоритета историям и приемку функциональности, реализованной командой…»

«Product Owner». Кто это такой?

«Владелец продукта (Product Owner) – персона, которая владеет определенным продуктом от имени организации.»

А что такое продукт?

Направлен на решение проблемы и/или получение выгоды для пользователя/ клиента

Создает прибыль, позволяет разрабатывать новые продукты или бизнес цели организации.

Создает ценность

Channels

SportsbookTrading ToolsMath

Core

CRM Payments Wallet Marketing Risks management

Основные этапы пути

Потенциальные обязанности Product Owner`a 1. Должен иметь и распространять видение

продукта.2. Общение с заинтересованными сторонами

и синхронизация их интересов.3. Определение и формализация требований.4. Организация, заполнение и приоритезация

беклога.5. Планирование итераций и ведение

груммингов.6. Определение целей на итерации и релизы.7. Консультация и объяснение сути задач для

команд(ы).8. Приемка результатов выполненных

командой.9. Определение успешности итераций для

команды, заинт. сторон и бизнеса. 10. Участие в командных мероприятиях.11. Презентация выполненной работы.12. Создание условия для

усовершенствования работы команд(ы)

Видение продуктаПроблемы:1. Не знаем конечную цель. 2. Не понимаем потребностей и

проблем пользователей.3. Большая рас фокусировка.

Решения:1. Составляем Vision document.2. Изучаем текущие бизнес процессы.3. Выделяем MVP.

Product vision document

Заинтересованные стороныПроблемы:1. Не знаем всех заинтересованных

сторон.2. Отсутствие интереса к

незаконченному продукту.3. Мнения разных сторон противоречат

друг другу.Решения:1. Составляем матрицу

заинтересованных сторон.2. Вовлекаем стороны в процесс

разработки.3. Показываем ценность каждого

решения.

Определяем заинтересованные стороны

Сбор требованийПроблемы:1. Сами придумываем требования.2. Непомерные желания заказчиков.3. Слишком много входов для

требований.

Решения:1. Валидируем все требования с

заказчиком.2. Не теряем цель из поля зрения.3. Приоритезируем и движемся

поэтапно.

Описание требованийПроблемы:1. Требования не достаточно описаны.2. Требования разбиты на большие

части.3. Тяжело визуализировать

требования.

Решения:1. Внедряем AC, DoR, DoD.2. Совместная декомпозиции

требований вместе с командой.3. Практикуем дудление и макапы.

Организация беклогаПроблемы:1. Не видны взаимосвязи между

задачами.2. User story не позволяют оценить всю

картину.3. По мере увеличения беклога

теряется фокусировка.

Решения:1. Используем линки и флаги.2. Добавляем уровни иерархии.

Jira+Structure: (Themes -> Initiatives -> Epics -> User stories)

3. Добавляем Milestones и считаем прогресс.

Приоритезация задачПроблемы:1. Неважные и ненужные задачи

попадают в разработку.2. Как приоритезировать равные по

размеру задачи?3. Разные приоритеты у разных

команд.

Решения:1. Используем MoSCoW метод.2. Определяем ценность каждой задачи

($-$$-$$$).3. Квотирование времени для другой

команды.

Грумминг задачПроблемы:1. «Ну описание я потом допишу…»2. Не понимание сколько стоит задача.3. Завышенные оценки задач.

Решения:1. Фильтруем задачи через DoR.2. Оцениваем используя “Story points

calibration scale”.3. Декомпозируем задачи +

техническая проработка перед груммингом.

Планирование итерацийПроблемы:.1. Постоянное уменьшение velocity

команды.2. Дисбаланс между тех. и бизнес

тасками.3. Рас фокусировка команды внутри

итерации.Решения:1. Сбавляем давление на команду. Учет

рисков в capacity.2. Квотируем задач на итерацию (70%

бизнес задачи, 15% тех. Таски, 10% баги с прошлого спринта, 5% на баги с текущего спринта).

3. Выделяем и фиксируем цели итерации.

Приемка результатов работы

Проблемы:1. Работа выполнена не так как

ожидалось.2. Сделаны не все задачи.3. Задача разработана, но не

протестирована.

Решения:1. Пересмотр сделанных задач в

середине спринта.2. Не загружаем спринты под завязку.3. Учитываем все стадии разработки в

оценке задачи. (FE, BE, QA)

Участие в командных мероприятиях

Проблемы:1. Не понимание значения

обязательных мероприятий в Скраме.

2. Митинги затягиваются по времени.3. Митинги превращаются в балаган. Решения:1. Безукоризненно соблюдаем все

практики.2. Выделяем под митинги строго

фиксированное время + высылаем агенду.

3. Строго соблюдаем регламент + используем техники фасилитации.

Демо выполненной работыПроблемы:1. «Эффект демо» или ничего не

работает.2. Деплой за 5 минут до демо.3. Акцент не на тех вещах.

Решения:1. Выделяем ответственного за демо +

заводим задачу на подготовку.2. Код фриз за 1-2 дня до демо.3. Прописываем сценарий демо.

Постоянное усовершенствование команды

Проблемы:1. Бесполезные ретроспективы.2. Команда не развивается.

Решения:1. Составляем экшн план на

следующую итерацию + начинаем ретро с валидации сделанного.

2. Проводим обучение и семинары (Бизнес, процессы, технологии и т.д.)

Не бойтесь меняться и совершенствоваться!

Спасибо за внимание!Andrii MandrikaBusiness Analyst / Product owner

Contacts:• andrii.mandrika@gmail.com• andrey.mandrika@betlab.com• linkedin.com/in/andrii-mandrika• Skype: mandrikaandrew