Сейчас в IT-сфере набирают популярность так называемые low-code и no-code системы. Разработчики таких систем твердят, что с помощью их продуктов бизнес может создавать прикладное ПО без профессиональных разработчиков. Еще и весь интернет набит статьями, которые преподносят low-code и no-code как что-то кардинально новое и очень крутое для людей, которые не умеют программировать. Так ли это на самом деле?

Меня зовут Виктор Никитин, мы с командой разрабатываем Бипиум — low-code платформу для создания корпоративных IT-систем. Хоть и называем себя low-code мы трезво относимся к этому, не обещаем людям, что они смогут создавать сложные информационные системы за дни.

Чтобы понять когда нужны, как использовать и эффективны ли low-code и no-code системы мы решили выпустить цикл статей с мнением профессиональных разработчиков, аналитиков, предпринимателей. Цикл статей будет полезен людям, которые хотят решать бизнес задачи с помощью IT и ищут новые способы автоматизации процессов.

Сегодня мы позвали на интервью Григория Петрова, DevRel Evrone. Он ответит на вопросы про историю происхождения методов, на чем они строятся и на каком этапе развития бизнеса их можно использовать.

Виктор: Что заставило разработчиков двигаться в направлении low-code и no-code систем?

Григорий: Итак, давайте поговорим про low-code и no-code. Откуда вообще взялись эти концепции трёхколёсного велосипеда? Зачем трёхколёсный велосипед если у двухколесного велосипеда гораздо больше маневренность, он быстрее едет, меньше усилий надо прикладывать и так далее. Потому, что у двухколесного велосипеда относительно трёхколёсного есть один фундаментальный недостаток — ездить на нем надо учиться. Ты не можешь просто посадить человека на двухколесный велосипед и сказать: «Езжай!». Будет больно. Поэтому для обучения существуют трёхколёсные велосипеды, да и в целом если по каким-то причинам человек не хочет учиться или не может ездить на двухколесном велосипеде есть трёхколёсный.

Я живу в Нидерландах. Тут на улицах много велосипедов. Я регулярно встречаю трехколесные. Они очень редки, потому что они объективно хуже чем двухколесные — всем, кроме того, что учиться надо. Но они реально есть. Люди катаются. Они крутые, футуристичные, стоят десятки тысяч евро. Если хочешь, то используй. Упасть с такого нельзя.

Так же и с программированием. Программирование традиционно было такой же областью, как и двухколесный велосипед — недостаточно быть просто хорошим человеком, чтобы начать программировать. Обычный хороший человек может сказать —  «А теперь я бариста» и идти варить кофе. Чтобы варить кофе тебе не нужны никакие hard skills. Понятное дело, что у хорошего баристы, который работает много лет кофе будет вкусный, а у человека, который это делает первый раз в жизни кофе будет невкусным. 

Хороший человек не может сказать: «А теперь я программист. Дайте мне работу, заплатите денег и я все сделаю». Нет, не сделает, потому что программирование как и многие сложные штуки требует hard skills.

Тут важно понимать, что навыки человека делятся на hard и soft skills. Есть много разных определений. Я, как человек, интересующийся нейрофизиологией, даю такое определение хард и софт скиллов:

Hard skills — навыки, которым мы обучаемся по учебникам осознанно. Мы берем учебник и приносим ему в жертву несколько сотен, тысяч или десятков тысяч часов и получаем некий навык. Мы можем усвоить навык хорошо или плохо, мы можем интернализовать или не интернализовать, пользоваться только учебником или другими источниками — это неважно, главное, что мы берём учебник, читаем его, осознаем и изучаем. Это стресс для мозга и требует времени. В общем, не самое приятное занятие.

Soft skills — навыки, которым наша нейросеть обучается автоматически. Их можно улучшать читая учебники, но само применение soft skills подразумевает интернализацию, что наша нейросеть этому обучится. Например, к soft skills относятся публичные выступления. Единственный способ научиться публично выступать — это публично выступать. Ты выступаешь, выступаешь, и через сотни, тысячи выступлений твоя нейросеть обучается выступать. Ты можешь это улучшать, ты можешь читать учебники как правильно выступать, ходить на тренинги, но в целом суть софт скиллов — обучение нейросети в процессе практики. Ты не можешь научиться этому без практики. Тебе нужно постоянно тренировать навык и нейросеть сама обучится и автоматически будет его применять.

Программирование — это не про soft skills. Ты не можешь обучиться программированию так же, как ты обучаешься катанию на велосипеде. Это hard skill, hard от слова тяжело. Берёшь учебник и начинаешь по нему учиться.

Это традиционно хороших людей сильно огорчало. И вот, чтобы дать хорошим людям возможность программировать разработчики придумали low-code и no-code системы. В первую очередь low-code, конечно.

Виктор: По каким принципам они создавались? Как человек, который не изучает по учебникам какую-то область может применять навык из этой области?

Григорий: Для этого разработку приводят к тем знаниям, которые у всех людей уже есть. Тем самым soft skills, которым нейросеть обучается.

А чему нейросеть в принципе за жизнь обучается у большинства людей? В большинстве культур скорее всего люди умееют разговаривать, слушать слова и осознавать то, что им сказали. Скорее всего они умеют навигировать в современном мире, то есть представляют себе или умеют пользоваться основными механизмами современного мира. Знают что такое дверь, окно, автомобиль, город, электричество, выключатель электричества, лампочка, микроволновка и так далее.

