Почему создавать программы могут не только инженеры: тренды

Почему вопрос «кто делает софт» стал актуальным

Ещё недавно ответ на вопрос «кто делает софт?» звучал почти автоматически: инженеры, разработчики, ИТ‑отдел. Сегодня это уже не так однозначно: в компаниях резко выросла потребность в небольших цифровых решениях, а инструменты для их создания стали доступнее.

Как изменилось понимание «кто может создавать программы»

Появился слой людей, которые отлично знают бизнес‑процессы (продажи, HR, финансы, операционный блок) и при этом способны самостоятельно собрать рабочий инструмент: форму, простое приложение, отчётность, автоматизацию рутины. Их часто называют «гражданскими разработчиками» — не потому что они пишут сложный код, а потому что создают полезные решения без классической инженерной подготовки.

Почему спрос на внутренние инструменты растёт быстрее ИТ‑ресурсов

У компаний множатся задачи «внутри»: согласования, заявки, учёт, статусы, напоминания, интеграции между сервисами. Каждая команда хочет немного «подстроить систему под себя», а ИТ‑отдел физически не успевает делать десятки мелких запросов параллельно с крупными проектами. В итоге бизнес либо ждёт месяцами, либо начинает обходиться «табличками и чатами», теряя качество и управляемость.

Что мы называем «созданием софта»

В рамках этой статьи под созданием софта будем понимать не только полноценные продукты, но и:

• внутренние приложения (каталог заявок, мини‑CRM, база знаний);
• автоматизации процессов (триггеры, уведомления, маршруты согласований);
• интеграции и связки между сервисами (передача данных, синхронизация статусов).

Где граница между «сборкой» и инженерной разработкой

Если решение собирается из готовых блоков, работает в рамках платформы и опирается на стандартные интеграции — это скорее «сборка». Когда требуется сложная логика, высокая нагрузка, нестандартные требования безопасности, глубокая интеграция с внутренними системами или долгий жизненный цикл — это уже зона инженерной разработки и ответственности ИТ.

Что подтолкнуло софт выйти за пределы инженерных команд

Бизнесу нужно всё больше «малого софта» — не огромных платформ, а десятков прикладных решений, которые поддерживают ежедневную работу. Это отчёты и витрины данных, формы в CRM, внутренние заявки и согласования, простые каталоги, чек‑листы, мини‑порталы для команд. Каждое такое решение экономит время, но вместе они превращаются в постоянный поток запросов.

Объём задач растёт быстрее, чем пропускная способность ИТ

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

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

Изменения в процессах происходят чаще

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

Цена задержек слишком заметна

Когда нужного инструмента нет, люди закрывают задачи вручную: копируют данные между таблицами, пересылают письма, ведут статусы в чатах. Это приводит к типичным потерям:

• лишние часы рутины и высокая стоимость ручного труда;
• ошибки из‑за человеческого фактора и несогласованных версий данных;
• упущенные возможности — от сорванных сроков до недополученной выручки.

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

No-code и low-code: что это и какие задачи они закрывают

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

No-code: собрать из готовых блоков

No-code — это «сборка из кубиков» без написания кода. Вы выбираете экранные элементы (поля, кнопки, таблицы), настраиваете правила, подключаете источники данных и получаете работающий результат.

Чаще всего на no-code делают:

• формы для заявок и согласований;
• внутренние порталы и базы знаний;
• простые мобильные приложения для сотрудников;
• чат‑боты для типовых вопросов;
• автоматизации процессов (например, передать заявку из формы в таблицу и отправить уведомление).

Low-code: когда нужно чуть больше гибкости

Low-code похож на no-code, но допускает «немного программирования», чтобы расширять возможности: добавить нестандартное правило, обработать данные, написать скрипт для интеграции. Это полезно, когда бизнес‑логика чуть сложнее, чем позволяют стандартные настройки, но полноценная разработка всё ещё избыточна.

Где заканчиваются возможности

Важно понимать ограничения — они не «плохие», просто задают границы применения.

