4 в 1: мифическая роль product owner

В каких случаях методология Scrum не работает

Несмотря на свою гибкость и универсальность, фрэймворк Scrum подходит не для всех компаний. Его не стоит использовать для текущей операционной деятельности. Это – способ организации работы над проектами. Чтобы метод работал, необходимо точно и полно исполнять его правила, прописанные в гайде.

Основной движущей силой в Scrum являются многофункциональные, самоорганизующиеся команды. Они умеют работать самостоятельно, и настроены на достижение положительного результата в короткие сроки. Но, согласно социологическим наблюдениям, общее количество таких сотрудников, способных к самостоятельной мотивации, составляет не более 15% от общего числа трудоспособного персонала. То есть, эффективно работать в Scrum системе может очень небольшая часть работников. Из-за этого в некоторых случаях происходит изменение функций в ролях Scrum мастера и Владельца продукта, приводящего к неверному использованию принципов методологии. Естественно, в таких условиях, система не может работать корректно.

Не стоит пытаться внедрять Scrum для создания продуктов в проектах с фиксированной ценой или таймингом. Данная идеология основана на отсутствии необходимости предварительного планирования всего проекта. Планируется только та работа, которая выполняется в текущем спринте. Существуют и другие ограничения по применению Скрам-практик.

***

Как стать Product Owner: что нужно знать и уметь

Владельцы продукта несут большую ответственность за результаты всего проекта. Им требуются глубокие знания в сфере разработки, маркетинга, монетизации, и UX-дизайна, а также развитые управленческие навыки общения и умение взаимодействовать с разными людьми. Ниже вы найдёте ключевые профессиональные навыки и soft skills, которые стоит развивать на этой позиции.

Личные качества

В числе обязанностей product owner — постоянное общение с scrum-командами, менеджерами проекта и другими заинтересованными сторонами. Коммуникативные навыки и развитая письменная речь поможет в постановке целей команде, решении проблем на этапах разработки и передачи ценностей продукта.

Анализ проблем и быстрый поиск решений — это первостепенное, что входит в обязанности product owner. Они выявляют проблемы, собирают данные и анализируют их и принимают решения на основе логических выводов. Аналитическое мышление также помогает им в расстановке приоритетов и распределении задач.

Владелец продукта нередко становится главным ответственным за проект и возглавляет команду. В его задачах — помочь сотрудникам сосредоточиться на общих целях и эффективно взаимодействовать для достижения успеха.

Возникновение спорных ситуаций во время проекта — довольно частое явление, важно уметь управлять конфликтом, чтобы команда не сбивалась с графика. Поэтому продакт оунер часто выступают в качестве посредников для разрешения внутренних конфликтов

Работать в условиях горящих дедлайнов, а также своевременно выявлять ошибки и быстро на них реагировать — обязательно входит в задачи product owner, поэтому навыки управления временем и стрессоустойчивость точно не будут лишними.

Профессиональные навыки

Ключевые вопросы, которые должен знать product owner Знаю Запланировать обучение Системы веб-аналитики: какие бывают и как использовать Как рассчитать объём рынка? Как формируется цена продукта? Основные методологии разработки продукта Что самое важное при выборе технических подрядчиков? Как разработать техническое задание программистам? Какой должна быть система вознаграждения подрядчиков? Как измерить пользовательский опыт? Что такое MVP? Что идёт раньше: прототип, PoC или MVP? Как анализировать эффективность маркетинговых каналов? Как выбрать маркетинговые каналы для привлечения пользователей? Как создать Customer Journey Map и ей пользоваться? Суть омникального подхода и его реализация Как анализировать большой объём данных? Зачем проводить email-рассылки и как это сделать? Показатели эффективности маркетинговых активностей Монетизация: выбор эффективной модели и способы применения Знаете ли вы, как реагируют пользователи на разные элементы интерфейса? Как технически происходит оплата сервиса пользователями?

Роли в управлении продуктом: менеджер по продукту и другие

В некоторых случаях управление продуктом или семейством продуктов осуществляется силами одного менеджера по продукту. Такой менеджер должен иметь глубокие познания как минимум в одной из областей, касающихся управления продуктом, и большую заинтересованность или хорошие знания в других областях. Чаще всего это опытный бизнес-маркетолог, который стремится создать продукт с выдающимися пользовательскими возможностями и свободно разговаривает на техническом языке, или руководитель технических разработок, который разбирается в продукте настолько хорошо, что может самостоятельно управлять его созданием. Такие специалисты оказались настолько редкими и ценными, что управление продуктом сегодня задает верхнюю планку заработной платы во всей сфере технологий.

