Многие организации сегодня ожидают невозможного от инструментов Low-code, поэтому их инициативы терпят неудачу. Вице-президент WEBCON Майк Фицморис называет на портале InformationWeek четыре основные причины такого положения дел.

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

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

1. Инструменты Low-code часто оказываются не в тех руках

Хотя инструменты Low-code рекламируются как платформы, которые любители (гражданские разработчики) могут использовать для легкого создания приложений, они не предназначены для того, чтобы любой мог решить любую проблему. В качестве иллюстрации можно привести следующий пример: многие люди могут играть на пианино на любительском уровне, некоторые даже умеют играть хорошо, но лишь немногие являются настоящими пианистами. Инструмент используется один и тот же, но по мере увеличения сложности требуется более высокий уровень мастерства. Реальные бизнес-проблемы требуют, чтобы инструменты Low-code для ускорения цифровых изменений использовались правильными людьми (как правило, профессиональными разработчиками). Low-code должен быть привлекателен для всех. Однако на практике чаще всего ими пользуются профессиональные разработчики — это позволяет им сэкономить время.

2. Инструменты Low-code применяются неправильно

Если профессиональные разработчики используют инструменты Low-code для более быстрого создания приложений, но не прислушиваются к мнению заинтересованных сторон, они все равно будут создавать ужасные приложения — просто они будут создавать их быстрее. Эти инструменты не спасают плохих разработчиков от плохой разработки. К Low-code нужно относиться как к настоящим, профессиональным проектам разработки. Пользователи, которые срезают углы и думают, что все проблемы будут решены в процессе тестирования (но затем не тестируют приложение), столкнутся с серьезными проблемами. Принципы Agile должны применяться к Low-code так же, как и к традиционным методам разработки. На самом деле, итерации нужно проводить даже чаще, чтобы убедиться, что приложения отвечают меняющимся потребностям заинтересованных сторон.

3. Не уделяется должное внимание развертыванию и сопровождению

Многие проекты Low-code создаются в производственном режиме. Допустим, предприятие создает решение для обработки заявок в службу поддержки или отчетов о расходах, и появился новый способ улучшить его. Вместе с тем возникает вероятность, что его применение может вывести из строя само решение (очевидно, что это очень плохо). Или же обновления будут раздражать других пользователей и не позволят им найти то, что они ищут, когда решение находится в производстве. Инструменты Low-code позволяют очень быстро воплощать новые идеи, но прежде чем вывести изменения в производство невероятно важно их протестировать, а также подготовить и обучить ИТ-специалистов и пользователей.

Разработка в производственной среде может нарушить работу пользователей или повредить живые данные. Что особенно верно для многих проектов гражданских разработчиков, так это то, что управление изменениями не является высшим приоритетом. Для одноразовых доставок существуют средства упаковки/развертывания, но это часто приводит к полной перезаписи исходного приложения. Фактическое управление изменениями редко встречается среди платформ Low-code.

4. Фокусировка на создании приложения, а не на его доставке

Создание приложения — это только 10% процесса его доставки. Например, инструменты Low-code не помогут создать хороший дизайн для вашего решения, сделать его совместимым или должным образом защитить его (возможности для обеспечения безопасности могут быть очень ограничены). По умолчанию платформы Low-code часто позволяют пользователям делать все, что не запрещено. На разработчика решения ложится ответственность за лишение пользователей ненужных привилегий. Обычно гражданский разработчик сам должен заниматься аудитом и мониторингом. Это же касается документации, не говоря уже о том, что ему самому приходится учиться обращаться с платформой. Процедуры обслуживания обычно выполняются вручную или вообще отсутствуют.

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

Инструменты Low-code неуклонно набирают популярность, и Gartner прогнозирует, что к 2024 г. создание приложений на их основе составит более 65% всех функций разработки приложений. Эта технология набирает обороты, и организациям будет еще важнее задуматься о том, кто, как и для чего их использует.