На основании этих предположений создаются системы no-code. Суть таких систем в том, что ту часть, где требуются hard skills представляют в виде аналогий из области soft skills. То есть, вместо того, чтобы дать человеку скальпель и пациента мы даем ему ассистента, который умеет выполнять голосовые команды. no-code представляет soft skills интерфейс для использования которого достаточно аналогий с тем, чему нейросеть хорошего человека уже обучилась.

Виктор: Когда началось low-code и no-code движение?

Григорий: Началось это довольно давно — десятки лет назад. Первые системы no-code строили мостик между миром hard skills, и soft skills путем аналогий. Было две концепции систем: первые пытались делать визуальные аналогии, вторые пытались делать языковые аналогии.

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

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

Ключевым отличием визуальной от текстовой является то, что визуальной no-code системе гораздо сложнее отдать противоречивую команду. Потому что набор операций и объектов фиксирован. Тебе сама среда не даст создать операцию, которая невозможна.

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

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

У no-code систем есть фундаментальный недостаток. Визуальная система нашего мозга не очень хорошо масштабируется, в отличие от других систем.

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

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

(пример из детской игры про соединение шланга на заправке)

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

Мир не отказался от no-code, потому что идея о том, что любой хороший человек не тратя сотни часов сможет создать систему выглядит очень привлекательно. Именно поэтому регулярно приходят компании и говорят: «Мы сделали визуальную систему». Люди начинают пользоваться и пока в ней 5-10 объектов она работает отлично, но как только квадратиков становится 100-1000 работать система перестает.

Виктор: Что с low-code?

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

Поэтому low-code системы родились как попытки объединить оба направления. low-code системы большую часть сложности запихивают в черные ящики-абстракции, которые человеку не нужно понимать и комбинируют их с минимальным количеством программирования, чтобы можно было создать более сложные решения чем в no-code. Если проводить аналогии с реальным миром, то хорошим примером будет автомобиль. Человеку, чтобы пользоваться автомобилем все еще нужно учиться на нем ездить, но при этом не нужно быть инженером, чтобы понимать как он работает. Автомобиль скрывает от человека всю сложность предлагая ему какое-то количество высокоуровневых абстракций: руль, педали, правила дорожного движения. Используя эти абстракции человек не сможет участвовать в гонках Формулы 1, но сможет решить главную задачу — ездить из дома до работы и обратно.

Виктор: С точки зрения компании, которой нужен IT-продукт. Когда подходят no-code и low-code решения?

Григорий: Чтобы понять подходит ли вам no-code или low-code решение нужно всего лишь понять насколько сложным должен быть итоговый продукт. Чем более сложную систему компании нужно сделать, тем больше ей нужно именно профессиональных разработчиков, которые с этой сложностью будут справляться. Если компании нужен чат-бот, то если они знают, что этот чат-бот с вероятностью 95% не эволюционирует в сложную систему, которая будет выполнять миллион действий, то использование low-code или no-code штуки будет целесообразно. Потому что  существующие сотрудники компании смогут это сделать, нанятый человек сможет сделать это быстро. Гораздо быстрее, чем если будет писать код с нуля. 

Итого — чем меньше сложность системы, которую компания хочет соорудить, тем привлекательнее становятся low-code и no-code. Чем более сложную штуку нужно делать, тем менее привлекательны low-code и no-code и более привлекательна разработка на платформе или индивидуальная разработка с нуля, если мы точно знаем, что делаем что-то совсем сложное и кастомное.

Виктор: Возникает проблема — у большинства компаний нет компетенций, чтобы понять какой сложности система нужна. Что делать в таком случае? 

Григорий: Таким компаниям подходит традиционный эволюционный подход. Сначала берется no-code решение и делается что-то очень простое. Это простое им нравится и у них возникают хотелки, но они упираются в ограничения no-code, выкидывают все и переделывают в low-code. Некоторое время счастливо живут, а потом хотят еще более сложное и если понимают, то выкидывают low-code системы со скрипом и переходят на какую-то платформу/фреймворк, нанимают программистов, которые делают решение на ней. И наконец, когда они упираются в ограничения платформы/фреймворка, то начинают создавать собственное решения с нуля, которое полностью заточено под их специфику.

Виктор: Как быстро можно вносить изменения в продукты на low-code и no-code?

Григорий: В рамках no-code ты можешь быстро вносить изменения в ограниченном мире. 

В low-code ты можешь менее быстро вносить изменения в менее ограниченном мире.

В классическом программировании скорость внесения изменений зависит исключительно от разработчика и архитектуры.

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

Заключение

Да, low-code помогает бизнесу быстро создавать IT-решения. В рекламе не врут, но как всегда есть недосказанность. Для использования low-code систем вам все же нужно уметь программировать.

Low-code и no-code решения действительно полезны для бизнеса. Только полезны они в разные этапы развития цифровой грамотности.

В самом начале вы используете no-code решения, потому что вам нужно что-то простое и вы не хотите тратить на это много времени. После этого, когда вы наиграетесь с no-code решениями и вам понадобится что-то более сложное, вы придете к low-code системам.

Когда вам понадобится очень сложный, кастомный, громоздкий IT-продукт, вы начнете делать его с нуля.

Осталось только понять на каком этапе вы находитесь и начать пользоваться нужным продуктом.