Очень трудно найти сотрудников, компетентных в обеих областях, поэтому зачастую управление продуктом осуществляет небольшая группа специалистов. В Atlassian сформировалась практика, когда три ведущих специалиста из областей разработки, дизайна и бизнеса совместно работают над стратегией развития продукта. Эту тройку специалистов поддерживают менеджеры по продукту, менеджеры по маркетингу продукта и многие другие сотрудники, перечисленные ниже.

Главный директор по продукту отвечает за управление продуктом на организационном уровне. Он следит за тем, чтобы каждым продуктом управляли опытные менеджеры по продукту и их команды.
Владелец продукта играет более активную роль в разработке продукта, управляя бэклогом команды разработчиков и их коммуникациями с другими заинтересованными сторонами

Менеджер по маркетингу продукта дает командам по продукту возможность более эффективно привлекать внимание целевой аудитории и получать обратную связь от клиентов с помощью маркетинговых кампаний по продукту. Специалист по пользовательскому интерфейсу

Пользовательский интерфейс входит в основную сферу ответственности менеджера по продукту, однако специалист по пользовательскому интерфейсу оказывает большую поддержку команде по продукту тем, что изучает поведение пользователей и формулирует рекомендации по возможностям использования.

Что есть SCRUM

Скрам, он же SCRUM — это один из способов управления проектом

Помимо скрама проект можно делать в порядке постановки задач, в алфавитном порядке, по степени важности задач, в авральном режиме, хаотично; можно делать проект с восьми утра до пяти вечера или круглосуточно; можно делать проект, пока не сгоришь; можно — по графику «два через два»

Скрам — просто ещё один способ структурировать работу над проектом. Смысл скрама — разбить работу на несколько маленьких кусочков, делать их последовательно и после каждого кусочка получать понятное и видимое улучшение продукта.

Ещё в скрам входят всевозможные ритуалы, артефакты и заклинания, но это лишь подспорье для основной мысли: мы улучшаем проект маленькими рывками.

Теперь посмотрим на основные компоненты скрама.

Примеры взаимодействия с владельцем продукта:

Спонсор — Должен иметь кристально чистые отношения со спонсором с точки зрения целей и бюджета. В противном случае возникнут критические недоразумения.
Клиент — определение его желаний и ожиданий, и как помочь ему, чтобы он в конечном итоге получил удовольствие от продукта.
Скрам-мастер — вместе с ним он слуга команды. Они работают вместе, чтобы убедиться, что вы получаете преимущества Scrum.
UX и UI — понимание клиентов и их проблем требует тесного сотрудничества с ними. В противном случае продукт будет недостаточно качественным. Однако независимо от того, хорош ли продукт или достаточно хорош, у UX, UI или команды разработчиков могут быть разные мнения. Ключ в том, чтобы увидеть точку зрения каждого и принять наилучшее решение для вашего продукта.
Скрам-команда — вместе с ней должна определить цель спринта, которая затем согласуется с обязательством спринта.
Менеджеры (c-level) – в разговорах с высшим руководством компании нет места сомнениям. Его роль заключается в том, чтобы найти баланс между бизнесом и технологиями.

What is the Role of Product Owners in Scrum?

What is a product owner? The role of a product owner in Scrum is to work with stakeholders to create a vision of the product they wish to create and communicate that product vision to the Scrum team and stakeholders. It is one of the key roles in Scrum, along with the Scrum Master and the cross-functional product development team.

Product owners have many responsibilities/accountabilities. Inside the Scrum framework, one accountability of the product owner is creating and maintaining the product backlog, which is an evolving list of desired features for the product, typically ordered by priority and often written as user stories. Others can write stories, split stories, and suggest new product backlog items. At the end of the day, however, the product owner’s job is to manage the product backlog, ensuring it reflects the current understanding of what the end product should be.

Product Owners Order the Backlog & Create the Product Roadmap

One activity the product owner engages in, therefore, is to keep the product backlog in order and always be looking a few sprints ahead to ensure the product backlog items are ready for the team to bring into a future sprint.

