Кого можно назвать владельцем продукта? Изначально такого понятия не существовало. Был менеджер проекта. И его обязанности были, мягко говоря, противоречивы. По сути, менеджер проекта отвечал за прямо противоположные вещи. Он находился и на стороне исполнителя, и на стороне заказчика, несмотря на то, что их интересы расходятся. Хотя управление проектами строится на слаженной командной работе. Менеджер не следил за развитием продукта после сдачи, не продавал и не продвигал его. В зону его ответственности входила только разработка продукта. Не исключено, что как раз из-за этого многие перспективные проекты не устояли и провалились.
Что сделали разработчики Scrum?
Управление проектами по методике Scrum помогает решить подобные проблемы. Разработчики предложили распределить задачи менеджера между специалистами, ответственными за работу команды, и владельцами продукта.
Методика Scrum предполагает, что владелец продукта отвечает не только за разработку и внедрение продукта, но и за его работу в течение определенного времени. К тому же, в зону ответственности владельца также вошло продвижение софта и продажи.
Таким образом, владелец продукта — это специалист, обладающий компетенциями сразу в нескольких сферах и отвечающий за полный цикл работы созданного софта. Он должен быть подкован и в области разработки различных программных обеспечений, и в области продвижения. Владелец продукта мыслит наперед и предвидит ожидаемые показатели.
Идеальный владелец продукта
Если бы существовал эталон понятия «владелец продукта», то он отвечал бы следующим характеристикам:
- Успешный опыт работы в сфере ИТ по разработке и дизайну.
- Отличные коммуникативные навыки.
- Руководящий опыт в реализации проектов.
- Знания в области продаж и маркетинга.
На самом же деле, владельцем продукта может стать любой инициативный человек, у которого возникнет идея создания продукта и желание учиться.
Какие ошибки может допустить владелец продукта?
- Предлагает идеи и цели, которые невозможно измерить. Каждая цель должна иметь конечное измерение. А каждое измерение должно быть аргументировано.
- Не объясняет коллегам, зачем нужны изменения и нововведения. Команда не понимает, какая цель преследуется, и выполняет работу не так, как необходимо, либо очень медленно, не имея достаточной мотивации. Чтобы управление проектами действительно вышло на новый уровень, владелец продукта обязан доносить идею всей деятельности команды до сотрудников так, чтобы они ее разделяли и поддерживали, иначе работа будет неэффективной.
- Не принимает участие в запуске и реализации идей. Отстраненный и незаинтересованный владелец проекта получит такую же команду. Он должен погрузиться в работу на все 100% и иметь представление о каждом этапе работы.
- Не анализирует результат. Разработка продукта может сопровождаться ошибками и недочетами. Необходимо видеть, что из запланированного не получается, и выяснять почему.
- Не принимает участие в приемке готовой работы. Владелец должен увидеть и рецензировать проект до того, как он будет сдан заказчику. Возможно, он заметит какие-то недочеты или сможет дополнить его новыми идеями.
- Не задумывается о будущем проекта. Зачастую владелец думает только о том, как сдать проект в срок и выполнить работу качественно. Но дальнейшая судьба проекта важна не меньше, он должен адекватно функционировать и оправдывать вложенные ресурсы.
Чтобы стать хорошим владельцем продукта, нужно развиваться не только в своей сфере, но и в смежных областях, налаживать связи и приносить пользу команде и партнерам.
Спасибо за внимание! Еще больше интересных статей об ИТ на сайте deasoft.ru