Low-code для корпораций: за и против

Дефицит разработчиков бизнес-приложений и динамика изменения конъюнктуры на рынках во всем мире вызвали очередной всплеск интереса к платформам low-code/no-code — конструкторам, позволяющим создавать ПО с минимальным программированием или вообще без него. Однако если в сегменте малых и средних предприятий необходимость таких платформ вопросов не вызывает, то для корпораций, обычно содержащих собственные крупные ИТподразделения со своим штатом программистов, применение low-code/no-code требует обоснований. Зачем подобные платформы крупным предприятиям? Какие бизнес-задачи они позволяют закрывать? Кто-то считает, что платформы low-code/no-code нужны лишь для тестирования бизнес-гипотез, а затем придется возвращаться к классической разработке. Кто-то видит в low-code/no-code устойчивую тенденцию к трансформации структуры бизнеса.

Возможность эффективного использования low-code/no-code в крупном бизнесе — тема обсуждения на круглом столе «Игра в low-code: зачем это нужно enterprise», прошедшем в рамках конференции LOW-CODE 2022, организованной издательством «Открытые системы».

Как отметил Всеволод Шадрин, модератор дискуссии круглого стола, при внедрении low-code/no-code часто приходится пресекать саботаж пользователей. Несмотря на, казалось бы, очевидную пользу такого подхода, сотрудники все равно сопротивляются насаждению новых инструментов. Еще чаще приходится сталкиваться с тем, что внедрение таких платформ саботируют внутренние разработчики, создающие «правильные» решения.

Кроме того, в ходе круглого стола обсуждалось еще несколько актуальных вопросов. Как проще и правильнее проверить бизнес-гипотезу: по-быстрому «накодировать» или реализовать процесс в low-code? И уж если в компании случился low-code/no-code, то кто должен играть главенствующую роль для успеха работы: аналитики или разработчики?

«ИТ-партизаны» и гражданские разработчики

«Low-code — это не только инструмент, но и средство изменения сознания. У айтишников и бизнеса головы работают принципиально по-разному: одни живут в пространстве векторов, объектов и свойств, а другие — в пространстве денег», — отметил Владимир Анисимов. Перевод с одного языка на другой — наболевшая проблема, с которой сталкиваются почти все компании. Начиная жить в новом мире сложных конструкций, гражданские разработчики быстро приходят к пониманию того, что появление одной новой галочки в приложении может повлечь написание километров кода — огромных доработок в унаследованных системах. Осознание принципов работы ИТ — очень важный результат усилий гражданского разработчика. До сих пор таких возможностей у бизнеса было мало.

Разумеется, есть и обратная сторона медали. Когда бизнес приходит с запросами к ИТ, то часто слышит, что сделать это невозможно, долго или дорого. Однако уже реализованное решение low-code гораздо проще перевести в промышленную эксплуатацию. Именно поэтому роль low-code в современном бизнесе будет только расти.

«Без сомнения, low-code очень хорош для быстрого решения проблем, когда требуется буквально за несколько дней из подручных средств собрать и запустить какой-либо продукт. И по мере своего взросления low-code будет занимать все большее место в создании приложений», — заявил Дмитрий Калаев. Популярность low-code растет — это бесспорно, причем в крупном бизнесе гораздо больше возможностей для его использования. Конечно, он не подойдет для решения всех корпоративных задач, но его применение может стать полезным для значительного числа перспективных направлений.

«У любого сотрудника есть поток задач. И чтобы с ними справиться, ему нужны компетенции и доступный инструментарий. Человек всегда зажат между скоростью потока задач и интенсивностью его обработки», — считает Станислав Фридкин. Low-code — один из инструментов, с помощью которых сотрудники компаний могут выстроить свой рабочий процесс. У специалистов появляется выбор: либо по-прежнему абсолютно непрозрачно работать в электронных таблицах, либо выстроить процесс и добиться его прозрачности, попутно сняв с себя часть рутины и сократив трудозатраты. Не менее важен и другой аспект: когда визуально выстроена последовательность из квадратиков со стрелочками, всегда можно без труда точно повторить процесс.

«Low-code был и раньше. Лет пятьдесят назад могло бы быть точно такое же обсуждение: айтишники, писавшие программы для больших ЭВМ на ассемблере, презирали Фортран, который считался тогда языком высокого уровня (был в статусе low-code по сравнению с ассемблером) и давал ученым возможность быстро делать расчеты», — напомнил в ходе обсуждения Леонид Головин.

По мнению Головина, для успешного развития подходов low-code компаниям нужен прогрессивный ИТ-директор, который правильно оценит место и роль такой платформы, выделит для нее песочницу в корпоративном ИТ-ландшафте, договорится с «безопасниками», предоставит необходимые инструменты и мощности, проведет обучение и привлечет «ИТ-партизан» — гражданских разработчиков, которые будут «возиться» в песочнице. Лучшее из созданного ими станет техническим заданием, на базе которого можно разрабатывать серьезные решения.

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

