Low-code

Привет! Меня зовут Мирослав, я инженер-разработчик проекта по реализации BPM-решений для внутренней автоматизации КРОК.

Наш проект не гоняет миллионы строк каждую ночь через фильтры и правила, это не сложная система, которая отвечает за кадровую информацию, бюджетирование или сведение план-факта. Наш проект автоматизирует КРОК на самом понятном пользователю языке их у нас сейчас более 2 000 сотрудников. Если есть рутинная задача, которую можно представить в BPMN, мы ее реализуем.

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

Теперь пользователь просто прописывает путь к папке, выбирает тип доступа (чтение/редактирование), оставляет при желании какой-нибудь увлекательный комментарий и все, дальше все делает BPMN.

Таких антирутинных процессов у нас сейчас 27. Самые популярные заказ командировок, пропуска для гостя, обучения и авансового отчета. В этом посте я расскажу историю о том, как мы решили обновить свою BPM-систему и что из этого вышло поделюсь опытом, не обойду ошибки, и расскажу, как в итоге выстроили систему, которая полностью устраивает нас и наших заказчиков.

Каким мы хотели видеть BPMS

Потребность в новой BPM-системе стала очевидной еще в 2018 году. Текущая K2 4.7 не шла в ногу со временем, а K2 5.0 не устроила нашу команду. В конце 2018 года менеджер нашего проекта в компании пары аналитиков начали изучать рынок BPM-решений в поисках альтернативы.

Тогда как раз набирала обороты глобальная трансформация КРОК (что это значит, в одном абзаце не объяснить, поэтому просто оставлю это здесь как факт). Бизнес повсеместно стремился к изменениям, и это, конечно же, влияло на нас. То, как было по-старому, работать перестало нужны были гибкая разработка, регулярные демо, работа бок о бок с заказчиком на понятном ему языке.

Нашей идеальной системе предстояло усилить взаимодействие команды с заказчиками и ускорить процесс разработки. Для этого отлично подходили iBPMS, в которых, при нашем сценарии использования, ведущая роль разработки отводилась аналитику и автогенерируемому интерфейсу. Именно аналитик должен был проектировать BPM-схему, собирать модель данных и создавать страницы в UI-дизайнере. Разработчики, в свою очередь, должны были насытить BPM-схему логикой при помощи скриптов, а также развернуть окружение и наладить workflow внедрения новых бизнес-процессов.

Спустя пару месяцев наш выбор пал на Bonita, а в феврале 2019 года мне поручили ее внедрение на нашем проекте.

Опыт использования Bonita

На изучение и внедрение новой системы, а также разработку бизнес-процесса под неё ушло около пяти месяцев. Это был очень интересный опыт адаптации цельного и мощного инструмента к нашим потребностям. В течение этого времени наша команда несколько раз меняла восприятие продукта и парадигму работы с ним.

Как вы уже поняли из заголовка Bonita нас все-таки не устроила. Далее я подробно опишу архитектуру решения, чтобы наглядно показать, почему в итоге наша команда от него отказалась.

Bonita Studio

С чем столкнулись

• Моделлер рисования схем сам по себе показался не очень удобным, так как достаточно криво отрисовывал XML. Редактирование схем и приведение их к единому стилю иногда доставляло боль.

• Ограничение лицензии не позволяло нам открыть два окна Bonita Studio, а значит, два проекта одновременно, чтобы скопировать схемы или скрипты.

• Отдельным разочарованием стал UI Designer конструктор форм, на который мы изначально делали большую ставку. Мы надеялись, что это поможет сократить срок разработки UI и делегировать этот процесс аналитику.

  На деле UI-дизайнер оказался слишком негибким для того, чтобы отрисовывать на нем сложные формы. Аналитик мог "набросать" примерную схему страницы, но дальше на ее оживление разработчик тратил слишком много времени. И чем сложнее была страница, тем больше времени требовалось. А все дело было в том, что под капотом конструктора были примитивные и не расширяемые инструменты, а формируемые им страницы реализовывались на AngularJS.

  Дальше мы старались писать фронтенд по старинке, при помощи Angular 2+, и налаживать взаимодействие с Bonita через REST API.

Bonita Portal

С чем столкнулись

• Такое пространство удобное решение, если нет необходимости его дорабатывать. У Bonita есть возможность кастомизировать портал при помощи архивов стилей, накатываемых прямо в Web. Мы легко перекрасили оформление и даже поменяли язык всего портала на русский. Но когда дело дошло до каких-то детальных изменений, не предусмотренных BonitaSoft, мы столкнулись с проблемой для подобных доработок Bonita Portal не был приспособлен.

• В Bonita Portal можно редактировать скрипты и параметры бизнес-процессов в runtime. Это достаточно мощное решение, с которым можно здесь и сейчас устранить проблемы пользователей, но в перспективе эта опция создает огромные проблемы и хаос в Production среде. И естественно с этими перспективами мы столкнулись лицом к лицу. Но это уже совсем другая история :D.

Bonita Runtime

К этой части вопросов почти не было. Движок требует настройки, документация не идеальна, но сам по себе он работает хорошо и REST API у него описан достаточно подробно.

Version Control

Это опция Bonita Studio, которая обеспечивает взаимодействие с Git-репозиториями. Не очень красивая, и на самом деле, совершенно необязательная, так как можно воспользоваться каким угодно иным инструментом для работы с Git. Но работает исправно :)

Bonita Storage

С чем столкнулись

• На деле обязанность по построению модели данных легла на плечи разработчиков, так как именно они писали скрипты для наполнения бизнес-процесса логикой и именно они знали, какие сущности им в этом будут необходимы. Здесь снова не совпали наши "ожидание - реальность", и мы еще сильнее отдалились от "идеальной" системы, в которой большую часть приложения создавали аналитики, оставаясь в тесной связке с бизнесом.

• После создания модель данных содержалась в xml-файле, который необходимо было заархивировать и развернуть в Bonita Portal.

И вот здесь нам снова аукнулись нюансы открывать одновременно два проекта нельзя. В итоге, xml затирала модели данных других бизнес-процессов. Решение оказалось костыльным - мы хранили в репозитории "главный" xml-файл модели данных, который вручную изменяли при появлении новых сущностей.

• После деплоя архива с xml-схемой в BonitaPortal на ее основе создавались таблицы в заранее указанной базе данных. Выглядели они не совсем так, как нам хотелось. При этом в самой Bonita были ограничения по именованию объектов BDM. Все таблицы лежали в одной БД, хранить их иначе было невозможно. Для того, чтобы исключить пересечения именований, мы добавили префиксы, но в названиях таблиц (сущностей в модели данных) нельзя было использовать точки или нижние подчеркивания. В результате это были просто буквы, с которых начинались все названия сущностей.

  Еще были сложности с изменением модели данных. Добавление нового столбца или изменение Nullable могло обернуться вынужденным сносом всех данных из таблицы этого в проде мы допустить не могли.

Information systems

С чем столкнулись

• Основная проблема этого механизма - в его предопределенности. Здесь ситуация очень сильно похожа на Bonita Portal. В рамках задач, обозначенных BonitaSoft, коннекторы справлялись хорошо, но расширить их настройки или спектр применения было попросту невозможно. Да, мы могли создать самописные коннекторы, но тогда какой же это low-code? В итоге некоторые взаимодействия с внешними системами происходили через проставку из самописного сервиса.

