Роман Пихлер
Один из ведущих экспертов по Scrum и Agile-управлению продуктом. Спикер международных конференций. Наставник и сертифицированный тренер по Scrum. Возглавлял Scrum Alliance при создании курса обучения для владельцев продукта.
О книге
Некоторое время назад мы объясняли, почему в «Атласе новых профессий», составленном по технологии Rapid Foresight в АСИ (Агентстве стратегических инициатив), управление проектами позиционируется как комплекс надпрофессиональных навыков. Лет через 5 они будут считаться базовыми – вы наверняка заметили большой тренд на распространение Agile. Управление проектами, по сути, открывающая компетенция.
В недавнем интервью Zillion пиэм Павел Капусткин рассказал про карьерные возможности пиэмов: «У менеджера проектов длинная ветка вертикального развития. <…> Базируясь на навыках управления проектами, прокачаться в бизнес-девелопмент и войти туда на позиции средние и выше среднего – да не вопрос. Потом как биздев ты вырастешь до директорских позиций, либо присоединишь продуктовые компетенции и начнешь свой бизнес. Дело в том, что, когда ты работаешь менеджером проектов, неизбежно отхватываешь кусок знаний по управлению продуктом. А управление продуктом – это и про знание рынка, и про знание продаж. То есть это тот ключевой кусок знаний, который необходим на уровне CEO».
Все здорово, но словосочетание «владелец продукта» в контексте Agile-разработки мало о чем говорит. Вот книга Пихлера «Управление продуктом в Scrum. Agile-методы для вашего бизнеса» про вариант развития проджект-менеджера – роль продакт-оунера, то есть владельца продукта в скрам-команде.
Соавтор «Манифеста гибкой разработки программного обеспечения», основатель Agile Alliance и Scrum Alliance Кен Швабер описывает круг обязанностей продакта так: «Владелец продукта – единственный человек, отвечающий за список требований к продукту и ответственный за результат работы команды. Этот человек составляет бэклог продукта и обеспечивает его доступность для всех членов команды».
Продакт-оунер ведет продукт, причем фуллтайм, иначе продукт обязательно пострадает. Его задача, кэп, – выдать нужный продукт, поэтому он одновременно вникает в работу инженеров и погружен в рынок. Продакт формирует видение перспектив, бизнес-плана и выручки, а также план развития и план релизов. Он разрабатывает бэклог продукта и расставляет приоритеты для команды. 50% времени владелец продукта проводит с командой, 50% – с клиентами. Считается, что дальновидный, мотивированный и наделенный полномочиями владелец продукта, сотрудничающий с другими членами scrum-команды, – ядро разработки. При этом надо иметь в виду, что идеальный владелец продукта в одном проекте может плохо подходить в другом случае.
Курс: Управление проектами. Драйв
Идеи из книги
- Scrum дает гибкость, чтобы внедрять новые идеи, быстро реагировать на меняющиеся условия рынка и давление со стороны конкурентов.
- Управление продуктом по-старому. Ответственность за создание продукта поделена между маркетологом, менеджером продукта и менеджером проекта. Менеджеры команды отделены от разработчиков. Исследование рынка, планирование продукта и бизнес-анализ предшествуют разработке. После предварительного исследования требования устанавливаются окончательно. Отзывы пользователей получаются в ходе рыночного тестирования и после запуска продукта.
- Управление продуктом по-новому. Продакт-оунер отвечает за продукт и возглавляет проект. Назначение одного человека ответственным за релизы обеспечивает их непрерывность и снижает количество звеньев. Продакт-оунер активно сотрудничает со scrum-мастером и всей командой. Предварительная работа минимальна и проводится для выработки общей идеологии и прикидок по функциональности продукта. Исследование продукта – это постоянный процесс. Бэклог продукта динамичен – варьируется по отзывам клиентов и пользователей. Быстрые и частые релизы + обзорные совещания = обратная связь от пользователей и клиентов.
- Что делает владелец продукта. Он говорит, что нужно сделать; бросает вызов команде; занимается созданием высокопроизводительной команды; мыслит категориями возможностей для бизнеса; защищает команду от внешнего шума; внедряет изменения между спринтами.
- Чего не делает владелец продукта. Он не говорит, как сделать и сколько времени это займет. Он не заставляет работать угрозами. Он не концентрируется на краткосрочной выгоде, не придерживается исходных мнений и подхода «во что бы то ни стало». Он не беспокоит команду заранее. Он не рассказывает о возможных изменениях, пока они не стали реальностью. Он не позволяет изменениям проникать в спринты.
- Бэклог – это журнал продукта: сформированный по приоритетности список невыполненных дел, необходимых для создания продукта. Бэклог составлен по принципу «от наиболее к наименее важному». Важность в данном случае – это совокупный показатель прогнозируемых трудозатрат на реализацию. В бэклоге хранятся элементы: пользовательские истории, технический долг и т. д. Элементы бэклога декомпозируются на задачи – элементарные действия одного человека.
- Принцип DEEP – это 4 свойства бэклога продукта: элементы достаточно детализированы, оценены, независимы и приоритизированы. DEEP: detailed, estimated, emergent, prioritized. Бэклог не должен превращаться в спецификацию.
- Владелец продукта – член scrum-команды. Он опирается на сотрудничество с командой, а scrum-мастер и команда помогают работать над бэклогом. Роли владельца продукта и scrum-мастера дополняют друг друга. Один отвечает за продукт, другой – за правильное использование практик Scrum. Долгосрочный успех = правильный продукт + правильные методы создания продукта.
- В коммерческих проектах владелец продукта – обычно представитель клиента: менеджер продукта или маркетолог. Сам клиент принимает на себя эту роль, если продукт разрабатывается для конкретной организации. Владельцем продукта может быть и CEO.
- Характеристики правильного владельца продукта: визионер и человек действия, лидер и командный игрок, пропагандист и переговорщик, доступный и квалифицированный человек, наделенный полномочиями и преданный делу.
- Перегруженный владелец продукта – слабое звено проекта. Симптомы перегрузки: недостаточная работа над бэклогом, пропуски планирования спринтов или обзорных совещаний, непостоянный темп.
- Люди излишне концентрируются на Билле Гейтсе, Стиве Джобсе и других легендарных лидерах. В действительности не так много инноваций стали результатом гениальности одного человека. Мудрость многих лучше, чем гений одного. Эд Кэтмелл (президент Pixar): хорошая команда исправит посредственную идею, выбросит ее и придумает кое-что лучше.
- Нейробиологи: даже сверхквалифицированный человек ошибается, пытаясь справиться со всем в одиночку.
- Чтобы группа людей превратилась в сплоченную команду, требуется время.
- Избегайте больших проектов: начинайте с малого и быстро разрабатывайте продукт с минимальной функциональностью. Увеличивайте объемы медленно. Если проект большой, разработка должна разрастаться медленно и естественно: прибавляйте по 1 команде за раз. Если сразу начать работу слишком большой командой, проект станет чересчур сложным, и все потребует много времени и денег.
- Обычно владельцу продукта удается работать максимум с 2 командами. Если их больше, правильно так: сотрудничают несколько продактов, и 1 из них – главный.
- Распространенная ошибка – начать разработку продукта вообще без видения. Однако концептуальная работа должна быть сведена к минимуму. Быстро выпустите первый вариант продукта или демо-версию для клиентов и пользователей. Меньше и лучше: чтобы опередить конкурентов, сделайте меньше, чем они, и дайте экономичному умному продукту набрать обороты на надежном основании. Опирайтесь на цикл Деминга: планирование, выполнение, проверка и воздействие. Быстрые и частые релизы – способ сделать продукт, любимый покупателями.
- Джон Маэда (специалист по простоте решений, профессор Массачусетского технологического института): «Легче всего достичь простоты при помощи обдуманного исключения. Если вы сомневаетесь в функции, исключите ее». Agile-манифест: простота – один из 12 принципов. Это «искусство увеличения работы, которую вы не делаете».
- Алистер Кокберн: при расстановке приоритетов для свойств продукта 1. пожертвуйте остальным ради этого; 2. попытайтесь сохранить; 3. или пожертвуйте этим ради остального.
- Одновременная фиксация времени, бюджета и функциональности невозможна. Ограничьте время и сделайте гибкой функциональность.
- У компромиссного подхода к качеству долгосрочный отрицательный эффект. Вырабатывается технический долг – софт, который трудно улучшать и поддерживать.
- Реальный срок работы может составлять 60–160% от примерного. Проект, рассчитанный на 20 недель, способен занять 12–32 недели. Это соотношение называется «воронка неопределенности».
- Распространенные ошибки: 1. владелец продукта с недостаточными полномочиями; 2. перегруженный продакт; 3. частичный продакт; 4. удаленный продакт; 5. заместитель продакта как ложное решение системной проблемы; 6. комитет продактов; 7. «скачущий» продакт; 8. чайка-продакт; 9. незаинтересованный продакт; 10. нежизнеспособный темп; 11. стремление пустить пыль в глаза; 12. включение в отчет диаграммы сгорания задач спринта; 13. отсутствие диаграммы сгорания работ; 14. отсутствие плана релиза; 15. пассивный продакт; 16. взрывные релизы; 17. слишком много функциональности сразу; 18. ущербное качество.
Экспресс-курс: Как управлять проектной командой. 5 техник
Что еще вы узнаете?
- Как развивать владельца продукта.
- Что такое концептуальные спринты.
- На какие вопросы нужно ответить при планировании концепции продукта.
- Как работать с бэклогом продукта.
- Что такое декомпозиция элементов бэклога.
- Как планировать спринты.
- Как строить диаграмму сгорания работ.
- Как планировать релизы на больших проектах.
- Критерии готовности: как команде понять, что работа действительно сделана.
По теме. Читайте 2 интервью:
Александр Горелик: «Разработка должна быть рентабельной и приносить деньги»
Павел Капусткин: «Смотри, наиболее вредна для пиэма непродуктивная эмоция»
