В современном мире бизнес и технологии постоянно развиваются и адаптируются к потребностям рынка. Одним из таких трендов является использование low-code и no-code платформ в разработке программного обеспечения и бизнесе. Сегодня Low-code и no-code платформы предоставляют возможность быстрого создания и автоматизации бизнес-процессов с помощью графических интерфейсов и предустановленных инструментов. Это позволяет бизнесу ускорить разработку продуктов, сократить расходы и получить более качественный результат, при этом не требуя глубоких знаний программирования. Также эти решения могут использоваться разработчиками в качестве дополнения к кастомным проектам, путем интеграции готовых компонентов для ускорения процесса разработки и оптимизации работы над проектом. Вместе с экспертами мы обсудили различные аспекты low-code и no-code решений, их влияние на рынок разработки программного обеспечения, а также затронули реальные примеры успешного применения таких платформ в сфере бизнеса и разработки.

«Low-Code и No-Code продукты - просто и доступно?»  

Эксперты до сих пор спорят, стали ли  Low-Code и No-Code решением для быстрой автоматизации процессов или, например, разработки каких-то программ или сайтов. Инструментов сегодня много, но кастомную разработку, да и вообще участие программистов на разных этапах в проектах они не отменили, хотя стремятся сделать это очень давно. 

Например, говоря  популярных и «простых» решениях Валерий Самарский, руководитель проектного офиса Comindware отмечает, что зачастую инструменты, которые декларируются, как low-code и no-code, на самом деле — много код. 

«Очень часто в low-code и no-code действительно приходится много писать кода, и программисты влияют на значительную часть процесса. Однако, в парадигме low-code и no-code мы в Comindware уже много лет успешно реализуем большие проекты, не только MVP. В таких проектах разработчик занимает всего около 5% общих трудозатрат, остальное выполняет аналитик с помощью мыши и инструментов платформы. И сейчас, Low-code решения используются в достаточно крупных и серьезных проектах, и не только для MVP», — отмечает он.

Но это не означает, что к проекту с применением инструментов  low-code и no-code можно приступать без подготовки. Валерий Самарский отмечает, что если использовать серьезные low-code инструменты, такие как Comindware, аналитик должен быть подготовлен: он должен понимать, как моделировать базу данных и бизнес-процессы. Только тогда он сможет построить полноценное встроенное бизнес-приложение с необходимой бизнес-логикой. 

«Если пользователь не подготовлен, ему придется долго учиться. Для людей, занимающихся простыми задачами, например, владельцев небольших магазинов, достаточно использовать простые инструменты, такие как Tilda. Однако для корпоративного уровня и предприятий потребуются более серьезные low-code инструменты, позволяющие не просто настроить уведомления, а грамотно выстроить бизнес-процесс. Такая система должна быть гибкой и быстро адаптироваться под изменения условий бизнеса. В этом случае возникает выбор между классической разработкой и использованием программных продуктов», — говорит эксперт. 

По его словам, с кастомной разработкой возникает необходимость написания и согласования тезисов с бизнес-пользователями, и часто то, что получается в результате, не соответствует ожиданиям пользователя. В этом случае начинается бесконечный цикл доработок и переделок. С low-code проблема другая: нужен подготовленный аналитик, но результат получается быстрее, и пользователь активнее участвует в процессе.

«У нас есть успешный опыт использования low-code инструментов. Через две недели после начала проекта мы уже можем показать пользователю интерфейс, и он может сказать, что ему нравится и что нужно изменить. Мы быстро можем вносить изменения, потому что это требует только изменения атрибутов формы или добавления условий. При выборе low-code инструментов нужно учитывать задачи, уровень пользователей и масштаб бизнеса, а также оценить, подойдет ли вам Tilda или более серьезный инструмент или платформа», — говорит руководитель проектного офиса Comindware.

«Low-Code и No-Code полностью самостоятелен?»

Иван Линдберг, СЕО ООО «Пена» рассказывает, что в его практике были кейсы которые исключают разработчика из процесса. 

