Почему Low-code плохо приживается

Привет, vc.ru. Меня зовут Георгий Ржавин. Я работаю процессным архитектором в компании GlowByte, руковожу направлением Business Process Management. В этой статье хочу обсудить основные причины неэффективности современного лоукода и, основываясь на своих наблюдениях, обозначить пути решения проблемы.

Для начала давайте разберёмся в понятиях. Любой современный бизнес не мыслит себя без сильного ИТ. Яркий пример – банки, которые представляют собой ИТ-компании с тысячами разработчиков на борту. При этом данный ресурс остаётся для компаний в дефиците: ИТ-подразделения, как правило перегружены, задачи распланированы на месяцы вперёд. Вот так плавно мы с вами подходим к термину Low-code. В действительности Low-code – это попытка сместить тяжесть разработки с ИТ в сторону бизнеса. Сместить на сам бизнес ещё не получилось, но, по крайней мере, появились проекты, где 80 % всех работ закрывают бизнес-аналитики (не ИТ-специалисты). Именно такие проекты мы и будем в рамках данной статьи называть Low-code.

Ещё одно уточнение. Low-code-подходы распространились достаточно широко – от создания сайтов и мобильных приложений до автоматизации бизнеса. В рамках данной статьи реализация Low-code-подхода будет рассмотрена на примере систем класса BPMS (Business Process Management Suite).

Если ещё лет 5 назад на конференциях можно было услышать вопросы: «А вы верите в Low-code?», «Неужели не ИТ-специалист может что-то, пускай даже небольшое, сам автоматизировать?». Сейчас такой проблематики уже нет, Low-code прочно вошёл и обосновался на российском рынке. Подтверждением тому являются конференции, полностью посвящённые Low-code-инструментам. Но возникла другая проблема – низкая эффективность Low-code-проектов. Нет тех скоростей, которые нам обещали с появлением этого подхода.

Для начала давайте развеем одно из заблуждений. Low-code – это не набор параметров или обязательных инструментов, при наличии которых система получает это звание. Здесь правильней рассмотреть некую горизонтальную шкалу, в левой части которой находится классическая разработка, а в правой – No-code-проекты, когда 100 % работ может закрыть не ИТ-специалист, не написав при этом ни одной строчки кода. Всё остальное пространство между этими двумя крайними положениями занимают Low-code-инструменты. При этом кто-то из вендоров «ушёл» дальше и приблизился к No-code-инструментам, а у кого-то Low-code-инструментарий очень скромный и любой проект требует написания кода.

Рассмотрим в данном примере две системы класса BPMS: Bizagi и ELMA 3 (4). В первой аналитик может самостоятельно в конструкторе собрать пользовательскую форму, а также сделать её динамической (скрывать или показывать поля в зависимости от действий пользователя системы), и всё это настраивается с помощью мышки, без кода. В ELMA так же есть конструктор, позволяющий собрать пользовательскую форму, но вот для добавления динамики уже придётся писать код на внутреннем сценарном языке – на базе C#.

Поэтому две системы одного и того же класса в зависимости от функционала и объёма Low-code будут «выдавать» разные скорости разработки и требовать разный состав команд. Но об этом чуть позже.

Давайте ещё раз вернемся к основной идее (и даже причине) появления Low-code – попытке сдвинуть «тяжесть» разработки с ИТ-специалистов на не ИТ-специалистов. Это случай, когда ожидание не совпало с реальностью, потому что зачастую я наблюдаю в командах, работающих с BPMS, преимущественно разработчиков, причём, как правило, очень злых и всё время чем-то недовольных. И их можно понять, их заставляют автоматизировать процессы в каком-то миксе мышки и привычного для них кода. Они искренне не понимают, зачем им в дополнение к знанию языков программирования изучать некий инструмент мышкования, почему нельзя писать на современной версии языка (как правило, когда до нас доходит BPMS, версия языка, который она поддерживает, устаревает). Почему нельзя использовать всю мощь современной разработки (git, отладка и т.д.). Ради чего всё это было принесено на алтарь Low-code.

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

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