• Нестандартная логика. Если правила сильно ветвятся, много исключений или сложные расчёты, визуальных настроек может не хватить.
• Масштабирование. При росте нагрузки, объёма данных и числа пользователей может потребоваться более «инженерная» архитектура.
• Безопасность и требования. Для систем с чувствительными данными, сложными правами доступа, аудитом и соответствием регуляторике часто нужны дополнительные меры и участие специалистов.

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

ИИ‑инструменты как новый «усилитель» для неинженеров

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

Характерный сдвиг последних лет — появление формата «vibe‑coding»: когда вы описываете, что нужно сделать, а система помогает собрать приложение через диалог. Например, TakProsto.AI как раз про такой сценарий: вы в чате описываете процесс (заявка → согласование → уведомления → отчёт), а платформа помогает собрать веб‑интерфейс и серверную часть, а при необходимости — и мобильное приложение.

Что ИИ умеет делать в формате черновика

На практике ИИ чаще всего полезен в подготовительной работе:

• набросать структуру интерфейса (что где разместить, какие поля нужны);
• предложить тексты для кнопок, подсказок, писем и уведомлений;
• составить SQL‑запрос под описанную выборку («выгрузи клиентов, у кого не было покупок 90 дней»);
• предложить простую логику правил: проверки полей, маршрутизацию заявок, расчётные формулы.

Важно относиться к этому как к «первой версии», которую всё равно нужно проверить и адаптировать под ваш процесс.

ИИ как помощник, а не автопилот

Сильная сторона ИИ — диалог. Он может объяснить, что делает формула или запрос, предложить альтернативы, подсказать, где потенциальная ошибка, и помочь упростить сложное требование. Для неинженеров это особенно ценно: меньше «магии», больше понимания.

Где обязательна проверка человеком

Есть зоны, где доверять генерации вслепую нельзя: права доступа и роли, работа с персональными данными, обработка «крайних случаев» (пустые значения, дубликаты, нестандартные статусы), а также всё, что может повлиять на деньги и отчётность.

Практика безопасного использования

Два правила дают максимум эффекта: не отправляйте в ИИ секреты (ключи API, пароли, выгрузки с персональными данными) и фиксируйте требования письменно — что именно должно быть на входе/выходе, какие ограничения и кто утверждает результат.

Дополнительный плюс, когда платформа работает в российской инфраструктуре и не отправляет данные за пределы страны. TakProsto.AI, например, запускается на серверах в России и использует локализованные (в том числе открытые) модели — это удобно для компаний, где важны требования по хранению и обработке данных.

API, интеграции и автоматизации: собрать цепочку стало проще

Ещё недавно, чтобы «подружить» два сервиса, почти всегда требовались разработчики: поднять сервер, написать обработчики, разобраться с форматами данных. Сейчас API всё чаще воспринимается как конструктор: сервисы заранее дают понятные «детали» (методы), а пользователи соединяют их через готовые интеграции и автоматизации.

API как конструктор без глубокого программирования

Если у продукта есть API, это значит: у него предусмотрены стандартные способы получать данные и отправлять их обратно. No-code/low-code платформы прячут сложные технические детали и дают визуальные блоки вроде «Создать сделку в CRM», «Записать строку в таблицу», «Отправить письмо». По сути вы собираете цепочку действий, а платформа сама выполняет запросы к API.

Типовые интеграции, которые реально закрывают задачи

Чаще всего автоматизации строятся вокруг повседневных инструментов:

• таблицы и базы (как «единый список» заявок или клиентов);
• почта и календарь (уведомления, напоминания, согласования);
• мессенджеры (оповещения в рабочие чаты);
• CRM и поддержка (лиды, тикеты, статусы);
• биллинг и платежи (счета, акты, статусы оплат);
• аналитика (передача событий и результатов кампаний).

События и вебхуки простыми словами

Многие цепочки запускаются не «по расписанию», а по событию. Вебхук — это способ сказать: «Когда у меня произошло X, отправь сообщение по указанному адресу». Например: оплатили счёт → сервис платежей отправил вебхук → сценарий создал запись в CRM и уведомил команду.

Важные риски: токены, лимиты, стабильность

