Что такое Low-code система
Под Low-code системами в рамках этой статьи я подразумеваю в первую очередь Low-code BPMS. Это класс специализированных корпоративных конструкторов, в которых пользователи без серьезных технических навыков могут вместе с разработчиками создавать корпоративное ПО. И сегодня это логичный трек развития BPM-систем, который позволяет создавать сложные корпоративные решения с меньшим количеством кода и большим вовлечением самых различных специалистов.
Типовые ошибки при внедрении Low-code систем
Технология сегодня хайповая, с маркетинговой точки зрения красиво оборачивается и продается как что-то, что позволит мгновенно создавать корпоративный софт, программисты не нужны, все само собой получится и будет дешево и классно работать. И хотя доля истины в этом есть, чудес не бывает: важно избежать типовых ошибок, потому что иначе вы рискуете просто потратить бюджет, потратить время и остаться с неработающим продуктом.
Ошибка №1. Внедрять только силами внешнего подрядчика
Это часто встречающаяся ошибка: для внедрения Low-code системы привлекают сторонних специалистов, а работа внутренней командой не ведется вовсе. Это имеет смысл, если у компании нет совершенно никакого интереса к развитию IT. Однако это убивает суть использования технологии, потому что идея и основная ценность Low-code системы в том, чтобы экспертиза сформировалась внутри компании. Важно создавать центр компетенции, чтобы внутри компании остался опыт и знание того, как это решение работает, как его сопровождать, как улучшать и какие есть возможности по дополнительной настройке — так мы получаем не только работающее решение, но и перспективу его дорабатывать, улучшать в дальнейшем. Даже если хотя бы один человек в компании как следует погрузится в экспертизу этого решения, он сможет формировать квалифицированные запросы стороннему подрядчику. А самая большая ошибка — когда нет ни команды, ни отдельного эксперта. По сути, это создание очередного абсолютно негибкого монолитного решения.
Ошибка №2. Внедрять командой без опыта
Да, Low-code системы просты, обучение проходит быстро. Но если говорить о серьезных решениях для enterprise-корпоративной автоматизации, вроде той же ELMA, — за два дня или за две недели обучиться работе в системе невозможно, на это уходят месяцы, и знание всех нюансов потребует времени.
Конечно, в работу внутри команды вовлекаются люди без опыта или подготовки, но всегда нужен костяк обученных специалистов, кто способен выступать в роли постановщика задач, архитектора и тому подобное. В противном случае время будет потрачено впустую: если люди работают и создают решения, совершенно не понимая, в каком направлении им двигаться — естественно, они придут куда-то не туда. Поэтому идея внедрять командой без экспертов, которые знакомы с Low-code системами и паттернами проектирования, обречена на неуспех.
Если в команде таких нет — поищите на аутсорсе сертифицированных специалистов по тем или иным системам в команде системных интеграторов или у вендора. И повторю еще раз: важно формировать собственный центр компетенции, чтобы прямо внутри команды формировалось экспертное сообщество, которое бы генерировало идеи и могло их либо имплементировать самостоятельно, либо передавать на сторону.
Ошибка №3. Работать без архитектора системы
Специалисты, попробовав создавать что-то в Low-code системе, понимают, что это похоже на работу в конструкторе, когда из простых решений-«кубиков» можно создавать серьезные бизнес-продукты. Но если у этой команды нет архитектора, то каждый будет создавать решение так, как ему вздумается. Обычно это приводит к тому, что создается тяжеловесное, неповоротливое, неудобное, очень прожорливое к вычислительным ресурсам решение с ошибками логики. Если есть наставник, куратор, архитектор, который позволит этих ошибок избежать — продукт обернется исключительно положительными результатами.
Ошибка №4. Не следовать принципам разработки программного обеспечения
В профессиональной современной hardcode-разработке выработано множество принципов, которые касаются написания кода, code review, тестирования, выпуска релизов и так далее. И любой современный разработчик с ними так или иначе знаком и следует им.
Если же говорить о citizen-девелоперах или Low-code разработчиках — они зачастую начинают изобретать велосипеды. Если внутри компании нет культуры выпуска релизов, проект внедрения столкнется с плохим тестированием, с конфликтами между командами и утонет в потоке ошибок в решениях. Опыт не будет переиспользоваться, одинаковые решения будут создаваться заново и заново, причем зачастую чуть-чуть по-разному. В итоге внутри решения могут оказаться очень похожие идеи, реализованные несколько по-разному, что не пойдет на пользу проекту в целом и будет вводить в заблуждение пользователей конечного продукта. Поэтому важно, чтобы в команде была правильно организована рабочая дисциплина и чтобы человек с грамотным техническим бэкграундом мог управлять релизами, тестированием, выпуском новых функций, исправлением ошибок и выстроил конвейер разработки.
Ошибка №5. Не привлекать программистов
Иногда все решение пытаются реализовать исключительно силами аналитиков, то есть используют исключительно инструменты Low-code в рамках Low-code системы. Это не самая драматичная ошибка, но участие в команде не только аналитиков и бизнес-пользователей, но и серьезных программистов позволяет расширить возможности системы. Например, кастомизировать, написать более простые интеграции и сделать жизнь конечных пользователей легче, потому что некоторые вещи не решаются настройкой — иногда нужно просто написать код и сделать удобно, красиво и быстро.
Важно грамотно управлять и требованиями, и возможностями команды. Пусть аналитики и бизнес-пользователи делают то, что могут, но некоторые задачи лучше решать силами программистов. Если их не привлекать, это часто приводит к неудобным решениям.
Ошибка №6. Не привлекать администраторов системы
Когда создается низкопроизводительное решение без привлечения CI/CD DevOps специалистов, то это решение так в песочнице и растет. Для любого серьезного IT-решения важно управлять нагрузками, заниматься оптимизацией, работать с серверными мощностями или (в случае облака) как минимум привлекать специалистов со стороны облаков или использовать правильный хостинг.
Ошибка №7. Забывать о вопросах безопасности
Разработка продукта часто ложится на плечи бизнес-пользователей и аналитиков, которые не так глубоко погружены в вопросы информационной безопасности, и в результате политика информационной безопасности используется довольно небрежно, а права выдаются как попало. При этом в современном мире вопрос безопасности стоит крайне остро, и, если не проверять, насколько конечное решение соответствует требованиям информационной безопасности, система может стать уязвимой для потенциальных злоумышленников.
Ошибка №8. Пытаться сделать «как было»
Обычно автоматизация строится не в чистом поле: уже есть какие-то системы со своими преимуществами и недостатками, и при внедрении нового инструмента автоматизации компания пытается полностью воссоздать тот привычный продукт, что порождает противоречия с особенностями нового продукта.
Важно взвешивать и пытаться здраво отнестись и к требованиям, и к возможностям нового продукта. Не всегда имеет смысл кастомизировать все и вся, пытаясь полностью повторить то, что было — если это противоречит принципам и паттернам нового продукта, это приведет к нежелательным последствиям и увеличит сложность и длительность реализации этого кейса. Иногда надо быть более открытым к изменениям и прислушиваться: возможно, пришло время понять, что старые привычки не являются лучшими практиками, и есть смысл обратиться к новым.
Резюме
Большинство из типовых ошибок использования Low-code систем происходит из-за того, что продукт начинают воспринимать как слишком легкий, слишком доступный инструмент исключительно для citizen-девелоперов, аналитиков и бизнес-пользователей. В результате плохо привлекают к работе технических специалистов, что приводит к хаосу, нарушению современных практик разработки программного обеспечения и созданию незрелых, нестабильных продуктов с недостаточно высокими параметрами быстродействия и безопасности.
Low-code система — это технически сложный продукт, который предполагает вовлечение не только citizen-девелоперов в рамках Low-code разработки, но и серьезного технического персонала для программирования, администрирования и поддержки. Сочетая таких специалистов, можно создать сильную команду, которая использует Low-code систему на полную мощность, может применять ее сильные стороны и создавать сложные корпоративные продукты действительно быстро.