They also collaborate with the team and stakeholders to create a product roadmap, a developing and changing picture of what will be delivered, and when. This roadmap helps remind everyone of the strategic destination, so that they don’t get lost in the day-to-day details of a project.

Free Product Owner Resources

The Product Backlog Iceberg Stakeholders & Product Owners Focus on the Most Important Items

No Matter the Job Title, Product Owners Are Empowered

Product owners sometimes carry different titles in their organization depending on their other responsibilities, such as management roles (e.g., no need to debate product manager vs product owner). But no matter their job title, they must be empowered to make decisions (in collaboration with their stakeholders) so that the team always knows they are building the right thing, for the right people, at the right time.

Product Owners Decide What, Not How

On agile projects, the product owner is responsible for product strategy: what gets created, and in what order.

Product owners are not, however, responsible for the development process (how the features are created)–the team has that accountability–or exactly how much work the team brings into each sprint. (They can make some architectural decisions, however,)

As part of release planning, and as an ongoing part of product backlog refinement, the team estimates the effort required to create each feature, and uses that estimate to help determine how long it will take to release some set of value to the customer.

During sprint planning, the team selects the amount of work they believe they can do during each sprint. The product owner does not get to say, «We have four sprints left, therefore you must do one-fourth of the product backlog this sprint.

Product Owners Set Clear, Elevating Goals

A key component of the role is to motivate the team with a clear, elevating goal. In fact, it’s essential for being effective. They are also responsible for describing the what and why of each feature to the team during formal and informal conversations throughout the sprint. That’s why it’s so important that they are readily available to their teams: their quick answers and clarifications help the team inspect and adapt in real time to ensure they are building the right thing.

In return for the Scrum team’s commitment to completing a set of product backlog items each sprint, the product owner makes a reciprocal commitment to not throw new requirements at the team during the sprint. Requirements are allowed to change (and change is encouraged) but only outside the sprint.

Once the team starts on a sprint, it remains maniacally focused on the goal of that sprint.

Теория Scrum

Scrum основан на эмпиризме и бережливом мышлении. Эмпиризм утверждает, что источником знаний является опыт, а принятие решений основывается на наблюдениях. Бережливое мышление сокращает потери и фокусируется на главном.

Scrum использует итеративный, инкрементальный подход для оптимизации предсказуемости и управления рисками. Scrum вовлекает группы людей, которые в совокупности обладают всеми навыками и опытом для выполнения работы, и по мере необходимости делятся знаниями и приобретают нужные навыки.

Четыре формальных события для инспекции и адаптации Scrum объединяет в событие-контейнер — Sprint. Эти события успешно работают, потому что они реализуют эмпирические столпы Scrum: прозрачность, инспекцию и адаптацию.

Прозрачность

Появляющиеся процесс и работа должны быть видны и тем, кто выполняет работу, и тем, кто получает результаты. Важные решения в Scrum основаны на оценке состояния трех формальных артефактов. Артефакты с низкой прозрачностью могут привести к решениям, снижающим ценность и повышающим риск.

Прозрачность делает возможной инспекцию. Инспекция без прозрачности вводит в заблуждение и является потерями.

Инспекция

Для выявления потенциально нежелательных отклонений и проблем необходимо регулярно и тщательно инспектировать артефакты Scrum и прогресс в достижении согласованных целей. Чтобы помочь с инспекцией, Scrum предоставляет каденцию в виде пяти событий.

Инспекция делает возможной адаптацию. Инспекция без адаптации считается бессмысленной. События Scrum спроектированы так, чтобы провоцировать изменения.

Адаптация

Если какие-либо аспекты процесса выходят за допустимые пределы, или если конечный продукт является неприемлемым, применяемый процесс или производимые материалы должны быть скорректированы. Корректировку необходимо произвести как можно скорее, чтобы минимизировать дальнейшее отклонение.

Адаптация становится более сложной, когда участвующие в ней люди не обладают полномочиями или не самоуправляемы. Ожидается, что Scrum Team адаптируется в тот момент, когда узнает чтото новое при инспекции.

Что почитать, чтобы лучше разобраться в скраме

Скрам Гайд. Исчерпывающее руководство по Скраму: Правила Игры / Кен Швабер, Джефф Сазерленд

Руководство по применению скрама: описывает роли, мероприятия, артефакты скрама, и правила их использования. составлен и поддерживается соавторами скрам методологии.

