{"id":14275,"url":"\/distributions\/14275\/click?bit=1&hash=bccbaeb320d3784aa2d1badbee38ca8d11406e8938daaca7e74be177682eb28b","title":"\u041d\u0430 \u0447\u0451\u043c \u0437\u0430\u0440\u0430\u0431\u0430\u0442\u044b\u0432\u0430\u044e\u0442 \u043f\u0440\u043e\u0444\u0435\u0441\u0441\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u044b\u0435 \u043f\u0440\u043e\u0434\u0430\u0432\u0446\u044b \u0430\u0432\u0442\u043e?","buttonText":"\u0423\u0437\u043d\u0430\u0442\u044c","imageUuid":"f72066c6-8459-501b-aea6-770cd3ac60a6"}

Как избежать провала при разработке digital-продукта?

Обысов Александр, директор по развитию Arcsinus

Диджитализация многих сфер экономики неизбежна. Однако превратиться из традиционного - в IT-бизнес непросто. По статистике, в мире не укладываются в запланированные сроки и бюджет или вовсе не выпускаются около 60-65% всех IT-проектов. По оценкам участников российского рынка, провалов гораздо больше - 7 из 10.

Наиболее распространенные причины неудач при разработке digital - продукта:

  • Низкая квалификация исполнителей.
  • Распределенность продуктовой команды.

  • Стремление к выпуску сразу промышленного полнофункционального продукта без проверки гипотез на ранней стадии.

А теперь подробнее о каждой проблеме и оптимальных вариантах решения.

Найти dream team

Первая проблема, которая встает перед компаниями, вступившими на путь диджитализации — подбор специалистов. Здесь есть два варианта: формировать собственную (in-house) команду или заказывать разработку на аутсорсинге. На вопрос, какой вариант лучше, хочется ответить крылатой фразой: «оба хуже».

В первом случае, серьезным вызовом, даже для крупной компании, будет битва за кадры. Конкурировать придется с IT-гигантами. И если у компании нет сильного бренда, и она не готова платить больше, чем, например, «Яндекс» или Mail.ru Group, рассчитывать на привлечение высококлассных специалистов - сложно.

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

При этом важно четко прописать в договоре с подрядчиком все нюансы относительно прав на интеллектуальную собственность. К сожалению, до сих пор встречаются случаи, когда заказчик, отказываясь от услуг компании-разработчика, не может получить у него исходный код и другие необходимые материалы поскольку права остаются у подрядчика. А значит разработку необходимо будет начинать «с нуля».

Важно повышать и собственную экспертизу в digital. Это поможет выбрать добросовестных заказчиков, не склонных завышать цены или увеличивать сроки.

Сформировать единую команду

Другой проблемой является распределенность участников проекта. Как правило, задачи, которые решаются с помощью IT-продуктов, предполагают несколько каналов взаимодействия с пользователями, а сами системы являются многокомпонентными. Например, они могут включать сайт, мобильные приложения для iOS и Android, а также сервер для хранения данных и реализации бизнес-логики.

В таких системах крайне важной становится сквозная аналитика и обеспечение единого продуктового видения всех участников проекта. Но, зачастую, для реализации проектов привлекается несколько подрядчиков: отдельная команда для разработки сайта, отдельная для мобильных приложений, еще одна делает дизайн. На деле это приводит к размытию ответственности, усложнению коммуникаций и фрагментированию продуктового видения. Каждая команда мыслит только в пределах системы, которой она занимается, но не видит всего продукта. Результатом такой распределенности становятся проблемы при интеграции компонент, снижение эффективности совместной работы, а зачастую и итоговый провал всего проекта.

Однако, даже понимая ценность формирования единой команды, обеспечения единого продуктового видения и чёткого распределения ответственности в проекте, сформировать такую команду непросто. По статистике, сейчас в России всего 4,3% компаний, занимающихся веб-разработкой, также занимается разработкой мобильных приложений.

Проверять гипотезы на ранних стадиях

Третья типичная ошибка - стремление к выпуску сразу промышленного полнофункционального продукта. Проект изначально реализуется как масштабный, к работе подключается большое количество департаментов, продукт долго создается и шлифуется. Однако результатом такой работы зачастую становится выпуск на рынок продукта, не востребованного пользователями и не приносящего пользу бизнесу.

Чтобы избежать такой ситуации, гипотезы следует проверять еще на ранней стадии. Сделать это позволяет выпуск MVP (minimum viable product) — минимально жизнеспособного продукта, то есть такого, который решает основную задачу проекта наиболее простым и быстрым способом. С его помощью можно на раннем этапе получить обратную связь от рынка и пользователей. И скорректировать, уточнить продуктовое видение, направить развитие продукта в верном направлении.

Если MVP окажется невостребованным, то это, как ни странно, тоже хороший результат. Это позволит отказаться от проекта на раннем этапе, и тем самым сэкономить ресурсы, направив их на проверку новых и ускорение развития успешных гипотез.

Резюме

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

0
Комментарии

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку

Комментарий удален модератором

Развернуть ветку
-3 комментариев
Раскрывать всегда