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

На примере бизнес-приложения IDM (Identity Management) мы покажем, как меняется подход к разработке, если использовать No-code, Low-code или Pro-code инструменты. Материал будет полезен тем, кто выбирает платформу для enterprise-сценариев, проектирует процессы и оценивает риски масштабирования. 

На демо всё красиво: задачки бегают, доски сияют, отчёты рисуются. Через полгода команда уточняет статусы в чате, релизы сверяет в таблице, а тимлид перед стендапом открывает пять вкладок. Разбираем четыре ошибки выбора системы управления разработкой и даём чеклист из 12 вопросов, которые стоит задать до покупки.

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

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

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

Об этом и поговорим.

Разбираем техническую анатомию расхождений, пять антипаттернов учёта и четыре класса инструментов, которые нужно заставить работать вместе.

В Excel 3000 строк, половина неактуальна, в графе «МОЛ» — уволившийся два года назад сисадмин. Разбираем четыре класса инструментов для инвентаризации ИТ-активов — от бесплатного Snipe-IT и GLPI до enterprise-платформ. Честный обзор с минусами каждого продукта, включая наш собственный, сравнительная таблица и навигация по масштабу компании.

Ушел TeamViewer, Veeam не купить, Jira SM превратилась в тыкву. Собрали актуальный стек российского сисадмина в 2026: шесть категорий, только то что реально работает в проде. Внутри — таблица импортозамещения, честные минусы каждого продукта и чек-лист выживания инфраструктуры.

Где-то на GitHub лежит репозиторий с файлом .cursorrules. Среди инструкций для Cursor затесалась строчка:

ALWAYS refer to the user as "My Dear Capybara"

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

Капибара – нормальная сцена для жанра. Мы несколько часов изучали публичные .cursorrules на GitHub, и обращение к капибаре оказалось примерно чуть ниже серединой шкалы странностей. Бывает заметно дичее: фурри-волки QA, отаку-самураи, команды Cursor-агентов в стиле Star Trek и (классический промптинг) прямой мат в адрес модели заглавными буквами. И всё это лежит в продакшн-репозиториях, между обычным ESLint-конфигом и package.json.

Окунемся в ужас с головой.

Автономные агенты в разработке уже встроены в CI/CD живых команд, закрывают реальные тикеты и пишут код, который идёт в прод. Проблема не в том, что они это делают плохо, а в том, что метрики при этом выглядят слишком отлично.

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

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

На балансе 1420 единиц техники. В сети светится 980. Где остальные — не знает никто. Разбираем, почему учёт ломается после 500 единиц, почему Excel и 1С не спасают, и как это починить за квартал.

Всем привет, это команда продукта SimpleOne SDLC. Поговорим о вещи, которую в командах обычно не обсуждают вслух — о бэклоге дефектов, который никто не разгребает.

Откройте свой git log за последний месяц. Посчитайте коммиты, начинающиеся со слов fix, hotfix, temp, workaround или (классика жанра) – //TODO: переписать нормально. Поздравляем, у вас уже работают проценты по техдолгу, которые вы пока не считали.

Фича делалась 3 дня, теперь делается 3 недели. Как перевести техдолг в рубли и перестать проигрывать разговор с бизнесом.

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

Мы команда SimpleOne — вендор решений для автоматизации бизнес-процессов. У нас есть Центр обучения с готовыми курсами по нашей Low-code платформе для разных уровней подготовки, эти материалы помогают партнерам и клиентам получить внутреннюю экспертизу по нашим продуктам. А ещё мы периодически проводим интенсивы для начинающих, за 2 недели разбираем основы и практические задачи. Мы решили показать, как выглядит ИТ-обучение от работодателя, после которого участники могут действительно получить оффер.

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

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

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

Пока команда одна — всё логично: бэклог, доска, понятный поток. Но когда команд становится пятнадцать и все работают над одним продуктом — Jira начинает вести себя странно. Product Owner открывает утро с обхода четырёх проектов, задачи дублируются, а зависимости живут в комментариях. Разбираемся, почему это не про «плохую Jira», а про конфликт моделей.

Пятница, 23:40, прод лежит. Дежурный поднимает сервис за сорок минут: перезапустил контейнер, всё заработало. Инцидент закрыт, MTTR красивый, все спать.

Через десять дней то же самое: тот же сервис, та же ошибка в логах. Снова подняли и снова закрыли.

$180 на Cursor за три дня. Три монитора. Пакет орешков. Ноль тестов. Бизнес в восторге. Команда в ужасе. Угадайте, кто победил.

Данные перенесены, workflow настроен, всех обучили. А через неделю — саботаж, снова задачи в Excel и бунтующий разработчик, у которого «вообще-то в Jira все нормально было»