Скрам. Революционный метод управления проектами / Джефф Сазерленд

соавтора scrum раскрывает историю создания и основные принципы методики. Автор приводит потрясающие примеры скрама в действии. Читать обязательно, чтобы загореться тут же внедрить скрам в работу и жизнь.

Управление продуктом в Scrum. Agile-методы для вашего бизнеса / Роман Пихлер

Существенная часть посвящена владельцу продукта: его функциям, качествам, ошибкам. Автор подробно рассматривает процесс создания продукта по скрам методологии, начиная продумыванием концепции будущего продукта и заканчивая созданием отчетов.

Scrum и XP: заметки с передовой / Хенрик Книберг

о практическом применении современных подходов agile — скрама и экстремального программирования — в конкретной команде. Множество примеров, инструментов, скрам методы в действии без воды и теории.

Качества продакт-оунера

Владелец продукта должен быть коммуникабельным, поскольку эта профессия предполагает постоянный контакт с людьми. Другая незаменимая черта — стрессоустойчивость. Продакт-оунеру приходится следить за дедлайнами, учитывать интересы всех сторон, нести ответственность за результат. Найти баланс между амбициозными планами, ограниченными ресурсами, требованиями к качеству – задача не из легких.

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

Вышеупомянутые навыки относятся к soft skills, то есть к гибким навыкам. Они универсальные и пригодятся почти в любой профессии. Но владелец продукта должен также прокачивать и hard skills. Вот некоторые из них:

анализ рынка и потребностей ЦА;
управление командой;
владение основными методологиями разработки продукта;
работа с гипотезами;
приоритизация задач.

***

Требования к Product Manager:

Умение анализировать рынок и продукцию конкурентов, выявлять болевые точки и проблемы потенциальных пользователей для понимания возможных зон развития.
Понимание, как превращать потребности клиента в готовый продукт.
Опыт в проведении тестов (к примеру, A/B, A/A) и навыки анализа больших объемов информации.
Знание принципов UX/UI дизайна и инструментов для прототипирования.
Опыт в создании плана развития продукта или отдельных функций и отслеживание его выполнения.
Умение работать в постоянно-меняющейся окружающей среде и сбор необходимых аналитических данных для “процветания” продукта в этих условиях.
Понимание процессов разработки продукта, зон ответственности команды и навыки общения с заказчиками и потенциальными пользователями.
Знание английского языка — не ниже Upper Intermediate.

Kanban

Kanban (“канбан”) похож на Scrum в том, что нацелен на поддержку высокой эффективности команды. Он оптимизирует выполнение задач, помогает эффективно управлять временем и улучшать процесс работы, избегая “узких” мест в производительности.

Kanban предполагает использование доски канбан, которая отображает “что” необходимо сделать (произвести), “когда” и “в каком объеме” (количестве). Именно визуализация процесса работы является основной чертой данного фреймворка, за счет которой оптимизируется рабочий процесс.

Kanban основывается на таких принципах:

Визуализация текущей работы. Наглядность всех задач, расположенных рядом по контексту, является очень информативной. По мере выполнения задачи перемещаются из колонки в колонку (от одного этапа рабочего процесса к другому) пока не не будут выполнены. Карточки задач отображают сроки выполнения и исполнителей.
Плавные изменения. Фреймворк начинает работу с уже существующими ролями и последовательностью задач. Не требует резкой перестройки сложившихся паттернов на новый лад. Все изменения происходят постепенно, эволюционно, в ходе выявления “узких” мест.
Ограничение объема выполняемой работы. Сбалансированность потока задач не позволяет команде браться за слишком много дел сразу. Новые задачи поступают в работу только после завершения части уже присутствующих на доске. Это помогает сократить время на выполнение задач, исключить многозадачность, улучшить качество и повысить частоту выпуска готовых “продуктов” (в качестве продукта может выступать любой результат работы – программа, дизайн-проект, статья, какой-то вещественный результат и т.д.).
Четкое определение критериев. Для каждой задачи на канбан-доске должны быть прописаны критерии ее готовности. То есть то, какие обязательные пункты должны быть выполнены, чтобы задача могла получить отметку “готово”. Обязательным является этап проверки готовой задачи. Такие правила должны быть утверждены всеми членами команды.

