Николай Николенко, технический директор KODE
Основная аудитория low-code технологий – это заказчики с небольшим бюджетом и сроками вывода продукта на рынок. Они могут быть не сильно погружены в технические нюансы разработки, для них важно дешево и быстро выпустить продукт, проверить гипотезу и начать работу. При этом Low-code – это удел не только стартапов. Даже крупные компании, чьи клиенты привыкли к высокому уровню сервиса и качественным IT-решениям, обращают внимание на Low-code.
К сожалению, у такого решения есть существенные ограничения, которые важно понимать на этапе выбора. В первую очередь, универсальность кода не дает большого разнообразия в проработке UX и UI: шаблонные большие формы, не изменяемая последовательность действий пользователя, отсутствие правильной реакции на ошибки, возникающие в процессе (например, у пользователя пустой экран, вместо экрана с целевым действием). Это сильно ухудшает пользовательский опыт и в конечном счете влияет на его лояльность.
Low-code, как и почти любое эконом-решение, имеет недоработки и недостаточную технологическую актуальность. Сложно вносить изменения в логику работы решения или интеграций с другими системами: без вмешательства разработчика в Low-code решениях почти невозможно что-то починить, а если обращаться к создателю платформы напрямую, ждать ответа придется очень долго.
Кроме того, нельзя добиться безопасного решения при использовании Low-code платформ: хранение персональных данных, обработка и передача критичных данных на стороне платформы в незащищенном контуре, хранение ключей доступа к интегрируемым системам на стороне Low-code решения.
Low-code неплохо подходит для MVP. Он позволяет, используя типовые компоненты накидать путь пользователя и проверить гипотезу, получить первых клиентов. На рынке уже довольно много Low-code решений заточенных под определенную сферу.
Например, небольшие банки, которые только начинают свой путь, используют технологии Low-code, чтобы стартовать, но как только они выходят на стабильный доход и готовы развиваться, обращаются к заказной разработке. Потому что только так можно произвести отстройку от конкурентов и сделать уникальный продукт.
Наиболее жизненный вариант - это компромисс, когда сочетается быстрота и гибкость Low-code, безопасность и проработанность кастомных решений.
Например, если продукту необходим какой-то простой, универсальный модуль: чат поддержки мобильного банкинга, новая заявка на банковский продукт, подойдет уже готовое решение в виде SDK, библиотек или WebView. Такое решение можно внедрить за несколько недель или даже дней. Это сильно сэкономит затраты заказчика на разработку.
Далее менеджеры продукта и аналитики могут оценить результат внедрения такого решения: понять как пользователи его используют, какие барьеры возникают, как это улучшить. И оценить возможности по доработке Low-code решения.
Если количество пользователей не достигло целевого показателя, но при этом текущим решением пользуются и не возникает больших проблем, то можно оставить как есть.
Если решение не позволяет построить нужный нам UI/UX для пользователя, или добавить дополнительный функционал, но у нас есть фактическое подтверждение востребованности нашей гипотезы, то мы смело можем начинать реализовывать то, что задумали не ограничивая себя платформой Low-code.
