Введение

В частях 1 и 2 мы увидели, как EUC и «God Excel» спасали рабочие места в краткосрочной перспективе, но оставляли организации отрицательное наследие в долгосрочной. В этой статье мы переносим взгляд в настоящее и разбираем свет и тень, которые несут современные платформы гражданской разработки вроде RPA и no-code/low-code.

Они повторяют сюжет God Excel и одновременно несут ещё большие риски по масштабу и степени зависимости. Прежде чем в следующей части обсуждать влияние генеративного ИИ, важно правильно понять их природу.

Вся серия

Свет — почему эти платформы приняли

Мгновенный эффект

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

Убедительная сила наглядности

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

Первый шаг гражданских разработчиков

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

Тень (1) — «профессиональный барьер» в реальной работе

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

  • Неизбежность управляющих конструкций Чтобы разделять обработку по условиям клиента, нужны ветвления (If/Else). Для работы со сотнями записей не обойтись без циклов (ForEach). Чтобы подготовиться к задержкам и ошибкам внешних систем, требуется обработка исключений (Try/Catch). Всё это лишь вынесено в элементы GUI, но по сути остаётся программированием.

  • Понимание структур данных Приходится разворачивать JSON или массивы, сопоставлять иерархии, приводить форматы дат и чисел — без этого невозможно интегрировать бизнес-процессы. Простая замена таблицей не работает: не понимая структуру данных, система рушится.

  • Сложность интеграции систем Нужно управлять сроком действия токенов API, обеспечивать целостность между несколькими системами, обходить ограничения по количеству запросов — это ровно те же задачи, что и в классической инженерии ПО. GUI лишь скрывает их, а уровень сложности может быть даже выше.

  • Требования к эксплуатации и качеству Без продуманного мониторинга, сбора логов, управления расхождениями между тестовой и боевой средой и планов отката релизов быстро наступает хаос. Поскольку код не хранится в версиях, наблюдаемость снижается.

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

Тень (2) — вендор-локин и трудности переноса

У God Excel ещё оставалась надежда: это ведь всего один файл. Табличные данные можно выгрузить в CSV, а хотя функции и макросы и привязаны к Excel, существовали пакеты с частичной совместимостью, да и код можно было разобрать. С RPA и no-code/low-code результат почти всегда оказывается заперт в специфических UI и конфигурациях конкретной платформы.

  • Переход на продукт другого вендора фактически равносилен «переделке с нуля».
  • Завершение работы SaaS-сервиса или изменение его спецификации не зависит от пользователя и способно за одну ночь обесценить накопленные активы.
  • При разработке на PaaS экосистема облака приковывает пользователя, и вынести решение в другую среду крайне сложно.
  • Когда логика задана через UI, а не код, проблемные места трудно найти и исследовать.
  • В ряде инструментов, чтобы увидеть внутреннюю обработку, нужно, например, дважды щёлкнуть по блоку, что дополнительно ухудшает читаемость.

По сравнению с God Excel, где всё ограничивалось таблицей, зависимость и риск превращения в долг возрастают на порядок.

Тень (3) — «погрешность на наглядность», которая обманывает руководство

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

Почему так происходит? Для руководства системы обычно — чёрные ящики, и стоит показать процессы, связанные стрелками, или выстроенные формы ввода, как им кажется, что они поняли внутреннюю сложность. Однако за кулисами работают те же управляющие конструкции и обработка ошибок, что и в программах; без инженерных знаний не получится сделать решение пригодным для практического применения.

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

Эпоха God Excel 2.0

Если взглянуть шире, RPA и no-code/low-code повторяют траекторию God Excel. Они быстро спасают операционные процессы, убеждают руководство визуализациями и в итоге оставляют организации тяжёлый груз из-за закрытости и персонификации знаний.

Но есть ключевое отличие — масштаб влияния. God Excel завершался на уровне отдельных файлов, а современная гражданская разработка пронизывает облако и бизнес-ядро, превращаясь в долг, опутывающий всю организацию. И что хуже, структура локина здесь даже жёстче, чем у Excel. Всё это ведёт к сценарию, который впору назвать «God Excel 2.0».

Выводы

  • RPA и no-code/low-code были приняты благодаря мгновенному эффекту и наглядности, убедившим и рабочие команды, и руководство.
  • Но чтобы выдержать реальную эксплуатацию, необходимы знания инженерии ПО — управляющие конструкции, структуры данных, интеграция систем, проектирование эксплуатации — и гражданские разработчики не могут поддерживать всё это в одиночку.
  • Платформенные UI делают миграцию чрезвычайно сложной и усиливают вендор-локин.
  • «Погрешность на наглядность» на уровне руководства заставляет недооценивать эти риски.

В итоге современная гражданская разработка столь же мощна, как God Excel, но на самом деле ещё опаснее. В следующей части мы разберём, что произойдёт, когда к этой картине добавится генеративный ИИ.

Следующая часть: Как генеративный ИИ влияет на гражданскую разработку 4/7