Канбан является наименее предписывающим фреймворком и не предполагает четких ролей или жесткого ограничения процессов. Поэтому он может быть легко внедрен малым и средним бизнесом в различных сферах для увеличения прозрачности процессов, ускорения фиксации и удаления препятствий на пути проектов, повышения производительности труда сотрудников.

Лидер продукта / Ведущий менеджер продукта

Это более новая роль, и обычно это еще более старший менеджер по продуктам, который отвечает за критический продукт в компании. Эта роль может быть аналогична по рангу старшему менеджеру по продуктам или вице-президенту по продуктам, но разница в том, что они вообще не управляют другими менеджерами по продуктам – они просто исключительные менеджеры по продуктам, которые хотят работать непосредственно с продуктом и оставить управление людьми другим.

Во многих отношениях это аналогично пути архитектора в инженерном деле (в отличие от пути технического директора), и здесь необходимо сделать выбор. Просто потому, что вы отличный менеджер по продуктам и хотите продвинуться в своей карьере, это не значит, что вы должны перейти от менеджера-практика к управленцу людьми

Признание того, кто является великим лидером, а кто лучший в создании новых продуктов, одинаково важно и ценно для организации

Преимущества и недостатки Scrum

Данный метод организации подходит для создания новых продуктов. С его помощью проще организовать взаимодействие между сотрудниками разных отделов компании. Методика отличается простотой, не требует привлечения дорогостоящих ресурсов. Понять роли, артефакты, мероприятия, входящие в систему, не сложно. Она структурирует рабочий процесс, оставляя свободу для принятия решений с учётом специфики компании. Другие преимущества методологии Scrum:

Быстрая адаптация к изменяющимся требованиям, в соответствии с пожеланиями и потребностями клиента. Компании, работающие по данной системе, способны выполнить любую работу в кратчайшие сроки.
Простота освоения. Чтобы освоить работу в системе не требуется много времени.
Получение рабочих версий продукта после каждого спринта (за счёт использования итерационного принципа управления с отдельными целями в каждой итерации).
Упор на многофункциональную команду, способную работать самостоятельно, без дополнительной координации со стороны руководства.
Высокая мотивация команды, благодаря частому выпуску продуктов. Представляя новый продукт, команда видит результаты своего труда, понимает, что усилия потрачены не зря. Это даёт новые силы на дальнейшее совершенствование продукта.
Снижение расходов на разработку.
Заинтересованность клиентов, принимающих активное участие в процессе, наблюдающих, как совершенствуется продукт в течение короткого промежутка времени.
Быстрые доходы за счёт быстрой сдачи работы заказчикам.

Недостатки у Scrum также имеются. Это:

Жёсткие правила взаимодействия в команде, которые могут причинять некоторое неудобство заказчику.
Отсутствие плана реагирования на риски, возникающие в процессе реализации проекта.
Дополнительные затраты на подбор подходящего персонала и его мотивацию.

В долгосрочной перспективе перечисленные минусы полностью нивелируются. Применение Scrum технологий в компаниях разного уровня помогает реализовать разнообразные проекты, повышая свою конкурентоспособность и прибыльность.

***

How Good Are Your Communication Skills?

Communication is crucial in Agile, regardless of the role. However, there is one role in particular that requires great communication skills—the Scrum Master.

The majority of the Scrum Master’s responsibilities revolve around interactions with other members of the team and external stakeholders. The Scrum Master is the one who coaches the team in Agile practices, the one who ensures that the Product Owner understands the abilities and the capacities of the team, and who makes sure that the rest of the organization supports the team and does not impede it with non-Agile requests.

All of this needs to be communicated in a way that no one feels managed or coerced by the Scrum Master, as that would deny the whole purpose of Agile. The Scrum Master has to convey their messages in a calm, factual matter and give the other team members the chance to notice the problem and come to the solution on their own.

This is the best way to help the team grow and become better.

Of course, this is easier said than done and this is why communication skills are key for being a good Scrum Master. In other words, if you feel like you have great communication skills, you will most likely excel in the role of the Scrum Master.

Главные сложности работы в Scrum

Если вы хотите внедрить Scrum в работу своей проектной команды, важно помнить, что в его основе лежит высокий уровень самоорганизации, который должны проявлять и заказчик, и команда. Методология гибкой разработки подразумевает, что заказчик обладает навыками делегирования и умеет вести работу, не навязывая свое мнение

Специалисты также выделяют следующие ключевые сложности по внедрению Scrum:

