Главное Свежее Вакансии   Проекты
Продвинуть свой проект
😼
Выбор
редакции
1 227 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

На успех или провал проекта можно повлиять. Вот пусть продакт оунер с этим и разбирается.

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

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

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

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

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

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

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

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

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

b_5d98d43e5c3af.jpg

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

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

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

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

b_5d98d46826c40.jpg

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

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

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

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

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

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

b_5d98d4853a25a.jpg

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

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

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

b_5d98d4a27ca66.jpg

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

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Первые Новые Популярные
Комментариев еще не оставлено
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать
Комментарии

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.