Можно ли эффективно использовать low-code для реализации процессов в крупном бизнесе? Эту тему обсуждали на круглом столе «Игра в low-code: зачем это нужно enterprise», прошедшем в рамках конференции LOW-CODE 2022, организованной издательством «Открытые системы» (см. также «LOW-CODE 2022: Польза неоспорима, но не панацея» и «LOW-CODE 2022: Актуальность платформ для 'гражданских' разработчиков растет»).
Как признал Всеволод Шадрин, руководитель развития продуктов Naumen Platform, выступавший модератором дискуссии, при внедрении low-code часто приходится пресекать саботаж пользователей. Несмотря на, казалось бы, очевидную пользу такого подхода, сотрудники все равно сопротивляются насаждению новых инструментов. Еще чаще приходится сталкиваться с тем, что внедрение таких платформ саботируют внутренние разработчики, создающие «правильные» решения. Кроме того, в ходе дискуссии обсудили еще несколько актуальных вопросов. Как проще и правильнее проверить бизнес-гипотезу: по-быстрому «накодировать» или реализовать процесс в low-code? И уж если в компании случился low-code, то кто должен играть главенствующую роль для успеха работы: аналитики или разработчики?
Гражданские разработчики и ИТ-партизаны
«Low-code — это не только инструмент, но и средство изменения сознания. У айтишников и бизнеса головы работают принципиально по-разному: одни живут в пространстве векторов, объектов и свойств, а другие — в пространстве денег», — отметил Владимир Анисимов, директор по данным «Интер РАО-Онлайн». Перевод с одного языка на другой — наболевшая проблема, с которой сталкиваются почти все компании. Начиная жить в новом мире сложных конструкций, гражданские разработчики быстро приходят к пониманию того, что появление одной новой галочки в приложении может повлечь написание километров кода, то есть огромные доработки в унаследованных системах. Осознание принципов работы ИТ — очень важный результат усилий гражданского разработчика. До сих пор таких возможностей у бизнеса было мало.
.jpg) |
| Владимир Анисимов: «Осознание принципов работы ИТ — очень важный результат усилий гражданского разработчика. До сих пор таких возможностей у бизнеса было мало» |
Разумеется, есть и обратная сторона медали. Когда бизнес приходит с запросами к ИТ, то часто слышит, что сделать это невозможно, долго или дорого. Однако уже реализованное low-code-решение перевести в продуктив гораздо проще. Именно поэтому роль low-code в современном бизнесе будет только расти.
«Без сомнения, low-code очень хорош для быстрого решения проблем, когда требуется буквально за несколько дней из подручных средств собрать и запустить какой-либо продукт. И по мере своего взросления low-code будет занимать все большее место в создании приложений», — уверен Дмитрий Калаев, директор акселератора ФРИИ. Популярность low-code растет — это бесспорно, причем в крупном бизнесе гораздо больше возможностей для его использования. Конечно, он не подойдет для решения всех корпоративных задач, но его применение может стать полезным для значительного числа перспективных направлений.
«У любого сотрудника есть поток задач. И чтобы с ними справиться, ему нужны компетенции и доступный инструментарий. Человек всегда зажат между скоростью потока задач и интенсивностью его обработки», — считает Станислав Фридкин, руководитель управления товародвижения и планирования компании Sunlight. Low-code — один из инструментов, с помощью которых люди могут выстроить свой рабочий процесс. У специалистов появляется выбор: либо по-прежнему абсолютно непрозрачно работать в электронных таблицах, либо выстроить процесс и добиться его прозрачности, попутно сняв с себя часть рутины и сократив трудозатраты. Не менее важен и другой аспект: когда визуально выстроена последовательность из квадратиков со стрелочками, всегда можно без труда точно повторить процесс.
«Low-code был и раньше. Лет пятьдесят назад могло бы быть точно такое же обсуждение: айтишники, писавшие программы для больших ЭВМ на ассемблере, презирали Фортран, который являлся языком высокого уровня (то есть был low-code по сравнению с ассемблером) и давал ученым возможность быстро делать расчеты», — напомнил Леонид Головин, советник генерального директора по цифровой трансформации «Газпромтранса».
.jpg) |
| Леонид Головин: «Low-code был и раньше. Лет пятьдесят назад могло бы быть точно такое же обсуждение: айтишники, писавшие программы для больших ЭВМ на ассемблере, презирали Фортран, который являлся языком высокого уровня (то есть был low-code по сравнению с ассемблером) и давал ученым возможность быстро делать расчеты» |
По мнению Головина, для успешного развития подходов low-code компаниям нужен прогрессивный ИТ-директор, который правильно оценит место и роль такой платформы, выделит для нее песочницу в своей компании, договорится с «безопасниками», предоставит необходимые инструменты и мощности, проведет обучение и привлечет «партизан» — гражданских разработчиков, которые будут резвиться в песочнице. Лучшее из созданного ими может стать техническим заданием, на базе которого можно разрабатывать серьезные решения.
Возможно, ИТ-директор должен действовать в тандеме с директором по развитию или инновациям. Именно так можно обеспечить правильную работу с гражданскими разработчиками.
Впрочем, как предположил Фридкин, ИТ-директор может и не знать, над какими проблемами бьются эти партизаны и какими средствами пытаются их решить. Аналогия с партизанами возникает не случайно: зачастую пользователи вынуждены скрывать свои разработки, чтобы не получить по рукам. «Мне приходилось видеть такие ситуации не только в наших, но и в зарубежных компаниях. Попытки делать собственные инструменты воспринимаются как проявление агрессии по отношению к корпоративным системам и могут иметь дисциплинарные последствия», — рассказал Фридкин.
Между жадностью и страхом
Почему внутренние разработчики противостоят внедрению low-code? Они ведут себя как снобы или просто больше знают и поэтому настроены скептически?
«Low-code по идеологии ближе к микросервисной архитектуре. Но в большинстве компаний до сих пор используются монолиты. Встраивать в них доработанные кусочки всегда долго, дорого и трудно, потому что после доработки систему приходится тестировать полностью», — пояснил Анисимов. Именно это и вызывает основное сопротивление: как только создан работающий прототип и встает речь о его внедрении, у разработчиков появляется очередная головная боль. В компании с микросервисной архитектурой это воспринимается гораздо проще. Однако, по мнению Анисимова, другого пути нет. Low-code на данный момент является единственным способом быстрой проверки бизнес-гипотез.
Как считает Калаев, реакция некоторых программистов объяснима: они действительно боятся остаться без работы. Вторая причина — психологическая: автоматически сгенерированный код вполне может быть неоптимальным, в нем нет красоты и изящества. И даже если забыть про потребляемые ресурсы, профессионала это может бесить. Однако на бизнес такой аргумент совершенно не действует: человеко-час дороже, чем потребленные гигабайты.
.jpg) |
| Станислав Фридкин: «Рынок — это всегда баланс между жадностью и страхом. Неизвестность и страх потерять что-то, давшееся большим трудом, всегда будут создавать много проблем» |
Фридкин напомнил, что рынок — это всегда баланс между жадностью и страхом. Если экстраполировать такой подход на внутренний рынок компаний, где продаются и покупаются проекты, то неизвестность и страх потерять что-то, давшееся большим трудом, всегда будут создавать много проблем.
«Поспорю с тем, что настоящие программисты должны бояться лоукодеров. Скорее, лоукодеры должны бояться за себя», — заявил Головин. Еще два года назад нейросеть DALL-E, рисующая изображения по их текстовому описанию, казалась чем-то фантастическим. А сейчас таких систем уже много, и в результате дизайнеры начинают терять работу. Вполне вероятно, что через несколько лет введенной фразы с описанием желаемого результата будет достаточно для того, чтобы искусственный интеллект предложил готовый прототип системы. Бизнес-руководители будут аплодировать, и никакие гражданские разработчики уже не потребуются. Самым ценным сотрудником станет тот, кто знает, что ему нужно, и способен это сформулировать нормальным языком.
Обойтись без low-code?
«Сейчас почти все выпускники вузов и даже школьники знают Python и не горят желанием изучать другие варианты. У этого языка достаточно большие возможности, и проверить с его помощью гипотезу вполне возможно, даже если код не выдерживает критики», — утверждает Анисимов. Сторонники других языков относятся к Python практически как к low-code. По мнению Анисимова, сейчас сложилась неоднозначная ситуация. С одной стороны, подрастает поколение, владеющее настоящим языком программирования, и им инструменты low-code не слишком нужны. С другой стороны, для разработки на Python все равно требуется довольно большое время. Предлагая пользователям какой-либо инструмент, важно четко понимать их потребности.
«В скорости low-code точно выигрывает, но мы платим за это ограничением возможностей. По моим ощущениям, экономия времени составляет около 20–30%», — оценил Анисимов.
.jpg) |
| Дмитрий Калаев: «Исходя из моей практики, вручную можно проверить 80% гипотез. Еще 15% имеет смысл проверять с помощью low-code, а еще 5% — лишь полноценным программированием» |
Калаев уверен, что с точки зрения проверки бизнес-гипотез идеальный вариант — не программировать вовсе. Некоторые из гипотез можно проверить в буквальном смысле вручную: с ручкой и бумагой. «Исходя из моей практики, вручную можно проверить 80% гипотез. Еще 15% имеет смысл проверять с помощью low-code, а еще 5% — лишь полноценным программированием», — отметил Калаев. Конечно, проще всего пользоваться привычным инструментом, а подумать и понять, как решить задачу проще, — отдельный навык изобретателя.
Как утверждает Калаев, команда, проверяющая гипотезы, обходится в 15–20 млн руб. в год. В зависимости от ее навыков и вида гипотез, она может проверять одну гипотезу в год, квартал или даже неделю.
Фридкин также призывает осмотрительно подходить к выбору инструментов и не бросаться в гонку за модой. Люди как-то работали и до появления программирования как массового явления в нашей культуре и бизнес-практике. Если появилось много современных инструментов, это не означает, что задачи нужно решать именно с их помощью. Есть масса компаний, способных решать многие задачи с помощью «мозгового штурма» — почему бы им не пользоваться, особенно на начальных этапах проектов.
Каждому свой инструмент
«Применять low-code или нет, должен решать бизнес, который больше всего в нем заинтересован. У аналитиков все и так неплохо, у разработчиков — еще лучше. А вот у бизнеса голова болит всегда», — объяснил Анисимов. Именно бизнес диктует требования к проверке гипотез на цифрах, и у него нет времени вставать в очередь на проверку, чтобы узнать, работает очередная идея или нет. А прототип, разработанный на low-code, позволяет не только оценить эффективность, но и «пощупать» созданное решение — это главный плюс такого подхода.
«Когда приходят бизнес-заказчики и требуют реализовать какую-то функцию, разработчики и аналитики испытывают лишь психологический дискомфорт. У них есть свои задачи, а главное — они все равно получат свои деньги», — иронизирует Калаев. А для бизнеса разработка новых приложений — это вопрос выполнения годовых показателей эффективности и получения премий.
Головин согласился с тем, что low-code как инструмент прототипирования более востребован у людей, работающих в бизнес-подразделениях, чем у системных аналитиков и разработчиков. Более того, он уверен, что low-code для ИТ-служб — очевидное зло. «Это все равно что предложить компании, которая строит здание, использовать алебастровую замазку. У нее есть свои инструменты и свои регламенты. А замазка — это скорее для тех, кто создает рядом киоск быстрого питания, чтобы быстро решить проблему с едой для строителей», — сказал Головин.
В итоге дискуссии эксперты сошлись во мнении, что каждому необходим свой инструмент: бизнесу — платформы low-code, а айтишникам — «нормальные» средства разработки. На данном этапе подход low-code, так же как некоторое время назад Agile, позволяет небольшими шагами прийти к тому, чего хотят бизнес-пользователи. Именно поэтому он стал так популярен.
.jpg)
.jpg)
.jpg)
.jpg)
