lviv pmday 2016 s Андрій Мандріка: "Шлях product owner`a. Від...
Post on 11-Apr-2017
82 Views
Preview:
TRANSCRIPT
Путь 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
top related