«Можно ли в таком случае сказать, что no-code полностью самостоятелен? На некоторых уровнях абстракции — да: там, где всё просто и нужно собрать из блоков, и там, где хочется создать что-то более серьезное и визуально приятное. Возьмем кейс Tilda, популярного no-code продукта для создания сайтов. No-code стоит воспринимать как инструмент для быстрого и простого решения, хотя в нем есть элементы low-code. Чтобы сделать качественный сайт на Tilda, нужно использовать ZeroBlock — зону, где работает дизайнер, позволяет ему, как в Figma, создавать визуальные продукты. Однако, без программного кода мы не можем получить анимации, когда что-то красиво крутится и вертится на сайте. Базовые инструменты Tilda дают некоторые возможности, но для действительно хороших продуктов, которые не выглядят сделанными на Tilda, нужен программный код», — отмечает он.

«Мы приходим к другому no-code решению, популярному сегодня: GPT-подобным решениям, которые помогают дизайнеру создать анимацию. Дизайнер заходит в него, говорит что нужно красиво создать и разместить кнопку, и ChatGPT выдает готовый кусок кода, который дизайнер вставляет, и в итоге продукт на Tilda полностью готов без привлечения разработчика. Но если мы хотим действительно продуманный и сложный продукт с точки зрения механики, то здесь, вероятно, no-code уже не очень справляется», — говорит Иван Линдберг. 

В то же время Сергей Расторгуев, CEO Тенлаб отмечает, что нужно учитывать, иногда GPT фантазирует. Если отправить ему не только программистский запрос, но и обычный, он может предоставить неверную информацию. Он может даже «знать» о несуществующих сетях. Если задавать ему вопросы по программированию, иногда он будет писать чушь с серьезным выражением, будто это правильно.

«Для качественной разработки требуется архитектор. GPT можно интегрировать как дополнительный инструмент для no-code решения, возможно, для неглобальных задач на начальных этапах, но все равно должен быть специалист, который проверит, правильно ли выполнена работа. GPT расширяет функционал и возможности рынка, но не отбирает работу. Творческая часть все равно на человеке. Написать код — это одно, но его надо придумать, и это гораздо сложнее», — отмечает он.

Говоря о готовности low-code и no-code к продакшену, то да эти решения готовы, — говорит Александр Грищенков, CTO digital-агентства Molinos.

«Как мне кажется, в основном они используются для быстрой проверки гипотез — продуктовых или маркетинговых, чтобы сделать что-то быстро, посмотреть на результат и проверить недорого. Если продукт работает, удовлетворяет потребности пользователей, то стоит обратить внимание на множество нюансов серьезного продакшена, таких, как нагрузка, продуманность архитектуры, безопасность и обработка данных. Если продукт хочет развиваться, то нужно переходить на нормальные технические процессы (контроль версий, ревью кода, тестирование и подготовка релизов и так далее)», — говорит он.  

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

«Тут стоит учесть, что есть проверенные решения с известной архитектурой, такие как Tilda, с которыми многие знакомы и которые работают хорошо. Однако, при использовании новых low-code и no-code решений необходимо учесть кривую обучения, так как пользователю придется освоить новые инструменты для построения API и других функций. Значит, тебе нужно иметь базовые знания о том, как работают базы данных, сервера, окружения, и уметь составлять запросы. Затем, ты должен освоить новый уровень абстракции и понять, что означают разные элементы интерфейса в терминах обычного программирования. Когда ты это освоишь, техпроцесс будет построен, и аналитик сможет, используя эти элементы, собрать хороший работающий продукт. Однако, при выводе продукта в продакшен, могут возникнуть ограничения, связанные с платформой, такие как оплата за трафик, мощность процессора и другие нюансы, особенно при работе с большими нагрузками. Чтобы оптимизировать запросы к базе данных, нужно иметь определенные знания, которыми может не обладать, например, человек без опыта работы с low-code решениями», — отмечает Александр Грищенков.

«А сколько ваш продукт будет существовать на рынке?»

Среди опасений пользователей  low-code и no-code продуктами и платформами можно выделить главное — срок жизни и обновления этих инструментов. Если сегодня, например, автоматизировать бизнес с применением популярной платформы, то кто даст гарантию, что она будет «жить» и развиваться еще долгие года. 

