Да, мы следим за Scrum уже некоторое время, и да, это вирусный термин, который многим не нравится из-за огромного ажиотажа. Хотя было доказано, что она успешна для многих организаций, это всего лишь средство для достижения цели и определенно не универсальная истина для всех. На самом деле, одно конкретное слабое звено может стать пагубным для успеха продукта — Владелец Продукта.
Важность владельца продукта
Грубо говоря, в любой Scrum-команде задача разработчиков — выполнять работу, а задача владельца продукта — следить за тем, чтобы остальная часть команды сосредоточилась на правильной работе. Это означает, что PO несет ответственность за увеличение ROI, полученного в этой команде организацией. Вот некоторые из ежедневных задач владельца продукта:
- Синхронизация информации между разработчиками, маркетологами и менеджментом требует глубокого понимания каждой области.
- Понимание потребностей и проблем клиента. PO должен стать экспертом в проблеме, которую решает продукт — предполагает тесный контакт с целевой аудиторией.
- Синхронизация информации с командами продаж и поддержки — опять же, способствует пониманию проблемы.
- Убедиться, что разработка идет в рамках установленного бюджета и соблюдены все сроки.
- Создание пользовательских историй, преобразование их в тикеты (задачи) и определение их приоритетности в зависимости от важности, чтобы задать направление продукта. Билеты должны содержать подробную информацию о каждой функции, чтобы команда разработчиков могла понять, что нужно сделать и почему. Часто это связано с созданием макетов.
- Исследование рынка, связанное с отраслью, в которой будет находиться продукт, с целью понимания конкурентной среды — часто включает посещение конференций и тематических мероприятий.
- Работа с QA, чтобы убедиться, что продукт работает правильно и в соответствии с заданной спецификацией.
- Решение любого вопроса, который неизбежно возникнет внутри команды. В Scrum-команде работают вместе разные люди с разными характерами, поэтому, как правило, каждый день возникают трения. Задача PO — решить эти проблемы до того, как они выйдут из-под контроля и станут препятствием для доставки продукта.
Даже после успешной доставки продукта владелец продукта должен работать в тесном контакте с командой продаж и поддержки, чтобы убедиться, что они знают, как должным образом сообщать о ценности продукта и как справляться с возникающими проблемами клиентов.
Подождите, так почему же Scrum-команды терпят неудачу?
Несмотря на огромный список обязанностей, связанных с работой Владельца Продукта, важность этой роли часто недооценивают. Тем более сами По. Они часто хранят молчание во время командных спринтов, уделяя внимание разработчикам, обсуждающим технические вопросы, чувствуя, что это более важно, чем общее направление продукта.
Удивительно мало ресурсов тратится на развитие необходимых навыков у Владельца Продукта по сравнению с остальной частью команды, даже несмотря на то, что окончательная ответственность за возможный сбой продукта будет лежать именно на PO. Вот почему многие организации, решившие внедрить подход Scrum, в конечном итоге не достигают ожидаемых результатов или вовсе терпят неудачу.
Самый важный шаг, который вы можете предпринять, чтобы предотвратить такой мрачный сценарий, — это работать над повышением вовлеченности PO в команде. Остальная часть Скрам-команды должна лучше понимать видение продукта, знать, какие возможности существуют для того, чтобы срезать углы, а где не следует экономить ресурсы. Кроме того, ЗП должен быть как можно более подробным в отношении каждой поставленной задачи. Команда не должна быть вынуждена делать предположения без заказа на покупку относительно функциональности продукта, иначе результат может оказаться совсем не таким, как предполагалось. Каждая неопределенность должна быть рассмотрена на месте, до обзора спринта.
Большую часть неясности можно смягчить за счет надлежащего ведения журнала невыполненных работ. Однако здесь возникает еще одна проблема: чрезмерно подробное описание заявки может почти не оставить разработчикам творческой свободы, тем самым сделав их работу скучной или даже снизив шансы на новаторские подходы. Это тонкий баланс, на самом деле.
Владелец продукта, возможно, является самой важной ролью в любом конкретном проекте по разработке программного обеспечения, и хотя большинство функций этой роли могут показаться гибкими навыками, далеко не факт, что PO автоматически примет требования должности, как только компания решит перейти на Scrum. Переход к Scrum должен быть в значительной степени сосредоточен, даже, возможно, вращаться вокруг создания твердой фигуры PO, которая приведет направление разработки к успешному продукту.
Вы можете просмотреть исходный пост на нашей главной странице.
