Ekaterina.Belov731
New member
Три года назад я возглавил проект автоматизации внутренних процессов в компании, где мне предложили отказаться от разработки с нуля и взять low-code платформу. Звучало идеально: дешевле, быстрее, без зависимости от штатной команды разработчиков. Через месяц у нас работало первое приложение для управления заказами, через три — ещё пять. Руководство было в восторге: мы сэкономили около 40% бюджета на разработку.
Нажать чтобы Перейти на сайт
Проблемы начались на четвёртом месяце. Каждое новое приложение строилось на собственных конструкторах и визуальных схемах, которые понятны только тому, кто их создавал. Когда один из бизнес-пользователей уволился, мы потеряли доступ к логике трёх систем. Документации не существовало — зачем она нужна, если «всё наглядно» в редакторе? Мы тратили недели на то, чтобы понять, как работает система, которую создали за два дня.
Второй удар пришёл, когда бизнес захотел интеграции. Low-code платформы прекрасно работают в вакууме, но как только появляется потребность в сложном API, кастомной бизнес-логике или работе с нестандартными базами данных, визуальные конструкторы упираются в потолок. Мы в итоге нанимали внешних разработчиков, которые неделями разбирались в чужих конструкторах, чтобы сделать то, что на чистом коде заняло бы вдвое меньше времени.
Не забываем про стоимость подписок. Казалось, что low-code — это разовые вложения, а оказалось, что подписка растёт пропорционально числу пользователей и приложений. Через полтора года мы платили больше за лицензии, чем если бы писали код сами. Плюс вендор-лок: вся наша инфраструктура завязана на конкретную платформу, и миграция на другую обойдётся в перестройку десятков приложений.
Узнать подробнее →
Мой главный вывод: low-code — это не про экономию, а про скорость прототипирования. Он оправдан для пилотов, внутренних инструментов с коротким жизненным циклом, задач, которые не критичны для бизнеса. Но строить корпоративную IT-архитектуру на low-code — это вешать дом на временную опору. Мы это узнали дорого.
А вы сталкивались с ситуациями, когда low-code решения превращались в технический долг? Где для вас проходит граница между «оправданным использованием» и «дорогим экспериментом»?
По теме советую почитать: Автоматизация бизнес-процессов: с чего начать без хаоса
Нажать чтобы Перейти на сайтПроблемы начались на четвёртом месяце. Каждое новое приложение строилось на собственных конструкторах и визуальных схемах, которые понятны только тому, кто их создавал. Когда один из бизнес-пользователей уволился, мы потеряли доступ к логике трёх систем. Документации не существовало — зачем она нужна, если «всё наглядно» в редакторе? Мы тратили недели на то, чтобы понять, как работает система, которую создали за два дня.
Второй удар пришёл, когда бизнес захотел интеграции. Low-code платформы прекрасно работают в вакууме, но как только появляется потребность в сложном API, кастомной бизнес-логике или работе с нестандартными базами данных, визуальные конструкторы упираются в потолок. Мы в итоге нанимали внешних разработчиков, которые неделями разбирались в чужих конструкторах, чтобы сделать то, что на чистом коде заняло бы вдвое меньше времени.
Не забываем про стоимость подписок. Казалось, что low-code — это разовые вложения, а оказалось, что подписка растёт пропорционально числу пользователей и приложений. Через полтора года мы платили больше за лицензии, чем если бы писали код сами. Плюс вендор-лок: вся наша инфраструктура завязана на конкретную платформу, и миграция на другую обойдётся в перестройку десятков приложений.
Узнать подробнее →Мой главный вывод: low-code — это не про экономию, а про скорость прототипирования. Он оправдан для пилотов, внутренних инструментов с коротким жизненным циклом, задач, которые не критичны для бизнеса. Но строить корпоративную IT-архитектуру на low-code — это вешать дом на временную опору. Мы это узнали дорого.
А вы сталкивались с ситуациями, когда low-code решения превращались в технический долг? Где для вас проходит граница между «оправданным использованием» и «дорогим экспериментом»?
По теме советую почитать: Автоматизация бизнес-процессов: с чего начать без хаоса