Выводы

Bonita отлично подошла нам для создания простых бизнес-процессов: в некоторых случаях нам пригодился UI-дизайнер и даже генерация несложной модели данных. Но при создании нетривиальных, многомерных BPM-приложений такой подход начинал пробуксовывать, порождать костыли, а само приложение становилось неподъемным в плане поддержки и развития.

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

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

Поиск новой BPMS

В этот раз в выборе BPM системы участвовала большая часть проектной команды все те, кто был причастен к разработке процессов на Bonita. Пропустив через этот опыт решения из прошлого исследования, выбрали четырех финалистов Bizagi, ELMA, BpmOnline и Camunda.

Bizagi не устроила нас по цене, ELMA показалась слишком похожей на Bonita. BpmOnline мы смогли изучить подробнее, благодаря опыту наших коллег она уже используется в КРОК в качестве внутренней CRM-системы. В нашем случае она казалась не самым удачным вариантом могли быть трудности с поддержкой нетривиальных схем. У Camunda не было богатого набора инструментов iBPMS как у Bonita (но именно к ним у нас и было больше всего вопросов). Но зато у нее была Community-версия что стало дополнительным аргументом "за". Нам хотелось быстро и безболезненно протестировать решение, и быстро отмести его, если вдруг что-то опять пойдет не так. В общем-то, по этой причине мы выбрали ее качестве объекта для исследования и внедрения в тестовой среде.

Новая BPMS

Camunda - BPM Engine

Рассказывать о том, что такое Camunda можно долго, но на самом деле об этом уже написано достаточно статей. Вот, например, отличный материал от Tinkoff, позволяющий быстро и легко погрузиться в особенности этого BPM движка.

Добавлю лишь немного лайфхаков.

• Ссылка на git-репозиторий с огромным количеством тестовых проектов Camunda на любой вкус, которые помогут быстрому старту и поиску решений проблем, возникших при самостоятельном знакомстве.

• Ссылка на telegram-канал русскоязычного сообщества Camunda, куда можно обратиться за помощью, когда документация и Google не смогли подсказать решение. Эти ребята ни раз меня выручали в период знакомства с движком, за что им огромное спасибо :)

Наша основная проблема

Начав исследовать Camunda я столкнулся с очевидной проблемой. Camunda написана на Java, разворачивается в среде Java и расширяется при помощи Java-подобных языков. А вся наша команда пишет на .NET (надеюсь, у вас тоже проигралась заставка из Ералаша).

Вероятных решений было два:

• Научиться писать на Java или Kotlin, но не растерять при этом навыков .NET, так как на поддержке у команды остается еще более двадцати бизнес-процессов

• Интегрировать Camunda в нашу экосистему таким образом, чтобы рассинхрон стека как можно слабее повлиял на получаемый результат

Мы решили попробовать пойти по второму сценарию и вот что из этого получилось.

Новая концепция взаимодействия с BPM

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

Spring Boot

Java-часть нашей BPMS выглядит так:

Здесь мы используем Spring Boot, в который как зависимость импортируем Camunda.

У Camunda есть свой REST API и, конечно, BPMN-составляющая, а также своя БД, используемая для хранения процессных данных.BPM-движок через схему обращается к коду, написанному на Kotlin, который, в свою очередь, обращается к нашему .NET приложению для получения бизнес-данных.

.NET

Основная часть бизнес-процесса представляет из себя .NET приложение:

Бизнес-данные хранятся в БД, с помощью EF Core мы потребляем их в слой сервисов, где рассчитываем бизнес-логику и откуда обращаемся к Camunda REST API. Также у приложения есть формы на Angular для взаимодействия с пользователями и REST API для доступа к бизнес данным из Camunda и внешних систем.

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

Как теперь все устроено

За 8 месяцев мы исследовали и внедрили движок Camunda, а также мигрировали на него все бизнес-процессы, тем самым полностью отказавшись от Bonita BPM. Теперь у нас есть 3 отдельных Spring Boot приложения Camunda, под каждый бизнес-контур (Sales, HR и Production), самописный CROC BPM Portal, агрегирующий информацию о состоянии экземпляров процессов, и 4 бизнес-процесса, работающих в production-среде вот таких:

Выдача прав доступа

С него начался этот пост. Это инструмент, позволяющий автоматизировано получать права и доступ на файлы и папки КРОК.

Обходной лист

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

Согласование тендера

Мы упростили коммуникацию по согласованию участия в тендере и исключили из этого процесса электронную почту или мессенджеры. Теперь наши менеджеры используют автоматизированное приложение с продуманным WorkFlow.

Пульс проекта

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

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

Bonita Portal => CROC BPM Portal

Интерфейс, который отвечает за отображение скоупа задач и экземпляров процессов CROC BPM Portal теперь тоже самописный.Благодаря этому мы можем оперативно отвечать на требования пользователей и гибко его развивать.

Bonita Runtime => Spring Boot и Camunda

Также, вместо standalone-подхода мы используем импорт библиотеки Camunda в Java-приложение. И таких приложений у нас несколько, в целях увеличения отказоустойчивости, каждое под свой бизнес-контур.

Bonita Storage => EF Core

Еще мы полностью контролируем бизнес-данные, для обновления БД используем миграции, а таблицы хранятся в удобном для нас виде:

Information systems => Самописные сервисы

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

Почему BPM это круто?

После прочтения этой статьи у вас может сложиться впечатление, будто мы отказались от всех преимуществ BPMS и переложили ответственность на самописный код. Но это не так.

Центр любой BPMS это BPM-движок, и мы используем его по полной. Это удивительный инструмент, который действительно помогает ускорить разработку и повысить качество поставляемых решений. Фокус вовсе не в том, чтобы переложить ответственность на аналитика и автогенерацию. Основное преимущество в том, что BPMN это исполняемая документация.

Аналитик согласовывает с заказчиком схему бизнес-процесса, передает её разработчику, и тот дальше вносит в нее технические изменения. Схема при этом всегда остаётся "живой" и может меняться в одном ритме с кодом. Такое поведение системы делает работу проектной команды целостнее и слаженнее, а связи с заказчиками прочнее. Это именно то, чего мы добивались, начиная описанную мной историю.

Что дальше?

Наша BPM продолжает развиваться, и многое еще предстоит усовершенствовать. В ближайших планах написать собственную админку с возможностью просмотра истории экземпляров процесса, а также сервис, уведомляющий проектную команду об инцидентах Camunda.

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

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

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

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

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

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

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

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

Схема данных рисуется в визуальном редакторе и пока не требует кода. Вот она: связанные и подчиненные объекты располагаются правее своего родителя.

Проводка означает отражение сумм документов на сальдо договора и остатках на складах. В результате проводки мы снимем пометку Черновик с документа и изменим сальдо по договору на сумму движения. Если на эту дату записи Сальдо нет, то мы создадим её. Также мы пересчитаем остатки товаров на складе. Если записи по остаткам на этот день нет, то мы её создадим.

Данные, введенные в систему согласно этой структуре, выглядят примерно таким образом:

Это шапки наших документов со ссылками на связанные объекты, а ещё у них есть табличная часть, где перечислены товары. Количество это подчиненный массив записей, в который можно провалиться и увидеть список, например, такой:

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

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