«Рассмотрим ситуацию, когда заказчики хотят обновить систему документоборота, которая существует в компании с 90-х годов, и есть разработчик, который все знает про эту систему. Что будет, если этого разработчика не будет? Система, вероятнее всего, умрет, и ее  невозможно будет поддерживать, потому что только этот разработчик знает все нюансы. Однако, когда вы используете low-code инструмент, вся настройка видна аналитику, и любой аналитик сможет разобраться в настройке и внести изменения. В этом проблемы нет. Мы уже давно не стартап, а большая компания с крупными проектами. Конечно, есть геополитические риски и другие опасности, но как российская компания, мы разрабатываем и ведем проекты внутри страны, и пока геополитических рисков нет», — успокаивает Валерий Самарский, руководитель проектного офиса Comindware.

«На мой взгляд, клиент ничем не рискует с покупкой low-code и no-code решений, потому что даже если у него поменяется аналитик, другой аналитик придет, сядет, посмотрит, и платформа продолжит работать. Система настроена на базе платформы, и это решение предоставляется клиенту», — резюмирует эксперт. 

На самом деле существует риск, что компания-разработчик может уйти с рынка и отозвать лицензии, даже на коробочные продукты. Это подтверждает Михаил Меркурьев, руководитель проектов, владелец продукта Девелоника (ГК Софтлайн)

«Однако нужно учитывать, с каким бизнесом мы имеем дело. Если это крупная компания, которая может позволить себе собственную разработку или содержать собственную IT-компанию, то для них это актуально. Некоторые крупные корпорации создают свои собственные IT-компании для работы на благо своих подразделений. Однако средний и малый бизнес часто не способны потянуть разработку с нуля или не обладают компетенцией для организации эффективного процесса разработки. В этом случае им приходится мириться с использованием no-code решений, поскольку они обладают преимуществами в стоимости эксплуатации и скорости внедрения, что делает их более эффективными для бизнеса», — говорит он. 

«Самое главное — четко собрать все функциональные и нефункциональные требования» 

Если человек или бизнес стоит перед выбором между low-code или кастомной разработкой, то в при любом решении он должен продемонстрировать определенный уровень готовности. Это подтверждает Павел Ольнев, технический директор компании  SEBEKON.

«Самое главное — четко собрать все функциональные и нефункциональные требования, от которых будет зависеть выбор. Например, если у вас среди нефункциональных требований к web-разработке есть требование «время загрузки страницы не более одной секунды», то нужно определить, сможет ли low-code или no-code решение выполнить это требование. Если рассматривать no-code инструменты в веб-разработке, то это те инструменты, с помощью которых можно создать веб-приложение без написания кода. Вам нужно проверять и экспериментировать с разными инструментами, такими как Tilda, Wix или Bubble, Glide, Webflow,  чтобы понять, могут ли они гарантировать выполнение ваших требований», — отмечает эксперт.

По его словам, если речь идет о масштабировании приложения, то возникают вопросы о контейнеризации и создании кластеров. Если вы не сможете выполнить требования по нагрузке с помощью low-code или no-code решений, тогда нужна будет кастомная разработка.

«Возможно, стоит систематизировать и создать базу требований, по которым можно определить, когда нужен кастом, а когда можно обойтись существующими инструментами. Также нужно учитывать аспекты тестирования и определить требования QA-команды заказчика. Если для QA-команды необходим будет preprod-контур для тестирования, то не каждая no-code платформа предоставляет такую возможность ограничиваясь лишь боевым и техническим доменами. Допустим, мы говорим о препроде и внутренних проверках, где мы проводим тестирование. Возникает вопрос: как нам проверять и как выполнить это требование? Или, например, касательно версионности: поддерживает ли каждое no-code решение версионность? Ответ: нет, не каждое. Как одна часть команды может работать с одной версией проекта, а другая — с другой? Здесь мы и сталкиваемся с ограничениями определенных low-code решений. Однако low-code решения часто являются наиболее приемлемыми и могут быть полезными даже в кастомной разработке. Если мы рассматриваем low-code решение как "low-code as a service", то мы можем встроить его в нашу сервис-ориентированную или микросервисную архитектуру. Такой low-code сервис может настраиваться администратором и нормально функционировать в рамках кастомной разработки, сокращая количество часов на внедрение и интеграцию», — отмечает специалист.