У интеграций есть слабые места, о которых полезно знать заранее.

Во‑первых, токены доступа: их нельзя хранить в открытых таблицах или пересылать в чат — это фактически ключ к данным.

Во‑вторых, лимиты API: при большом потоке операций сценарий может «упереться» в ограничения и начать пропускать запросы.

В‑третьих, зависимость от сторонних сервисов: изменения в API, сбои или отключения могут ломать цепочку, поэтому стоит предусмотреть уведомления об ошибках и простой план «что делаем, если интеграция упала».

Почему знания и инструменты стали доступнее

Ещё недавно «вход» в создание программ выглядел как длинная дорога: книги, абстрактная теория, настройка окружения, годы практики. Сейчас путь короче и понятнее, потому что вокруг появилось много «подсказок» — от обучающих форматов до готовых строительных блоков.

Снижение барьеров обучения

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

Отдельно ускоряют старт шаблоны (проектов, процессов, дашбордов), которые можно взять за основу и адаптировать под свою задачу.

Командная работа стала нормой

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

Переиспользование вместо изобретения заново

Готовые компоненты, маркетплейсы расширений и шаблоны процессов экономят время и снижают риск ошибок. Это похоже на конструктор: вы комбинируете проверенные элементы, а не создаёте всё с нуля.

Внутренние сообщества и гайды

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

Плюсы: скорость, автономность и ближе к потребностям бизнеса

Когда создавать решения могут не только инженеры, выигрывает прежде всего бизнес: задачи решаются там, где они возникают, и быстрее превращаются в понятные изменения в процессе.

Скорость: быстрые проверки вместо долгих циклов

Главный эффект — быстрые прототипы. Команда продаж, HR или операционный отдел могут собрать рабочий «черновик» (форму, мини‑приложение, автоматизацию) и за несколько дней проверить гипотезу: нужна ли функция, где пользователи «спотыкаются», какие поля лишние.

Это снижает риск вложиться в «продакшн‑разработку», а потом выяснить, что реальная потребность другая. В итоге ИТ подключается точнее: не к туманной идее, а к проверенному сценарию с понятными требованиями.

Автономность: меньше очередей и согласований

Децентрализация снимает нагрузку с ИТ‑бэклога: отделы решают локальные задачи без ожидания «свободного окна» у разработчиков. Часто это небольшие улучшения, которые критично важны для команды, но в общей очереди выглядят мелкими.

Автономность также помогает стандартизировать работу: вместо «письма на почту и таблички в чате» появляется единый путь заявки и обработки.

Меньше рутины: автоматизация процессов на месте

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

Прозрачность: процесс видно и можно измерять

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

Риски: безопасность, качество и «теневая ИТ»

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

«Теневая ИТ»: когда решения есть, а владельца — нет

Самый частый сценарий: кто-то собрал удобную автоматизацию для своего отдела, она стала критичной, автор ушёл в отпуск (или из компании), и никто не понимает, где настроено, что к чему подключено и кто должен это поддерживать.

«Теневая ИТ» опасна не самим фактом самостоятельной разработки, а отсутствием владельца, документации, мониторинга и понятного процесса изменений.

Качество данных: дубли, разные справочники, отсутствие проверок

No-code/low-code инструменты часто стартуют с простых форм и таблиц — и быстро превращаются в «локальную CRM» или «мини‑склад». Без единых справочников и валидаций появляются:

• дубли клиентов и сделок;
• разные статусы и поля в разных отделах;
• ручные правки «на лету», которые ломают отчёты.

В результате цифры расходятся, а решения принимаются на основе несовместимых данных.

Безопасность: доступы «по ссылке» и утечки через интеграции

Упрощённый доступ — сильная сторона гражданской разработки, но и источник рисков: публичные ссылки, слабые пароли, общие аккаунты, лишние права у сотрудников.

Отдельная зона риска — интеграции и токены: один неправильно настроенный коннектор может открыть данные внешним системам, а незаметный сценарий — отправлять персональные сведения не туда.

Технический долг: цепочки автоматизаций без карты и правил