Чтобы провести документ, нам надо выбрать все данные для расчета, произвести вычисления и записать результаты в эту базу данных. Мы используем механизм запросов. Запросом мы выбираем нужные значения, пишем расчетные формулы и указываем, куда записать результат.

Вот так выглядит и работает конструктор запросов, в котором мы выбираем нужные нам данные:

Мы видим всё, что есть в схеме данных, и можем добавить нужные колонки в наш запрос. Как только мы добавили или изменили колонку в запросе, он перестраивается с учетом этих изменений, и мы можем сразу видеть результат выборку данных.

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

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

Если добавить в запрос атрибуты связанных сущностей, то конструктор запросов сам свяжет нужные таблицы и выведет результат.

В следующем случае запрос объединит таблицы шапки документа, справочника договоров, регистров сальдо с фильтром на дату документа:

Будь мы программистами SQL, мы бы написали операторы JOIN ON и WHERE, написав соответствующие условия на объединение таблиц и отбор только тех Сальдо, которые относятся к дате документа. Здесь же мы задали имя формулы в нашей колонке Движение, а затем использовали это имя в фильтре по дате, взяв в квадратные скобки. Конструктор сам извлёк и объединил нужные нам данные, мы только наложили дополнительное условие по дате сальдо.

Мы не учим SQL, чтобы сконфигурировать всё это, но нам пришлось изучить некоторые правила работы с функциями и использование квадратных скобок, чтобы конструктор однозначно понял, чего мы хотим.

Вот тот же запрос, но не в конструкторе, а в навигаторе данных с большими запросами так работать легче:

Мы выбрали значения, нужные для проведения нашего документа, но нам нужно сделать изменения в базе данных.

Вычисленные значения можно присвоить вместо имеющихся в базе данных, записав их в поле SET Присвоить:

Мы задаем нужное нам выражение в поле SET колонки Сальдо, а конструктор запишет его результат вместо существующего значения сальдо.

Если требуется, мы можем посмотреть, какие изменения будут внесены в базу, прежде чем подтвердим их. Содержание будущих изменений выделено красным:

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

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

Получившийся запрос Сальдо вставим в выражение в поле SET, чтобы получить корректное значение сальдо, даже если записи о предыдущем сальдо нет:

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

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

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

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

• ROUND(x, 2) округление x до двух знаков после запятой (аналог в экселе ОКРУГЛ())

• IF(A, B, C) если условие A верно, то вернуть B, иначе C (аналог ЕСЛИ())

• x IS NULL Истина, если x пустое или неизвестно (аналог ЕПУСТО())

• SUM(x) просуммировать все x с группировкой по остальным полям (аналог СУММА())

• abn_ID возвращает внутренний ID объекта, нужна для однозначного его определения

Этот запрос делает всё то, что мы собирались сделать в начале этой заметки инвертирует пометку Черновик у документа, пересчитывает сальдо договора, остатки товаров на складе и их средневзвешенную себестоимость. То есть, он проводит документы, но также умеет откатить проводку и вернуть все остатки, себестоимости и сальдо, как было!

Он использует результаты трёх вложенных запросов собирает данные по остаткам, себестоимости и сальдо. Они просты и однотипны:

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

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

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

Если вам нужна только серверная часть, то в большинстве случаев вам и вовсе не придется ничего писать на языке программирования.

Применимость low-code: случаи, когда уникальная интеграция и визуализация занимают 90% усилий проекта и длятся, условно, 4 дня на проекте в 1 неделю. Часто базу данных и бэкенд можно накликать за 1 день, вместо 1-2 недель в традиционной разработке.

Пример, рассмотренный в статье, был сделан по ТЗ для простого приложения в 1С. В конструкторе с чистого листа были реализованы бизнес-сущности и формы ввода документов, которые уже есть в 1С. Для сравнения приведу некоторые факты (сравнение весьма субъективное, ибо 1С крут в своём сегменте, а тут нам нужно быстро собрать MVP):

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

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

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

Ещё, говоря о серьезном продукте, следует вспомнить про релизы, версионность, масштабируемость, авто-тесты, CI/CD и прочие сопутствующие вещи. Здесь всё достаточно просто конструктор, так же как и любая система, может быть покрыт стандартными процедурами. Можно выгрузить его состояние в гит, сравнить версии, оформить релиз и процедуру отката, но это тема отдельной статьи.

Все мы в последнее время довольно много слышим о платформах low-code/no-code. Платформы без кода обещают сделать разработку программного обеспечения столь же простой, как использование Wordа или PowerPointа, чтобы обычный бизнес-пользователь смог продвигать проекты без дополнительных затрат (денег и времени) на команду инженеров. В отличие от платформ без кода, low-code по-прежнему требует определенных навыков программирования, однако обещает ускорить разработку программного обеспечения, позволяя разработчикам работать с предварительно написанными компонентами кода.

Согласно Gartner, к 2024 году 65% разработанных приложений будут относиться low-code.

Еще в 2017 году я участвовал в раннем сравнительном тестировании производительности традиционной разработки (с использованием Java) и проектом low-code/no-code, основанном на моделях. Результаты были впечатляющими: при использовании метода low-code/no-code производительность увеличивалась в 5-7 раз. Опрос, проведенный компанией No-Code Census в 2020 году, показал прирост производительности в 4,6 раза по сравнению с традиционным программированием.

Low-code/no-code: Фрагментация платформы

Область low-code/no-code довольна сложна и включает в себя многочисленные решения, платформы и субрынки. Например, существуют субрынки, ориентированные на крупные, средние и малые предприятия. Корпоративные платформы low-code/no-code обеспечивают высокую масштабируемость, производительность, безопасность и интеграцию с приложениями предприятия. Они, как правило, дороже остальных. Ниже представлен Магический Квадрант Gartner для корпоративных low-code платформ:

Gartner дает платформе low-code (LCAP) следующее определение: Это платформа, которая поддерживает быструю разработку приложений, одноэтапную раскатку, выполнение и управление с использованием декларативных абстракций программирования высокого уровня, таких как языки программирования на основе моделей и метаданных.

G2 предлагает аналогичный обзор для малого бизнеса. Рынок платформ для малого бизнеса и для корпораций не особо пересекается. Некоторые поставщики платформ для малого бизнеса не столь известны и популярны в больших корпорациях. Аналогично малые и средние предприятия обычно не склонны покупать корпоративные платформы, в первую очередь из-за их цены и сложности.

Неудивительно, что многие платформы low-code являются платформами управления бизнес-процессами. BPM уже давно поддерживает разработку на основе моделей (Model-driven Development), где нужно нарисовать диаграммы, объясняющие, как должно работать программное обеспечение, прежде чем его создавать. Эта схема похожа на процессный подход BPM, при котором для задания бизнес-процесса необходимо в правильном порядке расположить блоки, представляющие собой подпроцессы. (Самым популярным стандартом отображения процессов, поддерживаемым большинством BPM-платформ, является BPMN). Поэтому процессно-ориентированные решения достаточно популярны. Примерами low-code/no-code платформ для BPM являются Appian, Pega, Outsystems.

Но существуют и другие примеры под эгидой low-code/no-code:

Веб-платформы для использования предприятиями любого размера. Ведущими конкурентами являются WordPress, Wix, Squarespace и WebFlow.

Платформы управления базами данных, начиная от таких, как Mendix, и заканчивая такими, как Airtable. Существуют также low-code/no-code платформы баз данных NoSQL, например, KgBase, предназначенная для построения графов знаний.

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

Разработка мобильных приложений. Большинство платформ low-code/no-code, таких как Bubble, предоставляют возможности адаптивного пользовательского интерфейса, другие предлагают встроенную поддержку ведущих мобильных OC (iOS и Android). Thunkable пожалуй, лучший пример low-code/no-code платформы для разработки мобильных приложений.

Многие из этих платформ предоставляют огромные коллекции подключаемых модулей и шаблонов для определенных типов приложений.

Другие категории платформ нацелены на определенные области или ниши приложений:

• E-commerce и онлайн-магазины: лидирующим примером здесь является Shopify.

• Управление рабочим процессом: отличный пример Monday.com.

• Приложения ERP (планирование ресурсов предприятия): в качестве интересного примера (также указанного в MQ Gartner) можно привести Zoho. Еще одна важная и впечатляющая платформа для ERP и CRM это Salesforce.

• Блокчейн и Интернет вещей: Atra.

• Искусственный интеллект: сейчас мы начинаем наблюдать появление таких инструментов, как C3 AI Ex Machina.

Челленджи low-code/no-code

Платформы low-code/no-code имеют множество преимуществ, но в то же времясоздают определенные трудности и требуют обучения для работы с ними. Многие передовые практики только появляются и относительно незрелы, и следовательно, растет ответственность при их использовании. Что касается традиционного программирования, здесь накоплен огромный опыт, существуют сильные сообщества, а передовые практики задокументированы. Во многих отношениях low code/no-code находится в зачаточном состоянии даже несмотря на то, что разработка на основе моделей существует уже давно (особенно платформы BPM).

Вот некоторые из наиболее серьезных проблем:

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

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

3. Необходимость использования нескольких платформ: одни платформы имеют более полную функциональность, другие нет. Unqork и Bubble, например, предназначены для любого сценария использования и поэтому предлагают множество вариантов интеграции с корпоративными системами. Кроме того, они могут взять много полезного из других компонентов, специализирующихся в определенных областях; например, Bubble вместе, скажем, с Parabola или плагином Zapier можно использовать для автоматической интеграции. С возможностями управления данными и интеграциями в Parabola или Zapier работать легче, чем с нативными от Bubble. Существуют и другие плагины или технологические компоненты, дополняющие платформы low-code/no-code: посмотрите, например, список технологических партнеров Unqork или полный список плагинов для Bubble.

4. Недостаточность ресурсов и поддержки сообщества: в мире существуют миллионы, или даже десятки миллионов разработчиков обычных языков программирования, множество онлайн-курсов, а также книги и материалы, доступные для таких языков, как Java или C#, есть множество сообществ и ресурсов для аутсорсинга. Совсем иначе дела обстоят для low-code/no-code, особенно для более новых платформ.

5. Сбивающее с толку ценообразование: корпоративные low-code/no-code платформы, как правило, неоправданно дороги. Платформы для среднего и малого рынка менее затратны, но, как правило, менее масштабируемы. А использование нескольких платформ для создания комплексного решения еще больше усложняет вопросы ценообразования.

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

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

Готовы ли вы к переходу на low-code/no-code?

Примечание переводчика: наша компания предоставляет как low-code/no-code омниканальный облачный контакт-центр Voximplant Kit с широкими возможностями автоматизации обслуживания клиентов, так и serverless-платформу Voximplant для традиционной разработки с набором API для создания голосовых, видео- и текстовых коммуникаций.

В прошлой статье о low-code в enterprise-решениях я обращался к бизнесу. Однако на Хабре бльшая часть пользователей инженеры (Кэп!), и в комментариях к статье я увидел резонное количество типичных возражений по LCDP (low-code development platforms). И пока те, кто не знает про Эффект Даннинга Крююгера, уже ищут кнопку dislike, давайте разберем наиболее частые заблуждения и мысли.

В этой статье я хочу разобрать наиболее частые заблуждения.

1. Low-code это использование готовых продуктов.

2. Под low-code понимают развитые code-first платформы. Кто-то из коллег приводил в пример даже WordPress.

3. В low-code отсутствует нормальный DevOps (code review, versioning, deploy, etc.), нормальное переиспользование кода и прочие абстракции.

4. Разработчикам лучше писать код с готовой ценностью, а не разрабатывать конструкторы.

5. Low-code можно не понимать, это какой-то артефакт. Мы продолжим кодить как обычно. Впрочем, некоторые разработчики и про DevOps до сих пор не всё понимают и думают, что это должность. Так что с low-code ситуация не уникальна.

Кратко о состоянии отрасли

Потребность в разработке растёт. Дефицит специалистов в отрасли сейчас легко отследить на примере роста окладов: он опережает рост производительности труда в IT-сфере.

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

Расходы на разработку увеличиваются, и одновременно возникает конфликт интересов: бизнесу нужно меняться быстрее, а разработчики хотят интересных задач. Но бльшая часть изменений у бизнеса неинтересная.

На подобные вызовы IT-отрасль всегда отвечала повышением уровня абстракции и упрощением разработки. Эпоху ассемблера сменила эпоха C++, затем наступила эпоха высокоуровневых языков с полным отсутствием управления памятью и ресурсами и далее количество фреймворков и библиотек только увеличивалось.

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

Low-code это не философия?

В Рунете каждая статья о low-code заканчивается комментариями о несовершенстве конкретного продукта (продуктов). Отдельно о продуктах поговорим чуть ниже, а для начала предлагаю подумать о концепции low-code в целом.

Философия code-first

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

При этом у разработчиков неизбежно возникают два желания.

1. Как бы нам писать только интересный код, а скучные операционные задачи передать кому-нибудь другому? К нам пусть обращаются лишь в редких кейсах, количество которых в идеале должно уменьшаться и дальше.

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

В code-first реализовать эти желания не получается.

Философия low-code

Представьте, что вы поставляете клиенту не непосредственно конечную ценность, а конструктор для реализации этой ценности. Нет, конечно, первичный функционал в вашем конструкторе придётся реализовать вам для целей отладки. Но при этом вы сможете создавать такие вызовы, функции и компоненты, которые...

• Являются самодокументируемыми в подавляющем большинстве случаев.

• В каждом компоненте есть настройки, которые делают его переиспользуемым.

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

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

• Если требуется какая-то очень эксклюзивная логика (один из компонентов отсутствует) и эта логика явно не будет переиспользуемой, вы сможете вставить нужный компонент, написав небольшой кусочек кода. В отличие от code-first систем, здесь не нужно писать весь модуль или микросервис вы вставите код в нужный фрагмент без сервисной обвязки (сахара). Часто такой код легко читается не только разработчиком, но и опытным менеджером или бизнес-аналитиком и состоит из 220 строк.

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

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

Это справедливо и при использовании готовых LCDP, и при разработке в парадигме low-code.

Low-code путают с развитыми code-first платформами

В дискуссиях я раз за разом сталкиваюсь с тем, что под low-code понимаются просто очень гибкие системы. Например, Битрикс потому что в нём же есть бизнес-процессы и моделирование таблиц или WordPress.

