Как избежать провала при разработке цифрового продукта

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

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

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

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

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

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

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

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

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