«Большие корпоративные системы, позиционировавшиеся как low-code или no-code, ушли с рынка» 

Ситуация с уходом компаний и технологий с российского рынка не прошла бесследно. Об этом говорит Валерий Самарский, руководитель проектного офиса Comindware, отмечает, что многие заказчики столкнулись с большими проблемами.

«Большие корпоративные системы, позиционировавшиеся как low-code или no-code, ушли с рынка, и люди столкнулись с реальными проблемами. Мы знаем такие случаи, и одна из известных историй связана с компанией Ланит. Важно смотреть на бизнес и понимать, почему он предпочитал заграничные решения, не осознавая рисков. В дальнейшем необходимо анализировать рынок и определять, что подходит лучше: low-code решение или собственная разработка. Не каждая компания может позволить себе содержать штат разработчиков или нанимать дорогостоящих интеграторов для создания индивидуальных систем», — говорит он.

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

«В условиях меняющегося бизнеса и законодательства, компании стали больше считать деньги и обращать внимание на low-code решения. Большой штат разработки становится дорогим, и результаты требуются быстрее. Опыт одного из крупных заказчиков показал, что такой подход позволяет быстрее реагировать на изменения в бизнесе и поддерживать быстрые изменения» — резюмирует эксперт.

Но, по словам Сергея Расторгуева, CEO Тенлаб, опыт взаимодействия с крупными корпорациями показывает, что менеджеры и топ-менеджеры зачастую не понимают разницу между low-code и no-code, и они обычно рассматривают SAP как основное решение. Отсюда возникает сложность: уже реализовано много процессов на SAP, и стоит ли переделывать их на российском low-code.

«Все разговаривают о переходе на новую ERP-систему, и люди ищут, на какую лучше перейти. Однако более продвинутые и умные ребята начинают анализировать свои текущие системы и процессы. Некоторые компании уже имеют сложную инфраструктуру с установками SAP, множеством процессов и данными. Они рассматривают возможность разложить все это по разным инструментам для оптимизации, что может быть выгоднее для поддержки и развития. Некоторые компании заменяют одну ERP на другую, например, на российскую разработку. Лучший подход — это анализировать текущие системы и процессы, определить, что должно остаться в ERP, а что лучше перенести на другие инструменты. Это добавляет гибкости и позволяет бизнесу быстро меняться и адаптироваться к новым условиям», — отвечает Валерий Самарский, руководитель проектного офиса Comindware.

«Переход на новую ERP может быть сложным, и переделывать все, что уже существует в SAP, наверное, не стоит. Вместо этого, можно переложить часть функциональности в другую ERP. Некоторые вещи, например, согласование договоров, можно вынести из ERP и реализовать с помощью низкоуровневых кодовых инструментов (low-code). Таким образом, процесс согласования может быть легко изменен в зависимости от потребностей бизнеса. Например, сегодня юристам может потребоваться одно согласование, а в других условиях — другое. Вместо того чтобы программировать эти изменения в ERP, их можно быстро реализовать в low-code. Это позволяет бизнесу быть более гибким и быстро реагировать на изменения», — говорит он. 

«Low-code инструменты могут помочь людям» 

«Low-code инструменты могут помочь людям, принимающим решения, потому что после первой встречи и определения задачи можно быстро собрать демо-версию и показать ее через неделю. Заказчик увидит, как быстро вы справились с задачей, и скажет: «Давайте будем делать это вместе», — отмечает Самарский.

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

