Владелец продукта: почему без него так плохо. Часть 1

Если вы тут в блоге, значит, вы, как и я, so excited от проектного управления и всего, что с ним связано.

Отчего одни проекты взлетают, а другие нет? От чего зависит успешность проекта?

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

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

Зона ответственности Владельца продукта

Наиболее важные аспекты при работе над продуктом:

• Видение (концепция) продукта / проекта
• Границы
• Целевая аудитория и пользователи продукта
• Проблемы, которые решает продукт
• Требования к продукту
• Приоритеты
• Продвижение

Работа над этими аспектами и является задачей владельца продукта (далее — ВП).

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

Рассмотрим удачный кейс.

Кейс разработки системы бэкофиса

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

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

Бизнес-задачи сервиса и показатели эффективности были определены сразу же на этапе анализа требований. Постановка приоритетов шла от непосредственного владельца продукта, в роли которого выступал один из директоров заказчика.

Владелец продукта взял на себя следующие вопросы:

• Формулирование конечного результата
• Постановка бизнес-задачи
• Определение заинтересованных лиц и их влияния
• Оптимизация службы доставки
• Определение показателей эффективности

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

Благодаря такому подходу проект имел четкие границы и приоритет задач для выполнения.

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

Данное решение сработало:

• появился единый интерфейс для работы оператора (вместо четырёх),
• время обработки одного заказа сократилось на 75%,
• среднее количество заказов выросло в полтора раза,
• лимит времени на одну доставку стал постоянным,
• заказы на доставку перестали теряться на кухне,
• вырос средний чек,
• был автоматизирован мониторинг изготовления заказа,
• причины возникновения проблем стали прозрачными,
• были убраны с десяток узких и неочевидных мест в процессе.

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

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