LCDP это такая платформа, в которой всё сделано на базе конструктора, ведь если это не так, рано или поздно поддержание такой платформы перейдёт в code-first.

Я бы обозначил следующие критерии LCDP.

1. Ядро системы содержит только элементы конструктора и всё, что к нему относится, т. е. вам не придётся применять code-first подход для реализации того, для чего предназначена LCDP.

2. В графическом редакторе можно вставить код там, где он нужен. А в некоторых платформах можно и слегка переопределить код текущего компонента.

Приведу излюбленные нами примеры.

• ETL / ESB Talend low-code механизмы для построения интеграций.

• Mendix, Pega, Appian, OutSystems, Caspio как платформы для создания приложений разного класса.

• Reify, Builder.io, Bildr для фронта.

• Из новичков 2021 года Corteza (полностью open-source, Go + Vue.js), Amazon Honeycode.

• Для игроманов давно ли вы смотрели на Unity и продукты на его основе? Видели ли Construct?

• Российские ELMA BPM, Creatio (разработка Террасофт) и Comindware, универсальная CUBA Platform, Jmix.

• Продукты особо крупных вендоров Microsoft Power Apps, Oracle APEX, Salesforce Platform, IBM BAS, SAP BTP.

• Частично open-source Builder.io (фронт), Bonita, Joget.

Есть и пограничные случаи. Например, Pimcore, которая в части фронта, workflow, моделирования инфомоделей с калькулируемыми полями является по своей сути low-code (с некоторыми оговорками, но это не тема данной статьи). Если же пытаться делать что-то за рамками этого, вы свалитесь в традиционное поддержание монолита.

Или тот же Битрикс. В нём удобно моделировать данные и строить бизнес-процессы, в которые при желании упаковывается PHP-код в low-code стиле (т. е. без длинных инициализаций). Однако огромный объём коробочного функционала, созданного не в LCDP-стиле, и отсутствие развитых инструментов low-code в других частях приводят к традиционному code-first.

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

• это была не LCDP;

• это была действительно плохая LCDP (такого сколько угодно);

• команда пыталась писать в LCDP больше кода, чем нужно. Вместо переиспользуемости один кастомный компонент, куда вставляется огромная портянка кода, мы встречали такое!

Low-code не содержит традиционных средств контроля, привычных разработчику (code review, deploy)

Это миф. Вы найдёте эти компоненты в подавляющем большинстве платформ. Многие (Mendix, Pega) имеют собственные CI с элементами low-code.

Хотя, безусловно, проводить ревью не всегда просто. Если с кодом компонентов всё понятно там всё так же, как и в традиционном code-first, то по поводу того, что можно сделать в конструкторе

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

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

Разработчикам лучше писать код с готовой ценностью, а не разрабатывать конструкторы

Разработчики обычно брезгливо относятся к самой идее того, что могут что-то накликать мышкой. Между тем подавляющее большинство задач разработчика не rocket science, а рутина. Та самая, которой заниматься неинтересно и от которой хочется побыстрее избавиться.

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

Как ситуация поменяется в рамках LCDP? Скучные задачи никуда не денутся и будут возникать с той же частотой, но, вместо того чтобы тратить на них уйму часов, вы сможете закрывать их в разы быстрее или вообще передавать не разработчику. Зачем писать ещё одну интеграцию между системами, когда вы быстрее сделаете её через ETL-решения? Зачем забивать спринт созданием нового экрана, если это может накликать дизайнер?

Чем быстрее вы закрываете скучные задачи, тем больше времени у вас освобождается на более интересные. Более того, вы статистически чаще будете получать интересные задачи, потому что перерыв на рутину сократится в разы.

А что с реально талантливыми разработчиками, теми, кто любую самую сложную задачу делает изящно и быстро?

Сдав задачу в виде кода и получив через полгода change request, они сталкиваются со следующим:

• надо вспомнить, как тут что написано;

• надо бы отрефакторить код быстро устаревает.

Но очень редкая команда подписывается под рефакторинг. И редкий бизнес-пользователь поймёт, почему минорную правку ему оценили в несколько дней.

Что в итоге? Мы хотели писать интересный код, но через какое-то время ничего интересного не пишем. Нам остаются операционка и угрызения совести за то, что тут всё уже не очень красиво.

Если же вы мыслите в плоскости LCDP, дело не ограничивается только более быстрым решением рутинных задач. Рефакторинг происходит не на уровне конечных ценностей, а на более высоком уровне абстракции на уровне реализации компонента конструктора. Как следствие, вам приходится больше думать и больше проектировать. Меньше областей остаются без вашего надзора, сделать плохо поддерживаемую задачу в LCDP намного сложнее ввиду того, что как минимум плохой нейминг или плохую логику могут обнаружить даже не разработчики. Сам подход заставляет вас больше мыслить абстракциями.

Лирическое отступление. Многие тимлиды конкретно для себя решают эту задачу так: реализацией занимаются другие члены команды, а они думают. Ни к чему хорошему это не приводит. Такие тимлиды часто начинают скучать по коду, а команда в целом становится более хрупкой. Антихрупкость таких людей обеспечивается за счёт хрупкости других членов команды, которые выступают в качестве машинисток. Этому пороку могут быть подвержены и традиционные, и low-code разработчики.

Low-code можно не понимать, это какой-то артефакт. Лучше продолжим кодить как обычно

Можно не думать о будущем разработки, если допустить, что:

• количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки (с учётом повышающейся производительности труда);

• бизнес сможет оплачивать растущие аппетиты разработки и не разорится при этом (т. е. ROI в IT всегда будет положительным);

• другие типы инвестиций не будут конкурировать с инвестициями в IT.

Давайте проведём мысленный эксперимент и прикинем, насколько всё это вероятно в реальной жизни.

Количество задач для разработчиков будет расти не медленнее, чем количество самих разработчиков и субститутов разработки

Сейчас дефицит разработчиков в мире около 10%. Я не могу предсказать будущее, но могу представить, какие условия нужны, чтобы этот дефицит оставался всегда.

Первое: производительность разработчиков не должна повышаться настолько, чтобы она могла компенсировать разницу в дефиците (т. е. на 10% относительно нынешней производительности).

Второе: количество разработчиков не должно расти быстрее, чем количество задач. Дополнительное условие количество субститутов разработки не должно снижать этот дефицит.

А это противоречит фундаментальному закону спроса и предложения, ведь спрос всегда балансируется предложением до равновесного значения.

Что мы видим сейчас?

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

• В отчётах инвестиционных банков рынок no-code решений (которые являются прямыми субститутами разработки) уже сейчас выглядит примерно так. И если вы посмотрите на этот список, то увидите, что количество продуктов растёт. Наберите в поисковике название любой компании low-code/no-code и вы поймёте, что почти все от российского Сбера до американской Apple думают о том, как существенно повысить производительность труда в разработке.

• В конце концов, дисбаланс на рынке труда легко прослеживается на соотношении стоимости управленцев (на которых лежит бльшая ответственность и на которых завязаны мультипликаторы) и мидлов (на которых ответственности существенно меньше). Разрыв по доходам в 34 раза, и это не случайность.