«Поэтому когда руководство бизнеса настаивает на использовании low-code, IT-специалистам придется подчиняться. Конечно, здесь также важна организационная структура и иерархия внутри компании, то есть разделение на бизнес-функции и IT-функции. Будет ли это департамент или отдельная IT-компания, но у них уже сложился алгоритм работы. И эта система сложно меняется. Некоторые компании осознают это и анализируют существующее положение, принимая решения в интересах бизнеса. Другие же продолжают работать по старым схемам. С использованием low-code можно быстро собрать интерфейс и показать его заказчику. Например, настроить 10% от их решения за неделю и спросить, двигаемся ли дальше», — уверен эксперт. 

Иван Линдберг, СЕО ООО «Пена», считает, что no-code и low-code инструменты перекраивают рынок, подобно тому, как это делали Tilda и Webflow десять лет назад. 

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

Сегодня low-code инструменты выполняют аналогичную роль на корпоративном уровне, помогая автоматизировать различные процессы. Корпорации используют подобные платформы для запуска микроинициатив, предпочитая не отвлекать разработчиков от более значимых задач. Такие инструменты позволяют аналитикам и менеджерам создавать ситуативные лендинги, освобождая разработчиков для работы над более важным функционалом, а не решением рутинных задач.

Использование low-code и no-code технологий позволяет разработчикам сконцентрироваться на значимой и интересной работе, минимизируя выполнение рутинных операций. "Если компании часто требуются лендинги для мероприятий, рациональнее использовать или приобрести конструктор, который менеджеры могут применять самостоятельно, без привлечения разработчиков," — подчеркивает Линдберг.

«Мы настоятельно не рекомендуем разработчикам использовать наше решение для настройки бизнес-задач»  

Развитие low-code и no-code иногда нацелено на то, чтобы профессиональные разработчики могли заниматься в компании более сложными задачами. 

Валерий Самарский, руководитель проектного офиса Comindware отмечает, что  Comindware Business Application Platform вовсе не предназначено для разработчиков. 

«Мы настоятельно не рекомендуем разработчикам использовать наше решение для настройки бизнес-задач, потому что это может привести к плохим результатам. Разработчик со своим подходом и мышлением начинает писать код, вместо использования инструментов и возможностей настройки мышью. В результате, схема процесса, где пользователи должны нажимать кнопки, состоит из технических задач с вложенными скриптами — это типичный подход разработчика. Конечно, low-code и no-code инструменты для разработчиков должны быть, но мы не знакомы с этим рынком. В нашем случае, мы фокусируемся на гражданских разработчиках. Например, сотрудник бизнес-подразделения, который знает свой процесс от начала до конца, ему нужно решить задачу. IT-специалисты говорят, что смогут написать приложение через два года, но он предлагает попробовать наше решение и начинает работать над ним сам, не привлекая IT-специалистов. После этого он обращается к IT-специалистам для размещения системы на их инфраструктуре. Они проверяют безопасность и выделяют сервера, но система уже рабочая и создана. Люди без IT-знаний и технических навыков успешно разрабатывают прототипы или маленькие решения, которые мы создали или настроили, и развивают их до масштабных систем», — говорит он.

Эксперт полагает, что кастомная разработка, вероятно, будет сосредоточена на доработке ERP-систем под требования бизнеса. Low-code системы продолжат развиваться, занимать свою долю рынка и вытеснять кастомную разработку. Бизнес будет рассматривать коробочные решения по документообороту или CRM, а также возможность настройки таких решений на low-code платформе, чтобы они точно соответствовали их потребностям, как костюм, сшитый на заказ. В ближайшее время бизнес будет оперировать такими категориями.

В заключение, стоит отметить, что low-code и no-code инструменты уже доказали свою эффективность и способность кардинально менять бизнес-процессы и процессы разработки ПО. Эти технологии представляют собой не просто новую волну инноваций, они уже стали частью нашего повседневного технологического ландшафта. Они помогают сократить время разработки, повысить эффективность работы команд и освободить разработчиков для работы над более сложными и творческими задачами.

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

А какое ваше мнение об использовании low-code и no-code технологий? Как они влияют на вашу работу или бизнес? Ждем ваших мыслей и опыта в комментариях ниже. Возможно, ваша история поможет другим получить более глубокое понимание этих технологий и их потенциала.