Непонимание концепции методологии Scrum некоторыми участниками команды или стейкхолдерами, что может создавать препятствия в деятельности и привести к конфликтам. Поэтому, чтобы избежать подобной проблемы, руководители нужно отправлять членов команды Scrum на курсы по обучению методике, а также подбирать участников по конкретным психологическим критериям.
Сложность в определении оптимальных длин спринтов и балансировании между скоростью и качеством работы. Как правило, оптимальная длина спринтов на этом этапе определяется опытным путем. Что касается скорости и качества, то этот вопрос находится в зоне ответственности Владельца продукта. По окончании спринта длина, цели и ориентиры следующего спринта могут поменяться.
Необходимость постоянной адаптации к изменяющимся требованиям и условиям, что может быть сложно для некоторых команд. Чтобы команде было легче выстроить эффективную работу, сам Scrum-мастер проводит дополнительные мероприятия, направленные на поддержание принципов Скрам в команде.
Сложность в планировании. Суть методологии Scrum в том, что при разработке продукта неизвестно, сколько времени понадобится на реализацию проекта и в какие сроки будет разработана промежуточная версия продукта с определенным набором функций. В то же время такой подход дает возможность сделать действительно востребованный покупателями продукт, который работает и полезен в использовании.

Техники владельца продукта :

Встречи . Наверное, каждый день. Владелец продукта должен иметь четкий приоритет участия. При их организации он должен убедиться, что там нужные люди и что они не тратят время друг друга.

полемика . Например, технические руководители требуют отдавать предпочтение техническим темам

Он должен уметь оценить, что важно в данный момент и что будет, если он рассмотрит вопрос как приоритетный.

Мозговой штурм. Его стоит использовать, чтобы получить как можно больше идей от других и использовать их

Люди часто имеют разные и часто конфликтующие точки зрения, но без них невозможно обнаружить скрытые возможности.

Задавать вопросы . Это отличная возможность для владельца продукта больше слушать, чем говорить. Особенно, задавая трудные вопросы, вы можете добраться до сути дела.

Переговоры . Они не означают, что его мнение должно побеждать, потому что целью всегда является лучший продукт. Безусловно, ему не раз приходится вести переговоры как с командой разработчиков, так и с заинтересованными сторонами.

Где искать

Владелец продукта — это не всегда быстрый подбор, потому что в случае с Agile, — открытая коммуникация и ожидаемый результат важнее скорости.

Работные сайты

По запросу “Product Owner”, на сайте hh.ru в среднем можно найти 2 500 резюме по всей России. Конечно, не все из них с нужным опытом именно управления продуктом

Перед созданием short-list, обращайте внимание на релевантность бэкграунда и задач, над которыми он работал в проекте

Executive search

Наиболее результативный, но затратный по ресурсам метод. Составьте список компаний-доноров, которые занимаются похожим продуктом. С этим вопросом рекрутеру поможет тимлид или сами разработчики.

Хедхантинг

Кадровое ИТ-агентство

Чтобы найти продакт оунера, который подойдет именно вашему проекту, нужно знать дополнительные источники поиска. С этими задачами справится профильное ИТ-агентство.

Оставляйте заявку на нашем сайте — мы поможем найти классного специалиста.

Остались вопросы?

Scrum tools

As you have learned in this guide, the scrum framework requires product managers to consistently communicate with the scrum master, the development team, and other scrum team members to be successful. Once you have defined strategy and organized work into releases, you share this with the engineering team and they manage work implementation across sprints. You then need to keep track of progress as work is completed.

There are a few tools you can use to track progress. Using purpose-built product management software helps keep everything connected — from strategy to work management to reporting. And you are often able to move faster when product data is centrally organized and up to date. Below are a few examples of views and roadmaps you can create using product management software:

The scrum framework requires product managers to consistently communicate with the scrum master, the development team, and other scrum team members. As a product manager, once you have defined strategy and organized work into releases, you will share these plans with the engineering team. They will then pick up the baton and manage work implementation across sprints. You will need to keep track of progress as work is completed along the development cycle.

Scrum board

A scrum board is a visual representation of work to be done by the development team. This type of board is useful for organizing features into backlogs or upcoming releases. It can be used by the development team to organize and assign specific features to team members. And you can use a scrum board to track each feature through its life cycle.

Release burndown chart