При 20 миллионах разработчиков в мире одна только Индия поставляет на рынок по миллиону разработчиков ежегодно (с ежегодным увеличением этого количества), т. е. существует некоторая вероятность, что в будущем дефицит разработчиков может не сохраниться. Есть и более радикальные суждения: у Германа Грефа, например, или у футуролога Герда Леонгарда.

Бизнес сможет оплачивать растущие аппетиты разработки и не разорится при этом

Чем дороже разработка, тем больше разрыв между технологическими компаниями и всеми остальными. Те, остальные, вынуждены встраиваться в экосистемы гигантов. А экосистемы гигантов имеют очень высокую производительность труда (в силу объёмов). Это само по себе заставляет компании уходить в чужие экосистемы.

Было время, когда затраты на IT были несущественными. Но программное обеспечение становится всё более сложным и разнообразным, и стоимость ИТ-инфраструктуры является значимым фактором для стартапов и одной из основных статей бюджета. Чем дороже IT, тем больше субститутов для инвестиций.

Другие типы инвестиций не будут конкурировать с инвестициями в IT

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

Не станет ли на каком-то этапе стоимость IT столь значимой, что будет автоматически отсекать большую часть новых ныне рентабельных проектов?

В заключение

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

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

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

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

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

Это подтверждает исследование Coralogix разработчик в среднем на1000строк кода допускает 70 ошибок. Для исправления ошибок требуется минимум в 30 раз больше времени, чем на кодинг.

Как было раньше

Заместитель начальника управления разработки и архитектуры компанииОТРАлексей Кузнецов рассказывает, чтов процессе разработки сложных информационных систем обязательными участниками являются бизнес-аналитики. Они готовят задание с указанием того, как должен работать будущий проект. Но есть трудность для запуска заданий в разработку они пишутся на языке бизнеса.

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

В этом процессе мы увидели сразу же несколько возможностей для оптимизации. Во-первых, системных аналитиков можно заменить на скрипты, которые автоматически будут раскладывать бизнес-требования в готовую инструкцию. Во-вторых, ряд процессов при разработке повторяются из проекта в проект. Можно сократить штат высокоуровневых разработчиков, если запрограммировать среду разработки самостоятельно вставлять куски кода в нужные места. Реализовывать задумку решили на Java.

Первые шаги со Студия 1.0

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

Чтобы визуально представить low-code систему, можно вспомнить среду для быстрой разработки Delphi 7. С ней многие читатели могли познакомиться ещё в школе или вузе. Для создания элемента достаточно было перетащить его на поле рабочий области. Он тут же прописывался в теле программы и оставалось лишь закодировать логику.

В Студии 1.0 принцип был схож с Delphi 7, но только описывать логику уже было не нужно. Из имеющейся базы подтягивался написанный метод, который ранее использовался на проектах. Важно отметить, что мы не собирались полностью отказываться от труда программистов. Если технолог не находил нужный код, то программист, обслуживающий проект, дописывал недостающие куски самостоятельно. С каждой итерацией инструмент становилсямощнее.

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

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

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

Автоматизируем разработку со Студия 2.0

В первой версии Студии мы не смогли уйти от необходимости передавать задание от бизнес-аналитиков к системным аналитикам. Но уже сейчас разрабатывается интерпретатор требований, который парсит техническое задание от бизнес-аналитиков и адаптирует его для разработчиков. Модуль умеет работать с популярными форматами файлов от офисных пакетов. Бизнес-аналитикам не придётся менять привычные инструменты.

Как это работает? Интерпретатор получает на входе от бизнес-аналитиков неструктурированные требования, которые подчас представляют собой кучу таблиц с атрибутами кнопок, жизненных циклов и так далее. На некоторых проектах подобные требования занимают до 600 страниц. А это половина книжного формата романа Война и мир.

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

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

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

Студия 2.0 оптимизирует затраты на тестирование, так как нет смысла делать отладку после работы автоматизированной системы.

Куда идём дальше

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

Отдельно список требований будет сформирован для подтверждения заказчиком.Он экспортируется в привычные офисные форматы DOC или XLS. Процесс займёт не больше времени, чем выпить чашечку кофе.

В будущем планируем сделать Студию кроссплатформенной. То есть отвязать её отплатформыОПОРА, гдеонасейчас работает, и подключать к другим системам. Это как раз то, чего не хватает многим системам автоматизированной разработки.

Намечен план развития до 2023 года. Студия уже сейчас используется для решения коммерческих задач компанииОТР. Но со временеммы отдадим её и во внешнее пользование.

Традиционные подходы к автоматизации HR насчитывают не один десяток лет, и обязательно требуют существенного вовлечения со стороны ИТ-службы (по крайней мере в крупных компаниях). Это приводит к необходимости искать общий язык, учиться формулировать задачи и идти итеративным путем, - imho редко когда ИТ-решения для управления персоналом сразу "взлетают". Пару лет назад все стали говорить о low code решениях как новом эффективном средстве для само-автоматизации, в том числе и в HR. Постараемся разобраться, насколько это перспективно.

Low code или No code решениями обычно называют программы для создания приложений (чаще всего для компьютера и/или мобильных платформ), которые позволяют "собрать" нужную вам программу из "кирпичиков" без необходимости писать программный код, иногда с применением минимальных формул как в Excel или немногочисленных команд. Рекламируется эта возможность для обычных пользователей, а не для программистов по образованию. Хотя на мой взгляд, это не совсем так удобно и радужно, как рассказывают их производители.

Low code программы обычно строятся на основе имеющихся или вновь создаваемых таблиц с данными, или имеющихся у вас баз данных, а также присоединяются к стандартным HR-системам типа SAP, Oracle, Salesforce. Также обычно есть возможность подключить имеющиеся таблицы Microsoft Excel или Google Sheets - многие кадровые процессы все еще ведут в простых таблицах (признаемся честно :).

Так вот, именно описанные выше возможности и кажутся большим плюсом - вместо покупки громоздкой программы и долгого мучительного "внедрения" и переработки ее "под себя", и вроде-бы citizen developer ("непрограммирующий разработчик") может за 1 день создать небольшое приложение под конкретную задачу, а потом его сами развивать, не прибегая к помощи ИТ. Даже больше:

• Вы можете менять интерфейс несколько раз в день, чтобы сделать действительно удобное для вас и сотрудников / руководителей приложение - вот он, моментальный Employee Experience Management!

• Вы сразу подключаете все свои старые тяжёлые Excel, не мигрируя данные.

• Вам не нужно обсуждать с ИТ реализацию новых возможностей, сами их добавляете.

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

• Облачное решение по подписке не очень дорого (по сравнению с коробочными HR-системами), и зачастую за фиксированную цену можно сделать сколько угодно приложений.

Пройдя обучение по трём ведущим low code платформам - Mendix, Microsoft PowerApps, Google AppSheet, и попробовав создать простые HR-приложения в каждой из них, готов добавить несколько "ложек дегтя" в описанный выше мёд:

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

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

• Low code отлично подходит под задачи сбора данных в ходе линейных HR-процессов - OKR, управление эффективностью, моментальная обратная связь, опросы, адаптация, взаимодействие сотрудника и кадровой службы по документарным вопросам (привет электронному документообороту). Но не совсем удобно создавать богатые контентом и сложными процессы, такие как микрообучение, сопровождение мероприятий, управления премированием, бюджетирование и подобные им.

