Типичные ошибки при внедрении low-code систем

Что такое 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 систему на полную мощность, может применять ее сильные стороны и создавать сложные корпоративные продукты действительно быстро. Ссылка на источник