A release burndown chart shows the amount of work completed per day against the amount of work remaining for a release. This chart is commonly used by product managers to monitor real-time progress, remaining work, and any changes. The engineering team will often use a sprint burndown to make sure their iterations are on track.

Agile roadmap

An agile roadmap provides a view of what the team is building and when you expect to deliver it. It helps you look at a short-term plan for achieving your product goals, with the flexibility to adjust that plan according to customer value. The example below provides a great view of current releases with their features — plus their relationship to strategic goals and initiatives.

Regardless of the methodology you use, your core responsibilities as a product manager are unchanged. Set the product strategy, plan the roadmap, and define the releases. It is your job to make sure everyone on your team understands who owns what. Using the scrum methodology can increase transparency and collective ownership throughout the development cycle. And quick iterations can keep the development team motivated with a defined goal in sight.

Before you move product development forward with scrum, take the time to understand your role in the process and the tools to use for success. Knowing these principles will set you up to lead an exceptional agile scrum team.

Start building your product roadmap with a free 30-day trial of Aha! Roadmaps — and unify your product and engineering teams with Aha! Develop.

Agile и Scrum: связь и различия

В некоторых источниках систему организации процессов Scrum ошибочно путают с методологией Agile. Несмотря на похожесть формулировки данных понятий, у них есть существенные ключевые различия. Agile – это общий набор принципов и ценностей, реализующийся путём применения гибких подходов к работе над проектами. Эджайл в своей основе состоит из четырёх ценностей, описанных в Манифесте:

Люди, их взаимодействие друг с другом важнее инструментов.
Работающий продукт важнее сопровождающей его документации.
Сотрудничество с заказчиком важнее согласования условий по контракту.
Готовность к быстрым изменениям важнее чёткого следования плану.

Философия Agile базируется на двенадцати принципах:

Удовлетворение потребностей заказчика в приоритете. Главное, чтобы клиент был доволен. Поэтому команда регулярно предоставляет ему промежуточные результаты работы, не дожидаясь финала проекта.
Изменение требований допускается на всех стадиях разработки.
Работающий продукт должен выходить как можно чаще.
Постоянная совместная работа исполнителей и заказчиков.
Привлечение команды профессионалов для работы над проектом.
Живое общение внутри команды.
Цель рабочего процесса – полностью рабочий продукт.
Устойчивый темп работы.
Совершенствование проекта на всех его этапах.
Минимум лишней работы.
Самоорганизующиеся команды.
Стремление постоянно улучшать свои результаты.

Получается, разница методологий в том, что фреймворк Scrum – это один из подходов семейства Agile, использующийся для реализации её принципов в практических условиях.

***

Вы владелец продукта?

Нравится ли вам каждый день разговаривать со многими людьми в разных контекстах?
Вы готовы к частым конфликтам?
Нравится ли вам проводить встречи?
Вы больше слушаете, чем говорите?
Вы умеете вести переговоры?
Вы готовы принимать решения в любое время?

Краткое содержание

Роль владельца продукта определенно можно назвать непростой, поскольку она требует принятия множества решений на каждом этапе . Команда разработчиков, как и компания, ожидают, что он определит весь процесс выпуска продукта. Именно ему предстоит расставить приоритеты, показатели эффективности и собрать требования.
Бесчисленные вопросы и альтернативы возникнут в процессе разработки; разработчики найдут несколько вариантов функции или сообщат вам, что она готова к использованию. Он решает, что оптимально для продукта и когда он будет выпущен ; потому что он должен вести всю команду таким образом, чтобы максимизировать стоимость компании.

Заключение

Метод управления Scrum – революционный метод в разработке программного обеспечения и новых продуктов. Его преимущество заключается в том, что он способен дать очень высокие результаты, особенно в ситуации непрерывных изменений. Но прежде чем внедрить Scrum и эффективно его использовать, нужно пересмотреть собственный подход к организации задач и принять тот факт, что в Скрам команда работает с высоким уровнем самоорганизации.

Отношения по принципу «начальник-подчиненный» или «заказчик-подрядчик» тут не сработают. Все члены Скрам-команды – от Владельца продукта до Тестировщиков – должны быть заинтересованы в успехе реального продукта Scrum. Без понимания единой цели и активного сотрудничества между специалистами разного профиля получить на выходе качественный проект Scrum, готовый к продажам, к сожалению, не сможете.