В итоге, мое мнение таково: да, lowcode будет крайне полезен для применения в автоматизации HR и аналитике, но только в руках power users (пользователей понимающих в ИТ) и не для всех задач. Волшебной таблетки для типового сотрудника HR на мой взгляд не случилось.

Особенности этих платформ:

1. Mendix - один из пионеров low code, визионеров нового подхода. Весьма проработанное и дорогое решение, особенно в плане автоматического создания форм под данные и визуального оформления, за счёт несколько более низких возможностей интеграции. И главный плюс - легко ставится on-premise! Безопасники будут довольны.

2. Google AppSheet - самое дружелюбное решение (но похоже, все ещё в неофициальном бета-статусе, много возможностей экспериментальны), минимальное количество настроек, но они продуманы. Свой язык формул (не из Goggle Sheets) и мало вариантов визуала, хотя мне хватило. Просто подключиться к моему серверу MS SQL не получилось, хотя с облачными данными он работал идеально. Очень простой процесс деплоймента и отличительная особенность - встроенный советчик на основе искусственного интеллекта, хорошо проработанный механизм предупреждений и советов по созданию приложения.

3. Microsoft PowerApps - позже вышли на рынок, но очень быстро развились. Рекордсмены по количеству вариантов источников данных (насчитал 26 работающих вариантов, среди которых Google, Oracle, Teradata, Apache!), есть бесплатный Power Gateway который подключает ваши on-premise базы данных к облаку (безопасники будут недовольны). Визуальное оформление наверное самой простое в этой тройке, но самая сложная кривая обучения - обилие всевозможных свойств и настроек, объектов - это даёт гибкость и расширяет возможности за счёт усложнения разработки.

И все же, мой фаворит пока Google AppSheet, и очень надеюсь, они его допилят до настоящего enterprise-класса в скором#nbsp; времени. Для современного цифрового HR, не боящегося хранить данные в облаке и отрастившего у себя "цифровые" компетенции - это просто клад.

No-code сейчас в тренде. Статей на эту тему пока не много, хотя они появляются достаточно регулярно. На Хабре по тегу no-code и его вариантам я нашел всего около 15 статей и первая из них появилась только в июне 2020 меньше года назад! Во время чтения одной из статей у меня возникла идея собрать разные варианты no-code сценариев и снабдить некоторых из них, наиболее востребованных, инструкциями по реализации. Мне кажется, это будет интересно многим. Внизу после туториала, вы найдете пока небольшой, но пополняемый список сценариев и опрос, а пока давайте посмотрим как реализовать один простой сценарий.

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

Описание задачи

Предположим, вам нужен временный адрес, который не жалко засветить при регистрации на малоизвестном сайте или сайте с репутацией, вызывающей вопросы. После регистрации или когда надобность в адресе отпадет, можем удалить или оставить, но временно заблокировать его (см. об этом шаг 10c ниже) вдруг нужно будет позже восстановить пароль. Идея простая и очевидная и такие сервисы наверняка есть, хотя я сам ими не пользовался. Говорят, что существует такой сервис у Apple, когда при регистрации с помощью Apple Id, он предлагает подменить основной почтовый адрес временным. Хорошая идея, но в данном случае она доступна только владельцам яблочных гаджетов, более того, сайт на котором нужна регистрация, должен принимать Apple Id. Также я сам видел бота, который предлагал временный адрес почты. Это был простейший бот, но он почему-то не работал.

Получаются два стартовых условия: 1) делаем свой, кастомный и настраиваемый сценарий; подробнее об этом см. варианты развития сценария шаг 11 почти в самом конце; 2) обходимся без единой строчки кода.

Конечно, сценарий будет зависеть от сторонних сервисов и их поставщиков, а также будет, скорее всего, платным. Но есть и хорошие новости, он может быть создан на коленке за считанные минуты. В самом худшем случае, если вы делаете это первый раз или если вдруг что-то пойдет не так, за 1-2 часа максимум. В последние несколько лет количество новых no-code сервисов растет как на дрожжах, так что сценарий может быть реализован разными способами и мы можем выбирать наиболее удобный вариант и таким образом снизить зависимость от провайдеров no-code. Поэтому добавляем еще условие: 3) задействованные сервисы должны быть легко заменяемыми и настраиваемыми. В одной статье не получится полностью описать, как реализовать все 3 условия, но будем считать это заделом на будущее развитие сценария (шаг 11). Кроме того, сейчас не будем подробно сравнивать разные альтернативы и объяснять, почему именно эти варианты выбраны. Об этом есть множество других публикаций (примеры есть по ссылкам в следующем абзаце) и, конечно же, можете написать обо всех альтернативах в комментариях.

Альтернативы no-code

Если вы в первый раз слышите о no-code, возможно вам будет интересно почитать вводные обзоры и статьи для знакомства с отдельными сервисами. Для старта подойдет небольшой обзор No-code как отличная альтернатива для быстрого решения бизнес-задач. Взвешиваем pro et contra Движение No-code конец программистов? Разбираем плюсы и минусы. Введение в один из инструментов на Хабре n8n. Автоматизация ИБ со вкусом смузи.

Мы подходим к задаче серьезно, поэтому изучив и выбрав лучшие (на сегодняшний день) из доступных альтернатив, уточним ТЗ.

Техническое задание

Нужно получить временный адрес и указать его при регистрации на каком-то левом сайте/сервисе сомнительного качества или с репутацией, вызывающей вопросы. И далее мы должны будем получить письмо или как-то прочитать его. Нас интересует только ссылка или код регистрации в теле письма, поэтому достаточно его извлечь и переслать дальше. Вот только куда? На основной адрес? Но зачем нам это письмо на почте, может лучше в виде короткого сообщения в чате или даже СМС-ки. Можно подключить WhatsApp, Slack или другой мессенджер. Но удобнее всего, конечно, Телеграм, для него и сделаем сценарий.

Проблемы, которые должен решать сценарий: 1) в общем случае текст письма может быть длинным, в то время как текст сообщения ТМ ограничен до 4096 символов, нужно обрезать длинные письма или разбивать их на части, 2) нам нужно также извлечь из письма ссылку или код для регистрации, т.е. нужно уметь обработать не только plain-text, но и HTML.

Кажется, что все совсем просто приступим. Все, что мы будем использовать это сервис Zapier и мессенджер Телеграм. Если у вас пока нет Телеграма, хороший повод его установить.

Шаг 1. Регистрируемся в Zapier

Если у вас есть аккаунт, этот шаг пропускаем. Если нет, нужно будет пройти стандартную процедуру регистрации на сайте Zapier и выбрать тарифный план или тестовый период. К сожалению, я регистрировался давно и точных условий сейчас не знаю, кажется, бесплатный тариф позволяет выполнить до 100 операций в месяц. Это совсем мало, но для тестирования сценария хватит. К тому же, посчитайте, как часто вы регистрируетесь на разных сайтах? И если этот сценарий придется вам по вкусу и вы захотите его и адрес почты использовать на всю катушку, можно будет попробовать заменить Zapier на другой сервис (например, бесплатный n8n) или заплатить за тариф, который вас устроит.

Шаг 2. Создайте новый Zap

Нажимаем [MAKE A ZAP] см. скриншот

Шаг 3: Укажите название запа и выберите триггер

Нужно как-то назвать Зап/сценарий и настроить триггер, который его запускает.

a) Жмем на Name your zap и вводим название запа. Вы можете выбрать любое. Я назвал его TMP Email Zap.
b) Далее в строке поиска вводим: email, Zapier покажет доступные почтовые сервисы.
c) В качестве триггера доступны различные приложения, но они потребуют дополнительных действий и регистрации новых сервисов, скорее всего. Нам не нужны такие трудности, выбираем простейший и первый в списке вариант Email by Zapier. См. скриншот выше.

Шаг 4: Выберите событие триггера

a) В разделе Trigger event нажмите на Choose an event
b) Тут вариантов не много: выбираем New inbound Email. См. скриншот выше.
c) Нажмите дальше [Continue]

Шаг 5: Выберите адрес email

Укажите адрес почты:

a) Появится поле для ввода email-адреса. Можете добавить любое слово. Но важно использовать ТОЛЬКО буквы в нижнем регистре или цифры, иначе вы не сможете пройти дальше.
b) Сохраните полученный адрес (кнопка [Copy]), вы будете использовать его для регистрации на левом сайте.
c) Нажмите дальше [Continue]. См. скриншот выше.

ВНИМАНИЕ!!!

Не показывайте никому этот адрес. Иначе вы рискуете попасть на спам. После чего, в лучшем случае, вы превысите бесплатные лимиты и сценарий перестанет работать, а в худшем случае придётся заплатить рублем, причём не деревянным, а зелёным по текущему курсу ЦБ. Хотя Zapier не очень дорогой, но платить только за спам совсем не хочется.

Шаг 6: Протестируйте email адрес

После того, как вы получили адрес почты, можете его протестировать.

a) Попробуйте отправить письмо на адрес, который вы получили на шаге 5b.
b) После отправки письма нажмите кнопку [Test Trigger]
c) Если ничего не происходит или Zapier пишет что-то вроде Request no found, подождите несколько секунд и еще раз нажмите кнопку письму нужно время, чтобы дойти до сервера Zapierа
d) Если письмо все еще не пришло, проверьте, правильно ли вы скопировали адрес
e) После того как Zapier получит тестовое письмо, он покажет содержание письмо и все доступные поля (sender, subject и пр. их довольно много).
f) После тестирования, нажмите кнопку [Continue]

Шаг 7: Настройте бота, получателя сообщения

Можно самостоятельно зарегистрировать бота есть множество инструкций, как это сделать. Но если оставаться строго в парадигме no-code, можно воспользоваться уже готовым решением телеграм-ботом.

a) Откройте Telegram и бота по этой ссылке @co_notbot. Если у вас еще нет Телеграма, его нужно установить.
b) При входе нажмите кнопку [Start] или введите команду /start. Ждите некоторое время пока бот отработает команду. Появится сообщение с Главным меню бота и две кнопки внизу.
c) Нажмите на кнопку [Подключить]. См. скриншот выше.
d) Откроется следующее окно, в котором появится больше вариантов и кнопок. Нас интересует кнопка [Webhook]. Нажмите на нее и подождите до 1-3 секунд. См. скриншот ниже:

e) В следующем сообщении от бота вы получите вебхук, который нужно будет скопировать и затем добавить в наш Zap на шаге 9a.

ВНИМАНИЕ!!!

Не показывайте никому этот вебхук/токен и храните его в достаточно надежном месте. Иначе можете легко получить неприятный поток спама в свой до сих пор уютный чатик.

Шаг 8: Выбираем Action

a) Вернитесь в Zapier и нажмите кнопку [Action].
b) В строке поиска наберите web
c) Из списка выберите Webhook by Zapier. См. скриншот выше

a) далее выберите Action event, нажмите на [Choose an Event]
b) из списка выберите вариант [POST]. См. на скриншоте выше.
c) Нажмите дальше [Continue]

Шаг 9: Добавьте вебхук и параметры

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

a) в поле [URL] введите адрес вебхука, который вы получили на шаге 7e. На скриншоте приведен пример. У вас должна быть точная копия с токеном и адресом.
b) в поле [Payload Type] оставьте вариант [Form]
c) в следующем разделе [Data] нужно будет добавить/задать передаваемые параметры вебхука. Нам нужно будет задать одно поле text и его значение, в котором будет передаваться сообщение.
d) в поле text можно сначала добавить значение [Subject], [Sender], [Body Plain] или [Stripped Text] из письма
e) если тестирование (шаг 10) пройдет успешно, можно попробовать обрабатывать и передавать значения из html (об этом см. шаг 11c). Можно пробовать разные варианты и смотреть, что получится в результате. Если после выполнения Zapier будет выдавать сообщения об ошибках, попробуйте задать статическую строку, например, Hello world! и посмотрите, что получится.
f) остальные поля, ниже раздела [Data], заполнять и изменять не нужно

Шаг 10: Тестирование отправки письма и всего сценария

a) после того как все поля будут заполнены вы можете снова протестировать отправку письма и весь сценарий. Отправьте новое тестовое письмо и нажмите кнопку [Test & Review]
b) если тест пройдет успешно, то вы получите ответ в зеленой зоне и сообщение вроде Test was successful включите Zap/сценарий, нажмите на переключатель [off] [on];
c) обратным действием можно выключить (или на время заблокировать) этот сценарий позже

Шаг 11: Развитие сценария: извлекаем ссылки, добавляем фильтр, укорачиваем текст

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

a) проверка длины текста и самостоятельно решаем обрезать текст или делить его на куски < 4096 символов, чтобы не превысить лимиты Телеграма; можно реализовать по-разному, модулем Formatter by Zapier, например;
b) можно пересылать не каждое сообщение, а пропускать все сообщения через фильтр, который оставит только нужное и уберет спам, например. См. Filter by Zapier;
c) можно сделать более сложную обработку входящих писем и извлекать ссылки и/или картинки из HTML кода письма (Formatter by Zapier). Как вариант, после этого картинки можно пропустить через один из сервисов распознавания изображений для извлечения чисел/текста/номеров/лиц и пр.
d) можно самостоятельно зарегистрировать бота Телеграм и подключить один из бот-конструкторов; и тогда сможем реализовать бота по-своему и не будем зависеть от работоспособности стороннего бота. Правда попадем в новую зависимость от сервиса-конструктора;
e) можно сделать новый чат, куда с помощью аналогичного вебхука вместо письма настроить получение RSS, уведомлений или любого другого потока сообщений;
f) и наконец, можно сделать отдельные шаги взаимозаменяемыми, чтобы не зависеть от отдельного провайдера сервиса no-code. Например, вместо Zapierа можно использовать n8n или Integromat.

Как я обещал, кратко перечислю более-менее простые сценарии no-code. Выберите наиболее интересные на ваш взгляд.

• Кастомный фильтр спама на базе AI/ML

• Временная почта для регистраций (см. пример этого выше)

• Агрегатор и фильтр вакансий/новостей/объявлений/rss

• Сканирование и учет чеков и финансовых операций

• Кастомный uptime-мониторинг для сайтов, серверов

• Уведомления и команды Умного дома

• No-code решения для скилов Алексы или навыков Алисы

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