Высокая стоимость разработки мешает 37% компаний запускать сервисы: как Oberton решает эту проблему

В статье расскажем, из-за чего стоимость IT-разработки растёт и как сократить расходы на внедрение сервисов для бизнеса в 2-3 раза.

С момента ухода иностранных вендоров с российского рынка компании пересматривают подходы к цифровизации. 34% представителей бизнеса внедряют собственное ПО силами внутренней разработки, столько же — покупают и адаптируют готовый софт. Но эти методы — дорогие и долгие.

Самый востребованный способ заменить ушедшие сервисы — эксперименты с low-code платформами. 70% российских компаний прибегают к low-code разработке, чтобы оптимизировать расходы на запуск новых продуктов.

В апреле 2024 года мы выступали на одной из крупнейших продуктовых конференций в России и СНГ — ProductCamp. Антон Макаров — руководитель Creonit — рассказывал про наш продукт для запуска продуктов, платформу для low-code разработки Oberton. В докладе поделился обзором проблем B2B-рынка, связанных с созданием и внедрением бизнес-приложений.

Боли при разработке B2B-сервисов

Во время подготовки к докладу провели небольшое исследование, чтобы узнать, с какими проблемами чаще всего сталкиваются компании в IT-разработке. Провели опросы в продуктовых чатах, отдельно опрашивали руководителей проектов и продактов о самых частых проблемах, с которыми они сталкиваются. По итогу выделили топ-5 самых частых трудностей. 

1. Долгая разработка. Создание цифрового продукта может длиться несколько лет. Часто сроки затягивают длинные согласования, особенно остро эта проблема стоит в компаниях с линейной структурой управления. 
2. Высокая стоимость производства.
3. Неудовлетворённость результатом. Как следствие – правки после разработки. Иногда правки такие серьёзные, что проект нужно переделывать с нуля. 
4. Запрет на использование SaaS или No-Code из-за политики безопасности компании. После массового ухода вендоров с российского рынка в 2022 году все стремятся пользоваться собственными решениями и хранить данные на собственных серверах. 
5. Сложности с внедрением коробочных решений. Не всегда удаётся адаптировать коробочное решение под бизнес-процессы компании. В таком случае коробку кастомизируют, в том числе за счёт “костылей”, либо не используют вовсе. В итоге чаще всего доработка готового продукта обходится дороже, чем разработка с нуля.

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

Разберём проблему высокой стоимости проекта.

Что повышает стоимость разработки

1. Простои команды в ожидании фидбэка

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

2. Отсутствие чётких требований к результатам разработки и сложные артефакты

Если нет чётких требований к результатам разработки, компания получит решение, которое может не соответствовать её ожиданиям. Частая история, когда лица, принимающие решения, начинают вникать в продукт только на этапе, когда уже увидели готовый интерфейс. Это нормально, потому у стейкхолдеров не всегда есть время разбираться в артефактах разработки, смотреть пользовательские истории, читать техническое задание и другое. Им могут показать картинки будущего интерфейса и рассказать, как он будет работать, но когда “потрогаешь” живой интерфейс, то может оказаться, что не все решения были такими уж удобными. Как итог — ожидания и реальность не совпадают. 

Пример из практики: образовательный проект 3 раза заказывал решение одной и той же задачи

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

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

Нередко такие кейсы осложняются сменой руководства. На место одного стейкхолдера посередине проекта приходит новый, а вместе с ним — новые ожидания от сервиса.

3. Нет опыта в создании продуктов с нуля 

Инхаус-команды хорошо развивают готовые проекты, но опыта в создании продуктов с нуля команде может не хватать. Переключиться на создание нового сервиса — не простая задача. 

Не всегда у команды есть необходимые знания и опыт в нужной области, а также специалисты (например, продакт-менеджер с опытом запуска продуктов с нуля)

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

Пример из практики: нефтяная компания, у которой «что-то не получилось»

Компания вела ежедневную статистику объёмов отгруженной продукции в Excel. Было много ручной работы: несколько отделов ежедневно из разных источников обновляли данные в таблицах и обменивались ими. Затем менеджер делал мини-отчёты и рассылали их нужным лицам по почте.

Руководитель во время пресейла сказал такую фразу: «Мы дважды пытались оцифровать процесс и отказаться от Excel, но не получилось…». То есть были сроки, финансирование, команда, но в какой-то момент просто...не получилось? 

4. Доработка готовых решений

На рынке много готовых продуктов, внедрение которых в теории должно решить проблемы бизнеса: LMS-платформы, сервисы для автоматизации рекрутинга и так далее. 

Все они обещают быстрое внедрение, лёгкость в использовании и повышение операционной эффективности. 

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

Как разработка на Oberton решает эти проблемы

Мы не просто так изучали проблемы рынка. Нашей целью было разработать инструмент, который избавит бизнес от существующих сложностей. 

Сделать продукт, который:

• Позволит быстро разрабатывать бизнес-приложения.
• Снизит стоимость разработки.
• Можно беспрепятственно размещать на серверах компании-заказчика.
• Не требует кастомизации ядра. Чтобы на его базе можно было запустить любой B2B-сервис: от CRM до HR-портала.

Так появился Oberton — инструмент для быстрой оцифровки бизнес-процессов. 

Преимущества Oberton

1. В два раза меньше согласований. При разработке интерфейс генерируется автоматически на основе моделей, описанных на бэкенде. Таким образом, исключаем из производственного процесса этапы дизайна и фронтенд-разработки. Меньше этапов — меньше согласований и простоев команды. Готовый продукт получаем за ~2 месяца без учёта интеграций.
2. Для запуска продукта хватает команды минимум из четырёх человек. Хватит руководителя проекта, бизнес-аналитика, python-разработчика и QA-инженера. В то же время для классической разработки требуется минимум 7 человек с дизайнером, фронтенд-разработчиком и ещё один бэкендером. Это уменьшает фонд оплаты труда работников, а значит, стоимость разработки и поддержки продукта.
3. Демо-стенд продукта можно подготовить за 5 дней. Это готовая часть программного продукта, которую можно «потрогать». Например, посмотреть, как будет работать личный кабинет, как заполнять данные в карточке кандидата, экспортировать документы и так далее. Это позволят управлять ожиданиями стейкхолдеров и снижает риск платных переработок сервиса в будущем.
4. Готовый сервис может поддерживать любой python-разработчик. Готовим проектную документацию при передаче исходного кода.
5. Нет кастомизации ядра и встроенных интеграций. На базе Oberton можно разработать любой B2B-сервис, который будет открыт для кастомизаций и интеграций. Не придётся долго и дорого переделывать готовое решение, если в бизнес-приложении потребуется модуль для нового отдела.

Итого

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

При этом оцифровка бизнес-процессов не обязательно должна быть стрессом для всей компании и аутсорс-команд. Готовое решение можно получить за ~2 месяца с помощью Oberton.

Если вы хотите запустить B2B-продукт, но боитесь приступать к разработке — закажите демо.