Автоматизации редко остаются «одной кнопкой». Со временем появляется цепочка из триггеров, вебхуков, таблиц и уведомлений. Без документации и тестирования она становится хрупкой: любое изменение поля или статуса ломает процесс, а поиск причины занимает часы.

Хорошая новость: эти риски можно снизить не запретами, а правилами — и дальше как раз о них.

Как выстроить управление: правила и «ограждения» вместо запретов

Запреты на no-code/low-code и самодельные автоматизации почти всегда приводят к обходным путям: файлам «на коленке», неучтённым ботам и хаотичным интеграциям. Рабочая стратегия — признать гражданскую разработку и поставить понятные «ограждения»: что можно делать, где границы ответственности и как проверять риски.

1) Классификация решений: что можно без инженеров

Разделите инициативы по уровню риска.

• Зелёная зона: прототипы, внутренние дашборды без персональных данных, простые уведомления, автоматизация рутины в пределах одного отдела.
• Жёлтая зона: интеграции между системами, обработка клиентских данных, любые процессы, влияющие на деньги/сроки/контракты — допускаются, но по правилам.
• Красная зона: платежи, критичные сервисы, публичные приложения, хранение чувствительных данных — только через инженерные команды и формальный проект.

2) Правила доступа: роли и контроль изменений

Зафиксируйте роли (создатель, владелец процесса, ревьюер ИТ/ИБ) и применяйте принцип минимальных прав: доступ к данным и API — только необходимый. Обязательны аудит изменений (кто и что поменял) и возможность быстро отключить решение.

3) Стандарты: чтобы решения были поддерживаемыми

Даже в no-code нужны минимальные стандарты: именование объектов и потоков, где хранится документация, правила работы с данными (что можно выгружать, как обезличивать), резервное копирование и журналирование ключевых действий. Это снижает зависимость от одного автора.

Если платформа поддерживает «снимки» и откат, пользоваться этим стоит с самого начала: любой быстрый конструктор рано или поздно упирается в человеческий фактор. В TakProsto.AI, например, есть snapshots и rollback — полезная страховка для команд, которые часто меняют процессы и не хотят «сломать» рабочее решение одним правком.

4) Процесс согласования: чек‑лист вместо бюрократии

Сделайте два маршрута:

• Быстрый: чек‑лист (данные, доступы, владелец, план отката) — достаточно для «зелёной зоны».
• Расширенный: обзор ИБ/ИТ и архитектурная консультация — обязателен для «жёлтой/красной зоны».

Так вы сохраняете скорость и при этом не теряете контроль.

Практика: как неинженеру создавать надёжные решения

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

1) ТЗ на одну страницу

Сформулируйте короткий документ, который можно перечитать за 2 минуты:

• Цель: какую проблему решаем и что перестанет болеть.
• Пользователи: кто будет вводить данные, кто — проверять, кто — смотреть отчёты.
• Данные: откуда берутся, где хранятся, кому доступны.
• Метрики успеха: например, «время обработки заявки −30%» или «ошибки в реквизитах < 1%».

Такое ТЗ защищает от бесконечных «добавим ещё одно поле» и помогает согласовать ожидания.

2) Проектирование данных (самое важное)

Даже в простом приложении заранее решите:

• какие поля обязательны (без них запись не создаётся);
• какие значения должны выбираться из справочников (статусы, типы, причины);
• где нужна уникальность (номер заявки, ИНН, e‑mail), чтобы не плодить дубликаты.

Если данные спроектированы аккуратно, отчёты и интеграции будут работать предсказуемо.

3) Тестирование без сложностей

Проверьте решение сценариями из реальной жизни:

• «обычный» путь пользователя;
• крайние случаи: пустые поля, длинные значения, дубликаты, отмена операции;
• права доступа: кто видит персональные данные, кто может удалять, кто — менять статусы.

4) Документация, которая спасает

Сделайте короткий файл (хотя бы в wiki):

• владелец (кто принимает изменения и отвечает за результат);
• инструкция для пользователей и администраторов;
• карта интеграций: какие API/коннекторы подключены, какие ключи и где хранятся;
• план изменений: как вносить правки, кто тестирует и как откатываемся при ошибке.

