2021 — год low-code. Как он спасает бизнесы в пандемию и превращает гуманитариев в программистов

Автор оригинала: Jenna Sargent, SD Times

Журнал SD Times назвал 2021 годом low-code и рассказал, почему программисты боятся этих решений, как low-code инструменты помогают бизнесу в пандемию, снимают нагрузку с IT-отделов и превращают обычного сотрудника в разработчика. Не обошлось и недостатков — такие системы подходят не всем компаниям. Предлагаем адаптированный перевод статьи на русский язык.

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

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

Со временем взгляды поменялись, и бизнес начал пользоваться этими сервисами. Разработчики и обычные сотрудники увидели, на что способны low-code инструменты.

Из-за пандемии офлайн-процессы очень быстро ушли в «цифру»

Все бы случилось через несколько лет, но вмешалась пандемия. Когда люди работают из дома, нельзя подойти к коллеге, посоветоваться или подписать бумагу. Вырос спрос на приложения, которые переносят офлайн-процессы в digital. Но с апреля 2020 low-code-платформы растут вдвое быстрее.

Агентство Gartner считает, что к 2023 году 50% средних и крупных компаний будут делать на low-code стратегически важные приложения.

Лоукодером может стать любой, но некоторым легче

Благодаря low-code-платформам, делать приложения может каждый. Для этого не нужно становиться Java- или NET-разработчиком. Любой сотрудник сможет принести пользу и делать ПО для своей компании. Причем некоторым специалистам будет проще стать лоукодером. Это легко сделает инженер со знанием 3D-моделирования или финансист, который хорошо знает Excel и может создавать макросы.

Мы уже рассказывали, как бывший руководитель SMM-агентства Евгений Спорыхин сделал «Тильду для ресторанов», используя платформу Bubble

Внедрять такие решения лучше с автоматизации таблиц. Например, есть Excel-файл с расходами, куда вся команда собирает данные. Руководитель отправляет всем таблицу, сотрудники заполняют и высылают обратно, а потом кто-то вручную объединяет все файлы в один — это легко упростить. Хватит несложного приложения — останется ввести в него расходы и получить на выходе готовый отчет. Google Таблицы легко связать с тем же Integromat.

На Западе сотрудников учат работать с low-code

В первую очередь обучают основам — базам данных и дизайн-мышлению. С первым обычно больше всего проблем. Неподготовленный человек сделает таблицу с 1000 столбцами, а потом будет их заполнять. Решение рабочее, но занимает много времени, к тому же его нельзя масштабировать. Зато, когда человек знает основы, он может использовать low-code-платформу на 100%.

Лоукодеры могут применить экспертизу, которой нет у обычных разработчиков. Вместо того чтобы ставить задачу IT-команде, маркетологи, менеджеры, аналитики и другие специалисты могут сделать приложение сами.

Low-code-платформы спасают, когда IT-отдел перегружен

Бывает, что маркетологи или менеджеры по продажам просят развернуть новый трекер задач или CRM. А технари против — у них нет времени возиться и поддерживать новую систему.

Но если классические программисты не дают командам нужные инструменты, они соберут их в каком-нибудь конструкторе. В итоге получится система, которую сложно поддерживать и масштабировать. Будут проблемы с безопасностью данных.

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

Разработка стала в разы быстрее и дешевле

Компании из списка Fortune 500 понадобилось приложение. Она попросила свой IT-отдел оценить, во сколько обойдется его разработка.

Программисты оценили задачу и ответили, что нужно 9 месяцев и 170 тыс. $, а low-code-специалист собрал все в конструкторе за 6 недель и 25 тыс. $. 

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

У low-code тоже есть недостатки

Эти платформы не идеальны, и поэтому не избавляют от всех проблем. Одни решения подходят только корпорациям, другие — маленьким командам. Иногда собранное приложение работает нормально, но его трудно тестировать.

У low-code два основных недостатка:

  1. Компания может «перерасти» платформу. Часто сценарии использования превосходят возможности решения. Оно может хорошо работать, пока им пользуются десять человек. Но когда клиентов сотни тысяч, все может тормозить.

  2. Визуальный интерфейс труднее тестировать. У большинства сервисов визуальная среда разработки. С ней проще, но не всегда понятно, почему приложение сломалось. Обычный код — просто текст, и легко узнать, что в нем изменилось. В визуальной среде с этим труднее.