А вот «скормить» её BPMS при наличии ошибок не получится. Поэтому самое первое требование к исполняемой схеме процесса – это соответствие стандарту BPMN 2.0. С последним у аналитиков в России большие проблемы, потому что нотацию изучают в основном стихийно, на практике, не обращаясь к первоисточнику. Как результат – создать модель процесса, которую поймёт и домыслит разработчик, любой аналитик может, а вот построить модель без ошибок, согласно стандарту, практически нет. Таких на рынке единицы, ну, может быть, десятки. Сейчас меня могут закидать помидорами, но, поверьте мне, я знаю о чём говорю, так как сам являюсь представителем аналитиков, хожу на профильные конференции, общаюсь с коллегами по цеху.

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

Ещё одну характеристику, которую нам обещали в Low-code BPMS, – высокую скорость внесения изменений – мы также где-то во время внедрения этих инструментов теряем. И это действительно так, это не обман маркетологов. Доказательством этого явления была следующая картина, которую я наблюдал в крупной организации. Одна команда вносила изменения в текущие автоматизированные процессы за часы, а другая, на таком же инструменте, но на соседнем сервере, – дни. После анализа ситуации стало ясно, что вопрос не в компетентности сотрудников, а в архитектуре итогового решения. Дело в том, что на старте обоих проектов каждой из команд была вручена система в одном и том же состоянии, а дальше одна из систем растеряла все свои лоукод-инстурменты и по сути представляла монолит с оболочкой BPMS. В результате в первой команде аналитик заходил в конструктор форм, добавлял кнопку с помощью мышки, «вешал» в её настройках необходимое поведение. А второй команде для достижения такого же результата нужно было анализировать код пользовательской формы, добавлять туда кнопку, а далее всё тщательно тестировать. В первом случае всю дополнительную работу делала Low-code-система.

Давайте разбираться, как так получилось и как этого нужно было избежать. Дело в том, что BPMS представляет собой конструктор. Ваша задача – либо собирать нужный функционал из готовых кубиков, либо добавлять новый, но обязательно не лениться и заворачивать их в готовые кубики, чтобы тем самым обогащать конструктор. Ни в коем случае не нужно «пилить кубики» и «заливать всё цементом». Под кубиками я имею в виду любые части системы на любом уровне: процесс, элемент пользовательской формы, сервис, бизнес-правило и т.д. Да, это требует дополнительных накладных расходов, но в будущем они очень быстро окупаются.

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

Баланс при работе в BPMS найти легко. Достаточно соблюдать следующий набор правил:

1. Приоритизация стандартных объектов системы перед кастомными.

2. Если нужного функционала нет, разрабатываем свой, но обязательно стараемся делать его универсальным. Тем самым обогащаем конструктор новыми «кубиками» для последующей работы.

В конце статьи хотел бы описать идеальный проект по внедрению BPMS, к которому нам надо стремиться:

1. Тщательный выбор BPMS. Подскажу один лайфхак. Попросите вендоров BPMS автоматизировать небольшой процесс прямо во время демонстрации продукта. Так вы сможете прорваться через маркетинговые картинки и на практике увидеть, насколько лоукодистой является рассматриваемая система. Ну а если у вас сформированная команда разработчиков и именно они будут заниматься автоматизацией, то я вам рекомендую в первую очередь посмотреть в сторону BPM-engine (Camunda, Activiti). Разработчики вам только спасибо скажут.

2. Формирование команды. Обязательно включайте в команду процессных аналитиков и правильно распределяйте полномочия. В Low-code-инструментах работать должны в первую очередь аналитики. Не прощайте аналитикам схемы в нотации BPMN 2.0 с нарушениями стандарта. При необходимости отправляйте их на обучение.

3. Играйте по правилам BPMS. Если выбрали данный инструмент, обязательно изучите его и старайтесь играть по правилам. Не нужно сломя голову реализовывать любой каприз бизнеса. Я наблюдал такую картину, когда в проекте полностью отказались от конструктора пользовательских форм (увеличив трудозатраты на автоматизацию в разы, если не в десятки раз) только из-за требования бизнеса разместить вкладки на форме вертикально (в конструкторе можно было только горизонтально). Самое интересное то, что при повторном согласовании дизайна выяснилось, что бизнесу никто не предлагал реализовать по-другому, более того, данное требование не было критичным и можно было вполне остаться в рамках конструктора.

Не так плох Low-code, если умеешь его правильно "готовить”!

#lowcode #it #glowbyte #лоукод