Первая часть тут , вторая часть тут.
Есть работоспособная система, но она не работает. Почему так произошло? Потому что оказалась никому не нужна. Nuff said.
Но пора разобраться с причинами.
Причина 1. Непонимание бизнес-модели.
Заказчик просто не знал, что на самом деле он будет делать со всем великолепным сервисом. Отсутствовало понимание того, что продажи и обслуживание в оффлайне или даже в интернет-магазине имеет мало общего с бизнес-моделью маркетплейса.
Причина 2. Не та аудитория.
Заказчик полагал, что его самым важным сегментом пользователей маркетплейса будут непосредственные покупатели товаров и потребители услуг, упуская из виду, что маркетплейс - это двусторонняя платформа. А вот поставщики товаров и услуг совершенно не горели желанием приходить на платформу, разбираться с интерфейсом, да еще и комиссию платить кому-то.
Выходит, что такой важный этап, как анализ рынка и потенциальной аудитории был упущен. Если бы был проведен хотя бы предварительный аудит проблематики, то компания смогла бы переориентировать свои усилия на другую аудиторию.
Причина 3. Нехватка времени.
Для курирования проекта со стороны заказчика были выделены опытные и разбирающиеся в маркетинге, продажах и логистике специалисты уровня топ-менеджмента. Естественно, у них не хватало времени ни на обсуждения, ни на согласование требований, ни на качественную приемку.
Причина 4. Отсутствие ответственного.
Все указанные выше причины являлись следствием самой основной — отсутствия конечного заинтересованного ответственного лица, того самого продакт оунера.
Как видно из схемы распределения ролей на проекте, ни у кого из команды не было задачи на исследования, анализ рынка, определение бизнес-модели и приоритизацию фич.
Что в результате? Релиз постоянно откладывался, проект так и не был запущен, а миллионы рублей потрачены.
Мало просто ввести на проекте роль владельца продукта, необходимо соотнести эту роль с конкретным ответственным лицом.
Обязательный чек-лист:
- Продукт — приоритет для задач.
- Определенная зона ответственности (продукт и его развитие).
- Полномочия на принятие решений (приоритет разработки и внедрения).
- Управление бюджетом продукта.
- Выделенное время.
- …
- ???
- Profit!!!111
В противном случае проект пойдет puppy’s day.
На двух примерах мы видим, как важно на проекте добиться определенности и управляемости. Для того, чтобы появилась возможность:
- составлять прогнозы
- определить и понять ошибку
- оценить качество
- рассчитать бюджет и эффективность
- развивать продукт
Пост основан на тезисах доклада “Владелец продукта. Почему без него так плохо”, представленному мной на конференции “РИФ.Технологии” в Ульяновске осенью 2017 года.
Stay tuned.
С любовью, Гузель
P.S. Посты канала «Байки из проектного офиса»