Если нужно, закрепите эти правила внутри команды и в ИТ‑политике (см. /blog/governance-rails).

Где всё ещё нужны инженеры и как делить ответственность

Демократизация разработки не означает, что инженеры «больше не нужны». Скорее меняется граница: часть задач можно делать силами команд бизнеса, а инженерная команда становится гарантом надёжности, безопасности и масштабируемости.

Когда лучше отдавать инженерам

Есть категории решений, где экономия на инженерном подходе быстро превращается в риски и простои:

• Высокая нагрузка и требования к скорости: массовые сервисы, сложные очереди, параллельная обработка, строгие SLA.
• Критичные данные: персональные данные, финансы, медицинская информация, доступ по ролям, аудит действий.
• Сложная логика и много исключений: расчёты, тарифы, нестандартные бизнес‑правила, которые трудно тестировать «вручную».
• Интеграции с ключевыми системами: ERP/CRM/склад, где ошибка затрагивает всю компанию.

Модель сотрудничества: прототип строит бизнес, инженеры усиливают

Практичный формат — «сначала быстро, потом правильно»:

1. Бизнес‑команда собирает прототип в no-code/low-code, проверяет гипотезу и процесс.

2. Инженеры подключаются, чтобы укрепить решение: делают архитектуру, CI/CD, мониторинг, тесты, права доступа и резервное копирование.

3. Дальше продукт масштабируется: переносится в полноценную разработку или остаётся на платформе, но с инженерными ограждениями.

Вариант, который часто хорошо работает организационно: прототипировать в платформе, а затем, если решение становится критичным, передать его в инженерный контур. Здесь помогает экспорт исходников и прозрачная технологическая база. В TakProsto.AI, например, можно выгрузить исходный код и при необходимости продолжить развитие уже как «классический» проект (веб на React, бэкенд на Go с PostgreSQL, мобильная часть на Flutter).

«Платформа + расширения»: ядро под контролем ИТ

Хорошая схема — выделить ядро (данные, безопасность, интеграции, общие справочники) как зону ответственности ИТ, а периферию (формы, отчёты, небольшие автоматизации, внутренние боты) — оставить командам. Так снижается риск «теневой ИТ», но сохраняется скорость.

Признаки, что пора переводить в полноценную разработку

• Решение стало критичным для операционной работы и простои недопустимы.
• Появились регулярные ошибки, которые сложно отлавливать без тестов и логирования.
• Количество пользователей/данных растёт, и платформа начинает тормозить.
• Требуются тонкие права доступа, аудит, шифрование, соответствие внутренним политикам.
• Поддержка держится на одном человеке — нужен процесс владения и документация.

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

Что дальше: к чему ведёт демократизация создания программ

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

Курс на «композируемые» системы

Организации всё чаще переходят к компонуемому подходу: вместо монолитных проектов — сборка решений из готовых модулей, сервисов, шаблонов, коннекторов и API. Это ускоряет изменения: можно заменить один блок, не переписывая всё целиком.

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

Продуктовое мышление важнее инструмента

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

• понимает процесс и его узкие места;
• умеет проверять гипотезы на пользователях;
• задаёт критерии качества (время цикла, ошибки, удовлетворённость).

Появятся новые роли и зоны ответственности

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

Краткий план внедрения

1. Пилот: выбрать 1–2 процесса с понятной ценностью и низким риском.

2. Обучение: базовые навыки (данные, права доступа, тестирование, документация).

3. Каталог решений: шаблоны, коннекторы, примеры, владельцы и контакты.

4. Контроль рисков: простые «ограждения» — политики данных, аудит изменений, обязательные проверки для интеграций.

Итоговый вектор: создание приложений станет обычной компетенцией бизнеса, а ИТ — «фабрикой платформы», которая делает это безопасным, повторяемым и управляемым. А платформы класса vibe‑coding (вроде TakProsto.AI) добавят к этому ещё один слой ускорения: быстрое прототипирование в чате, планирование изменений, деплой и хостинг — с понятным переходом к инженерному уровню, когда решение перерастает «малый софт».