Зерокодерские платформы не решают все проблемы. Даже если создатели сервиса говорят, что он масштабируется бесконечно и у него продвинутый контроль версий, обязательно будет предел. Все ограничения важно знать до внедрения платформы в компании.

Также мы уже рассматривали недостатки low- и no- code-платформ на примере Bubble

Low-code — это тренд обычных платформ

В программах для крупных компаний появляется все больше low-code-инструментов. Например, только в Power Platform от Microsoft таких четыре:

  • Power BI для аналитики и визуализации данных;

  • конструктор приложений Power Apps;

  • Power Automate для автоматизации работы;

  • Power Virtual Agents для чат-ботов.

Если в решении есть low-code-возможности, оно становится гибче. Пандемия показала, что бизнес отказался от ПО, которым пользовался годами. Чем сильнее бизнес связан с IT, тем больше его сотрудникам нужны low-code-приложения. Компании, которые это понимают, смогут быстро адаптировать свое ПО к любым изменениям.

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

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

Средняя зарплата в IT

120 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 7 122 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 35

    +20
    Не справляются менеджеры с зерокодингом, это обман. Потому что нужно то же самое понимание структур и алгоритмов, без технического бекграунда не потянуть. Они крестик на 1С закрыть не могут, вы от них зерокодинг хотите? Маркетинговое фуфло!
      +1
      >Не справляются менеджеры с зерокодингом, это обман.
      Да тут почти все обман. Ну так, условный но реальный пример — нужно интегрироваться с (внешним) REST-сервисом. Для настоящего программиста задача вполне рутинная, которую многие решали уже в жизни раз по сто.

      А тут будет одно из двух — либо этот «менеджер» прочитал документацию и книжки, и реально понимает, для чего нужны методы в HTTP, и что означают статусы, и когда нужно применять GET, а когда POST. И если он это сделал — он правда стал немного программистом. Но сделали его таким чтение книжек и документации, а не какой-то там мифический инструмент low-code. А если он не прочитал — то скажем тривиальную аутентификацию, даже BASIC, он никогда не сделает.
        0
        Справедливости ради не очень удачный пример, инструменты для работы с данными часто из коробки умеют в rest. Другое дело, на том же питоне съедать такой запрос заметно проще.
          0
          А как они узнают, какой метод нужно? Волшебным образом догадываются?
            0
            Ну если «технари» нормально документацию сделали, то в документации по работе с данными.
            Вообще странный вопрос, адрес rest сервиса, это какая-то особая магия который, обычные смертные обладать не могут?
            Другое дело, что дергать rest из того, же excel или powerBI, имхо навыков нужно больше( где что нажат ), чем дернуть его из python или любого другого скриптового языка, но знаний программирования для этого не надо.
              0
              >Ну если «технари» нормально документацию сделали
              Сколько я этих интеграций писал, наверное сотни. И примерно лишь в 10% документация как следует описывала сервисы. Почему? Да потому что она имеет свойство устаревать. Это ее естественное состояние, в общем-то.

              Кроме того, вот смотрите, вы написали адрес, а я писал метод. Т.е. POST или скажем PUT. И откуда вы его узнаете, если вы не понимаете ничего в HTTP, и вам эти названия ничегошеньки не говорят? Откуда вы знаете, какие заголовки нужно, если вы снова не знаете о HTTP, и вообще не понимаете, что это такое? Я готов согласиться, что понимание протокола это не навыки программирования, но прямо скажем — это не сильно отличается.

              Для ясности — я просто привел REST как очевидный пример, они реально часто поддерживаются инструментом — но даже в таком инструменте у меня были проблемы. Скажем, инструмент умеет SOAP — но только в одном из форматов документа, а их два. Или умеет только BASIC аутентификацию, и не умеет SPNEGO (а попробуйте для начала найти живого программиста, который бы помнил все детали реализации SPNEGO :).

              Ну и опять же — если вы не программист, вы не сможете понять, что вам нужно, если вы не вникните, не прочтете документацию, и т.п. — то есть не сделаете все тоже, что сделает обычный программист, вникая в подобную задачу. И как только вы это сделаете — вы решите задачу, но вы перестанете быть каким-то специальным low-code программистом, а станете нормальным, который читает документацию и изучает новые для себя технологии в каждом проекте.
        0
        Так менеджерам это и не нужно! Я уже встречал тильда-программистов и их работу.
        Недавно знакомая поросила к сайту на тильде Страйп прикрутить (там просто нужно в два поля ключи вставить, чтобы понимали скоуп работы). Так вот это сначала делал тильда-программист, но осилил не все. Он смог сайт из готового темплейта запустить и контент загрузить, даже аккаунт в Страйпе создать смог, но вот что-такое ключи доступа к АПИ уже не смог осилить.

        Для малого бизнеса low/zero code самое то. Ведь будем честными, малый бизнес очень редко может вырасти, я бы даже сказал, что почти никогда. У них и денег нет программиста нанять, да и задачи там типовые и уже решенные по 1000 раз.

        А так как рынок и спрос есть, вот и появились Зерокодеры, ну и пусть будут.
        +6
        Дело хорошее, но какой-то нездоровый хайп — сервисы и есть сервисы, теперь еще учать быть программистом по интеграции сервисов.

        Но в реальности не менеджер без программиста это интегрирует, а программиста просят это все настроить. То есть ему надо еще и эти инструменты знать
          +8

          Какие-то у них не те недостатки low-code. Намного важнее огромная сложность доработки и поддержки таких решений.

            0
            Сложность? Я б сказал скорее невозможность.
              +1

              Ха, нет ничего невозможного в разгребании 10 тыс строк лапшевидного кода без документации. Но времени и мыслительных усилий это потребует ой как много.

            0

            Если вы Кока-Кола или WAG можете смело ставить себе такие системы

              +4
              В первую очередь обучают основам — базам данных и дизайн-мышлению.

              Такс, такс, такс, что тут у нас миллениалы изобрели на этот раз? Ага, точно, Excel и Access.
                0
                Когда для excel гораздо удобнее писать на питоне или руби
                  0
                  Как то работал на проекте, где часть софта была в excel, с кучей макросов и коде на бейсике. И все это понимал один человек, который это накликал, как в примере за несколько дней. Это понравилось менеджерам, а что не надо платить много денег программистам. Начали вливать в человека кучу денег. В результате у человека случился burn out, а кроме него никто не понимал, что там внутри. 15 человек как бараны смотрели на это. И желали крепкого здоровья автору.
                  +1
                  О да!
                  Power BI — это же такой no code, никому не надо знать эзотерический M или хотя бы DAX!
                  А чтобы поправить виджет под нужды, нужно поставить тулчейн и собирать TS код, сильно отличающийся от браузерного.
                  Power BI прекрасен, но python проще реализует «хотелки» заказчиков.
                    0
                    А JS еще и нарисует интерфейс в каждом утюге браузере
                    –2

                    Не надо нам гуманитариев, спасибо

                      0

                      … ммм, как человек с высшим гуманитарным образованием, хотел бы поинтересоваться, где конкретно не надо гуманитариев, и почему?

                        0

                        В программировании не надо. Потому что как правило, плохо с логикой

                          0

                          "Плохо" в значении "хуже определенного уровня" или в значении "хуже, чем у какой-то другой группы"?


                          Вообще, конечно, занятно: большую часть своей истории логика изучалась с гуманитарными дисциплинами, но при этом у людей, занимающихся этими самими дисциплинами, "плохо с логикой"?

                            –2

                            Хуже чем у сферического технаря в вакууме


                            Логика давно не гуманитарная дисциплина. Теорема Баеса, теорема Геделя, парадокс Скулема, недостижимые мощности и реверсивная математика...

                              0
                              Хуже чем у сферического технаря в вакууме

                              А на основании какого повторяемого эксперимента вы делаете это утверждение?


                              Логика давно не гуманитарная дисциплина. Теорема Баеса

                              Теорема Байеса разве не из теории вероятностей?


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


                              И сколько из сферических программистов в вакууме эти, гм, понятия знает, понимает, и умеет использовать?

                                0
                                Теорема Байеса помогает не попадать в логические ловушки. Вы читали о вреде огурцов?

                                Выводы на основании личного опыта.
                                  0
                                  Теорема Байеса помогает не попадать в логические ловушки.

                                  Является ли знание теоремы Байеса необходимым условием, чтобы не попадать в логические ловушки? Является ли знание теоремы Байеса необходимым, чтобы работать в прикладном программировании?


                                  Выводы на основании личного опыта.

                                  Это, конечно, очень достоверная и полезная информация.

                                    +1
                                    А вот вы как раз попали в логическую ловушку. Тип образования в общем случае слабо коррелирует с умением в логику. А если уж и есть корреляция, то не в разрезе точные vs гуманитарные науки.
                                    0
                                    Ну, понимать Геделя нужно не столько для практической работы, сколько для того, чтобы не пытаться решать некоторые нерешаемые задачи. Но строго говоря, я не вижу никаких причин, почему бы гуманитарию не понимать теорему Геделя, скажем прочитав «Гедель, Эшер, Бах». Никакого рокет сайнса особого тут нет. И доказывать ее уметь не нужно (хотя и доказательство в общем понять тоже можно).

                                    >логика изучалась с гуманитарными дисциплинами
                                    А кстати, поясните как технарю, это какого сорта логика? Ну т.е. что за учебники, что за законы? Входит ли в изучаемое что-то типа законов Де Моргана, ну т.е. логика как часть именно математики?

                                    >И сколько из сферических программистов в вакууме эти, гм, понятия знает, понимает, и умеет использовать?
                                    Я бы по своему чисто прикладному окружению сказал бы, что таких не очень много.
                                      0
                                      А кстати, поясните как технарю, это какого сорта логика?

                                      Всех сортов.


                                      "Далее в течение почти двух с половиной тысячелетий до второй половины 19 века логика изучалась как часть философии и риторики. "


                                      (https://ru.wikipedia.org/wiki/%D0%9B%D0%BE%D0%B3%D0%B8%D0%BA%D0%B0)

                                        0
                                        Так все же, как выглядит учебник логики для гуманитариев? Наверняка же в сети уже все давно есть.
                                          0

                                          Я вам честно скажу: у меня логики как отдельной дисциплины не было. Была в курсе философии, была в (дополнительном) курсе риторики, но больше всего ее было в написании и защите своих и рецензировании и оппонировании чужим курсовым и дипломным работам. Так что я не могу вам ничего сказать про учебник логики про гуманитариев.

                          0
                          Мы уже рассказывали, как бывший руководитель SMM-агентства Евгений Спорыхин сделал «Тильду для ресторанов», используя платформу Bubble

                          Где работает в реальности этот продукт. Как посмотреть в живой природе? Какие компании используют?

                            0

                            Достаточно посмотреть на обычную Тильду, чтобы понять ограниченность лоу-кода.


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

                            +6

                            Понравилось про программистов, которые оценили разработку в несколько раз выше low-code решения, и про то, как программисты "не воспринимают low-code, потому что боятся потерять работу".


                            Разве стал бы специалист (любой области) отказываться от инструмента, если он позволяет выполнять ту же работу эффективнее? Я сам порой для некоторых "на коленке" проектов использовал bubble, а для других часами искал подходящие сервисы в надежде сделать проект меньшими усилиями. Но на практике часто уже на этапе знакомства с платформой видишь, что проект в неё в итоге не впишется. И с bubble такая же история: можно быстро сделать прототип, но чем дальше развиваешь, тем понятнее, что нужно быстрее с него слезать и делать "классическое" решение. (Хотя, конечно, там, где дальше прототипа дело не пошло и функционал прототипа простой — время экономится.)


                            Отсюда и оценка в IT-отделе в несколько раз выше: вероятно, специалисты сразу видят детали проекта и потенциальные узкие места чуть дальше и глубже и закладывают это в оценку. Есть вероятность, что в итоге придётся сделанное за 25к переписывать, вложив ещё 170к, заложенные IT-отделом. Наконец, странно, что это всё происходит внутри одной компании, и никто не попытался выяснить (по крайней мере в статье не рассказано), как же так получилось-то, что сотрудники другого отдела могут сделать то же самое и в несколько раз дешевле, чем их же IT? Тут много чего можно быть же. Либо есть проблемы в HR — люди не на своих местах и нужно тех ребят переместить в IT, раз они так круто делают ПО. Либо более дешёвое решение имеет какие-то недостатки — и тогда неплохо бы обсудить их и соотнести с планами и приоритетами бизнеса. Либо есть проблема в проджект менеджменте — не было человека, который бы состыковал видение программистов и пользователей, они друг друга не поняли, и программисты оценивали более сложную задачу, чем реально нужно было пользователям. А вместо всего этого поверхностно показывается: смотрите, как дёшев low-code, и вот какие нехорошие программисты.

                              +5
                              Опять эта хрень про lowcode. На ресурсе, где большинство — кодеры. Это как приходить штурмовать ворота древнего города с воротами от другого города.
                              Для этих генераторов есть своя ниша, но она не здесь. Пожалуйста, перестаньте, додо пицца и то успокоилась вроде.
                                0
                                А что, закономерный результат победы бизнеса над технологиями.

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое