Alex.Zaytsev173
New member
Всем привет! Продолжаю серию практических заметок. Сегодня — про low-code и no-code платформы, потому что тема будоражит умы руководителей, а инженеры обычно кивают головой и молчат. За последние пять лет я поучаствовал в десятке проектов на разных low-code движках и вижу чёткую закономерность: с одной стороны — обещание собрать систему за пару недель вместо года разработки, с другой — риск нарастить долг, о котором многие не предупреждают заранее.
Нажать чтобы Перейти на сайт
Начну с того, что работает. Как-то у клиента был бизнес-процесс обработки заявок, который целиком держался на трёх Excel-файлах и одном сотруднике, который ушёл в отпуск и всё упало. Мы собрали на low-code платформе систему с формами, согласованием и простыми отчётами примерно за две недели, без единой строки кода на стороне разработки. Скорость, прозрачность для бизнеса и возможность быстро менять логику — это реальные плюсы. Внутренние инструменты, пилоты, сервисные кабинеты — там low-code часто спасает и бюджет, и время до первого результата.
Дальше начинаются нюансы. Система живёт, бизнес растёт, и простая форма превращается в сгусток бизнес-логики, размазанной по десятку модулей, автоматизаций и связок. Версионирования как в нормальной разработке нет, тестирование ручное, документация — если повезёт, и тот самый сотрудник всё уже понял без слов. Через год интеграция с CRM, бухгалтерией и внешним API превращается в квест, потому что возможности платформы упираются в потолок «из коробки», а выйти за него — уже не так просто и быстро.
Есть ещё два подводных камня, о которых говорят редко. Первый — vendor lock-in: перенос данных и логики на другую платформу или на собственную разработку стоит сопоставимо с изначальным бюджетом, а то и больше. Второй — экономика: бесплатный старт обходится дешевле, чем кажется, но подписки на пользователя, лицензии на API, отдельные тарифы за среду и поддержку складываются в сумму, которая через пару лет неожиданно превышает стоимость классического подхода. И вы не можете ни перенести, ни договориться — только платить.
Узнать подробнее →
Что я делаю сейчас? Держу простое правило: low-code — для того, что быстро проверяется, быстро меняется и не является ядром бизнеса. MVP, внутренние инструменты, временные процессы, автоматизация рутины на 3–5 человек — беру. А всё, что живёт дольше трёх лет, критично для выручки, тянет на сложные интеграции и требует высокой надёжности — проектирую с возможностью в любой момент выйти на обычную разработку, закладывая чёткие границы данных и документацию с первого дня. Иначе вместо спасения получаем красивую ловушку, из которой уютно, но очень дорого.
А у вас был опыт внедрения low-code или no-code? Где это оказалось оправданной инвестицией, а где превратилось в головную боль и дорогое техническое наследие? Буду рад реальным примерам из вашей практики.
По теме советую почитать: Как фрилансеру выстроить процессы и дорасти до студии
Нажать чтобы Перейти на сайтНачну с того, что работает. Как-то у клиента был бизнес-процесс обработки заявок, который целиком держался на трёх Excel-файлах и одном сотруднике, который ушёл в отпуск и всё упало. Мы собрали на low-code платформе систему с формами, согласованием и простыми отчётами примерно за две недели, без единой строки кода на стороне разработки. Скорость, прозрачность для бизнеса и возможность быстро менять логику — это реальные плюсы. Внутренние инструменты, пилоты, сервисные кабинеты — там low-code часто спасает и бюджет, и время до первого результата.
Дальше начинаются нюансы. Система живёт, бизнес растёт, и простая форма превращается в сгусток бизнес-логики, размазанной по десятку модулей, автоматизаций и связок. Версионирования как в нормальной разработке нет, тестирование ручное, документация — если повезёт, и тот самый сотрудник всё уже понял без слов. Через год интеграция с CRM, бухгалтерией и внешним API превращается в квест, потому что возможности платформы упираются в потолок «из коробки», а выйти за него — уже не так просто и быстро.
Есть ещё два подводных камня, о которых говорят редко. Первый — vendor lock-in: перенос данных и логики на другую платформу или на собственную разработку стоит сопоставимо с изначальным бюджетом, а то и больше. Второй — экономика: бесплатный старт обходится дешевле, чем кажется, но подписки на пользователя, лицензии на API, отдельные тарифы за среду и поддержку складываются в сумму, которая через пару лет неожиданно превышает стоимость классического подхода. И вы не можете ни перенести, ни договориться — только платить.
Узнать подробнее →Что я делаю сейчас? Держу простое правило: low-code — для того, что быстро проверяется, быстро меняется и не является ядром бизнеса. MVP, внутренние инструменты, временные процессы, автоматизация рутины на 3–5 человек — беру. А всё, что живёт дольше трёх лет, критично для выручки, тянет на сложные интеграции и требует высокой надёжности — проектирую с возможностью в любой момент выйти на обычную разработку, закладывая чёткие границы данных и документацию с первого дня. Иначе вместо спасения получаем красивую ловушку, из которой уютно, но очень дорого.
А у вас был опыт внедрения low-code или no-code? Где это оказалось оправданной инвестицией, а где превратилось в головную боль и дорогое техническое наследие? Буду рад реальным примерам из вашей практики.
По теме советую почитать: Как фрилансеру выстроить процессы и дорасти до студии