Впрочем, как предположил Фридкин, ИТ-директор может и не знать, над какими проблемами бьются ИТ-партизаны и какими средствами пытаются их решить. Аналогия с партизанами возникает не случайно: зачастую пользователи вынуждены скрывать свои разработки, чтобы не получить взыскания. «Мне приходилось видеть такие ситуации не только в наших, но и в зарубежных компаниях. Попытки делать собственные инструменты воспринимаются как проявление агрессии по отношению к корпоративным системам и могут иметь дисциплинарные последствия», — отметил Фридкин.

Жадность vs страх

Почему внутренние разработчики противостоят внедрению low-code? Они ведут себя как снобы или просто больше знают и поэтому настроены скептически?

«Low-code по идеологии ближе к микросервисной архитектуре. Но в большинстве компаний до сих пор используются монолиты. Встраивать в них доработанные кусочки всегда долго, дорого и трудно, потому что затем систему приходится тестировать полностью», — пояснил Анисимов. Именно это и вызывает основное сопротивление: как только создан работающий прототип и встает речь о его внедрении, у разработчиков появляется очередная головная боль. В компании с микросервисной архитектурой это воспринимается гораздо проще. Однако, по мнению Анисимова, другого пути нет. Low-code сегодня — единственный способ быстрой проверки бизнес-гипотез.

Как считает Калаев, реакция некоторых программистов объяснима — они действительно боятся остаться без работы. Вторая причина — психологическая: автоматически сгенерированный код вполне может быть неоптимальным, в нем нет красоты и изящества. И даже если забыть про потребляемые ресурсы, профессионала это может бесить. Однако на бизнес такой аргумент не действует — человеко-час дороже, чем потребленные гигабайты.

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

«Поспорю с тем, что настоящие программисты должны бояться лоукодеров. Скорее, лоукодеры должны бояться за себя», — заявил Головин. Еще два года назад нейросеть DALL-E, рисующая изображения по их текстовому описанию, казалась чем-то фантастическим. А сейчас таких систем уже много, и в результате дизайнеры начинают терять работу. Вполне вероятно, что через несколько лет введенной фразы с описанием желаемого результата будет достаточно для того, чтобы ИИ предложил готовый прототип системы. Бизнес-руководители будут аплодировать, и гражданские разработчики тогда уже не потребуются. Самым ценным сотрудником станет тот, кто знает, что ему нужно, и способен это сформулировать нормальным языком.

Жизнь без low-code

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

«В скорости low-code точно выигрывает, но мы платим за это ограничением возможностей. По моим ощущениям, экономия времени составляет около 20–30%», — оценил Анисимов.

Калаев уверен, что с точки зрения проверки бизнес-гипотез идеальный вариант — не программировать вовсе. Некоторые из гипотез можно проверить в буквальном смысле вручную: с ручкой и бумагой: «Исходя из моей практики, вручную можно проверить 80% гипотез. Еще 15% имеет смысл проверять с помощью low-code, а еще 5% — лишь полноценным программированием». Конечно, проще всего пользоваться привычным инструментом, а подумать и понять, как решить задачу проще, — отдельный навык изобретателя.

Как утверждает Калаев, команда, проверяющая гипотезы, обходится в 15–20 млн руб. в год. В зависимости от ее навыков и вида бизнес-гипотез она может проверять одну гипотезу в год, квартал или даже неделю.

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

Каждому свое

«Применять low-code или нет, должен решать бизнес, который больше всего в нем заинтересован. У аналитиков все и так неплохо, у разработчиков — еще лучше. А вот у бизнеса голова болит всегда», — объяснил Анисимов. Именно бизнес диктует требования к проверке гипотез на цифрах, и у него нет времени вставать к ИТ-подразделению в очередь на проверку, чтобы узнать, работает идея или нет. А прототип, разработанный на low-code, позволяет не только оценить эффективность, но и «пощупать» созданное решение — это главный плюс такого подхода.

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

Головин согласился с тем, что low-code как инструмент прототипирования более востребован у людей, работающих в бизнес-подразделениях, чем у системных аналитиков и разработчиков. Более того, он уверен, что low-code для ИТ-служб — очевидное зло. «Это все равно что предложить компании, которая строит здание, использовать алебастровую замазку. У нее есть свои инструменты и свои регламенты. А замазка — это скорее для тех, кто создает рядом киоск быстрого питания, чтобы быстро решить проблему с едой для строителей», — сказал Головин.

В итоге дискуссии эксперты сошлись во мнении, что каждому сотруднику крупной компании необходим свой инструмент: бизнесу — платформы low-code, а айтишникам — «нормальные» средства разработки. На данном этапе подход low-code, также как некоторое время назад Agile, позволяет небольшими шагами прийти к тому, чего хотят бизнес-пользователи. Именно поэтому он и стал сегодня так популярен.

Николай Смирнов (nsmirnov@osp.ru) — независимый автор (Москва).