Привет, Хабр! Меня зовут Александр Сахаров, я директор по работе с партнерами в «Диасофт». Последние пять лет мы строим экосистему Digital Q — набор low-code платформ для enterprise-разработки в микросервисной архитектуре. Внутри у нас около двух тысяч разработчиков, и мы на собственном опыте знаем, что бывает, когда каждая вторая команда изобретает велосипед.
Но в этой статье я хочу показать не только наш взгляд. На конференции Deckhouse Conf 2026 мне удалось собрать за одним столом людей, которые каждый день живут внутри этой проблемы: это руководители в ИТ в крупнейших банках и телеком компаний, помогал мне Артем Гениев из «Фланта», руководитель бизнес-юнита «Экспресс 42» — ребята, которые строят платформу со стороны DevOps и инфраструктуры.
Получился разговор о реальных граблях: почему заказчик получает не тот продукт, который заказывал, куда уходят миллиарды на легаси, и почему половина инициатив по внедрению платформ проваливается. Собрал выжимку — без воды, с цитатами и конкретикой.
Принесли код — а он черный ящик
Любой, кто хоть раз принимал результат заказной разработки, узнает эту историю.
«С чего все начинается? Где-то в бизнесе владелец продукта говорит: мне нужна автоматизация процесса. Бизнес-аналитики лезут в документацию, долго пишут бизнес-требования, согласуют с владельцем, потом отдают на сторону разработки — как правило, подрядной организации. Те пишут ТЗ, задают вопросы, им отвечают. Дальше процесс реализации, поставка кода, функциональное тестирование. И вот функционал вытаскивается на бизнес. Но принимать его приходят не те люди, которые делали постановку. Приходят те, кто реально этим процессом пользуется каждый день. И — о чудо — оказывается, что процесс выглядит вообще по-другому. Начинаются разборки с подрядчиком: как же так получилось? Это баг или фича? Выясняется, что фича, начинается оценка стоимости — дайте денег, дайте сроки. Все, что было заложено в план-графике, уезжает вправо. И этот цикл повторяется», — рассказывает один из участников.
Параллельно появляется еще одна проблема — документация расходится с кодом.
«Мы стараемся написать документацию качественно, и первая версия действительно соответствует тому, что мы запрограммируем. Но в бесконечных итерациях — туда-сюда, туда-сюда — про документацию забывают. В результате система доезжает до эксплуатации с документацией от первой версии кодовой базы. И потом выясняется, что в условном кредитном процессе забыли проверку внешнего источника. А чтобы вставить этот сервис, нужно привлечь кучу соседних команд, которые перепишут свои части», — продолжил он.
Масштаб проблемы становится понятнее, когда речь заходит о заказной разработке в крупных организациях с сотнями информационных систем. Подрядчик приносит кодовую базу — и начинается.
«Когда подрядчик приносит код, мы пытаемся развернуть его на своих контурах. Но решение падает — и начинается куча разборок: контуры не те, библиотеки не те, еще что-то. Код написали, а ошибки вылезают даже на нефункциональном тестировании, не доходя до бизнеса. И вот эти проблемы — что мы такого нашли, что у нас процесс блокируется — бесконечны. А вот с внедряемыми low-code платформами другая ситуация: может быть, не до конца реализована та красота, о которой мечтаешь, но изменения вносятся значительно проще. И когда мы нарастим компетенции, нам будут не нужны будут классические команды с системным аналитиком, то все с платформами сводится к аналитику-настройщику и тестировщику».
Это принципиальный сдвиг. Там, где раньше нужен был целый конвейер из специалистов — аналитик, фронтенд, бэкенд, QA, — появляется возможность обойтись двумя ролями. Но для этого нужна платформа. А что вообще в 2026 году считать платформой?
Сколько людей спросишь — столько определений платформы получишь
«Что такое платформа? Этот вопрос мне всегда напоминает другой — что такое репозиторий. Сколько людей спроси, столько ответов получишь. Самый шикарный ответ, который я слышал: GitHub — это репозиторий репозиториев. С платформами все аналогично. Платформа может быть законченным решением, в котором можно создавать и модифицировать приложения в low-code или no-code подходе. А может быть набором инструментов — не обязательно от одного вендора, — но между ними должна быть сквозная методология, единый или хотя бы одинаковый пользовательский опыт. Вызов одинаковых действий должен вызывать одинаковую реакцию системы. И любое событие — непройденный тест, незакрытый security gate — должно автоматически создавать артефакт. Но только не руками, тогда это платформа», — объяснил эксперт, один из участников обсуждения.
Спикер привел в пример стенд «Фланта» на той же конференции.
«Очень хорошо видно, что ребята делают платформу: у них появился функционал управления проектами и задачами, функционал git, управление секретами. Они взяли определенный процесс и весь его жизненный цикл покрывают своими инструментами вместе с методологией. Поэтому платформа — это может быть как один инструмент, в котором полностью идет разработка, так и набор инструментов, но они должны реализовывать законченный жизненный цикл какого-либо процесса», — уточнил он.
Артем Гениев из «Фланта» предложил посмотреть на проблему через спектр реализаций.
«Мы сфокусировались на платформе как важном инструменте построения эффективного конвейера разработки — и это подтверждается статистикой. Компании, которые поставляют ПО, как правило, являются пользователями какой-либо платформы разработки. Но между шаблонами CI/CD-пайплайнов, которые переиспользуют десять команд, и полнофункциональным центром управления, где в одном окне собраны требования, задачи, пайпы, ресурсы, тесты и мониторинг, — огромная дистанция. И то, и другое можно назвать платформой», — отметил Артем Гениев, руководитель бизнес-юнита «Экспресс 42» компании «Флант».
Вопрос в том, какой уровень платформы оправдан. И здесь начинается самое интересное — разговор о деньгах.
«Сейчас главный критерий — это TCO, то есть стоимость создания плюс стоимость владения. Логика проста: если купить «коробку», настроить ее под себя и затем поддерживать окажется дороже, чем написать с нуля, — значит, нужно писать с нуля. Но здесь кроется подвох. Не забывайте, что каждый разработчик приходит в IT с тайной мечтой создать свой Facebook. И первое, что он скажет, открыв чужой код: «Какой чудак это написал?”», — заметил эксперт, один из участников обсуждения.
Этот рефлекс «перепишем с нуля» обходится дорого. Создать полноценную платформу — с автотестами, управлением релизами, проектированием, безопасностью и стандартами производства — это, по оценке Пихтовникова, команда от 50 до 100 человек фулл-тайм. Умножаем на зарплаты — получаем миллиарды рублей. Крупнейшие банки и телекомы могут себе это позволить. Но если в компании IT-подразделение меньше тысячи человек, содержать собственную платформенную команду — роскошь.
200 систем на Delphi и if-then-else на русском
Разговор о платформах рискует остаться теоретическим, если не понимать масштаб легаси, с которым работают крупные российские компании прямо сейчас.
«В нашем контуре порядка двухсот развивающихся систем. Самой молодой из них — лет семь, самой старой — около двадцати пяти, и написана она, кажется, еще на Delphi. Поэтому, когда к нам приходят со словами: «Вот вам отличный конструктор, на нем вы быстро все сделаете, будет супер!» — это воспринимается как чистый маркетинг. Ведь реальность такова: у меня на руках старая система, в которую нужно просто добавить одну конкретную фичу», — описал ситуацию один из участников круглого стола.
Причем импортозамещение для госкорпораций — не следствие 2022 года, как принято думать.
«Крупные госкорпорации начали замещать критичные системы гораздо раньше. Первые KPI по импортозамещению, напрямую влияющие на первых лиц организаций, появились, кажется, еще в 2017 году. Именно тогда стартовал процесс миграции всего критически важного ПО. А вот засилье Axapta, SAP и Oracle — это уже наследие двухтысячных, когда Enterprise-сегмент жил по совершенно другим лекалам. Выбирая их, ты получал готовый набор методологий и отчетность по МСФО прямо «из коробки», поэтому реальная стоимость владения действительно была ниже.
Ну а 1С… Кто в начале нулевых не пробовал на ней писать? Через этот опыт, как и через Delphi, прошли абсолютно все. Никогда не забуду конструкцию “Если — Тогда — Иначе на русском языке”. Воистину незабываемый опыт», — вспомнил он.
Сегодня задача — переписать весь этот зоопарк на современном стеке. Причем не просто переписать, а сделать это так, чтобы результат соответствовал требованиям регуляторов.
На этом фоне бизнес-заказчик формулирует три простых требования к IT.
«С точки зрения автоматизации у бизнеса есть всего три глобальных «хотелки». Первая — приемлемая скорость изменений. Вторая — стоимость: затраты на сами доработки, сопровождение и инфраструктуру. Мы о ней еще не упоминали, а ведь это критически важный фактор. Представьте: десять команд на заказной микросервисной разработке — это десять изолированных контуров. И не просто десять, а с множителем на среды: Dev, Test, Preprod, интеграционные слои… В итоге набегает под пятьдесят окружений! В случае же с платформой инфраструктура едина, и все команды работают внутри нее.
Третья потребность — соблюдение SLA. Обкатанная платформа, внедренная у множества заказчиков, получает обновления и новые функции автоматически, в рамках стандартного сопровождения. Заказная разработка такой привилегии лишена. Ну и если вернуться к вопросу скорости: 80% платформенного решения уже готово, кастомизировать нужно лишь оставшиеся 20%. И это обеспечивает реально высокий темп разработки», — резюмировал эксперт.
Велосипед, который изобретают тысячу раз
Тут я не удержался и вставил свои пять копеек — потому что именно эта боль стала главным драйвером того, что мы делаем в «Диасофт» последние пять лет.
У нас работают около двух тысяч разработчиков. И когда мы честно посмотрели на то, чем они занимаются, выяснилось: больше половины времени команды тратят на изобретение того, что уже сделано в соседнем проекте. Каждая команда заново пишет примерно одни и те же вещи — работу с информационной безопасностью, обращения к шинам, типовые справочники, клиентские процессы.
Мы это прекратили. Первым шагом стало визуальное проектирование логической архитектуры и бизнес-процессов — и бесшовная связь между ними. Как только какая-то команда начинает проектировать что-то похожее на то, что уже существует в другом месте, загорается красный семафор. На еженедельных архитектурных контрольных точках это видно, и начинается обсуждение: почему вы не используете то, что уже сделано до вас? За три года таких переиспользуемых процессов у нас накопились тысячи.
Вторым шагом стала автоматическая генерация интерфейсов. Заставлять фронтенд-разработчиков рисовать одни и те же экраны — странно: можно сгенерировать каркас, а дальше руками подправить. Получается единый UX, не надо никого переобучать, а реальная фронтенд-разработка сводится к корректировкам.
«Переиспользование компонентов — это не только снижение стоимости владения, но и гарантия того, что у службы эксплуатации будет куда меньше проблем. Допустим, типовая спецификация интеграции с корпоративным SSO публикуется в формате OpenAPI. Следующий логичный шаг — выпустить готовый компонент для работы с SSO, который берет на себя механизм авторизации во всех встраиваемых приложениях. Компонент становится стандартом.
Но главная сложность кроется в другом: команда-разработчик фактически превращается во внутреннего вендора. И здесь возникает вопрос зрелости организации — готовности этой команды не просто «пилить» свой функционал, а полноценно поддерживать его для смежных подразделений. Однако, как только эта точка невозврата пройдена, культура меняется, и все быстро привыкают к новому подходу: достаточно найти автора спецификации и просто уточнить: «А у вас это уже реализовано?»» .
Вручную управлять этим нереально. Нужен единый репозиторий, куда можно зайти, найти API, посмотреть, что уже есть. Собственно, ради этого в Digital Q и появились визуальные инструменты проектирования и каталоги переиспользуемых компонентов.
Но была и обратная сторона — как быть, когда заказчику нужно очень срочно и нет времени делать полноценное решение?
Мы решали подобные вопросы через архитектурные комитеты. Безусловно, бывают ситуации, когда заказчик приходит с безапелляционным: «Мне нужно завтра». И здесь ничего не поделаешь: условный старт корабля «Прогресс» назначен на завтра, а послезавтра будет уже слишком поздно. В таких экстренных случаях принимается осознанное решение — делаем быстро, в обход стандартов и вне платформы.
Однако в результате команда закономерно накапливает технический долг. Мы контролируем его крайне жестко: наглядно видим объем техдолга в разрезе каждой команды и каждого бизнес-заказчика. Как только его доля начинает превышать 30% от общего бэклога задач, мы ставим «на стоп» всю продуктовую разработку и объявляем: «Ближайшие три месяца занимаемся только исправлениями». Ведь если мы этого не сделаем, то в перспективе просто перестанем выдерживать SLA
Почему половина платформенных инициатив проваливается
Артем Гениев приводит весьма отрезвляющую статистику:
«Порядка 50% инициатив по внедрению платформы разработки проваливается. При этом компании-лидеры по качеству и скорости поставки ПО, как правило, платформу используют — будь то коробочное, самописное или кастомизированное решение. Согласно нашим пятилетним исследованиям, около 45% респондентов уже применяют ту или иную платформу. Однако важно понимать: платформа должна развиваться как полноценный внутренний продукт — с удобным поиском, единым пользовательским опытом и реальной востребованностью. Иначе она просто умрет».
При этом он подчеркивает, что полномасштабное решение нужно далеко не всем: «Представьте организацию, где всего пятнадцать разработчиков. Им, безусловно, полезно переиспользовать код и ускорять рутину. Но нужна ли им тяжеловесная полнофункциональная платформа для эффективной поставки ценности? В таком масштабе пользы от нее будет мало, а обойдется она неоправданно дорого».
Действительно, для небольших команд вполне достаточно набора шаблонов и стандартизированных пайплайнов. Но когда счет разработчиков идет на сотни, количество проектов измеряется десятками, а сверху давят требования регуляторов, — без единой платформы выдержать темп становится невозможно.
Мы четко видим это на собственных проектах: 95% нашей разработки сегодня ведется на базе платформы Digital Q. В результате команды из четырех-пяти человек выпускают такой же объем качественного кода, который раньше требовал штата из пятнадцати специалистов. Секрет прост: платформа забирает на себя всю рутину — кодогенерацию, автотесты, DevOps и обеспечение информационной безопасности, оставляя при этом исходный код полностью открытым».
Между вайб-кодингом и чистым кодом
Отдельная тема, которую мы не могли обойти, — вайб-кодинг. Когда разработчик промтом просит нейросеть передвинуть кнопку и получает новый интерфейс — это завораживает. Но масштабируется ли это на enterprise?
«Долгое время создавались именно монолиты. Потом монолиты начали распиливать на микросервисы. И сейчас появляется ось: с одной стороны — полный кастом, с другой — вайб-кодинг, где промтом можно получить новый дизайн или реквест на изменение кода. Может быть, для систем с большой вариативностью и частыми изменениями где-то в середине этой оси лежит платформенный подход — уже не чистый кастом, где стоимость ошибки огромна, но еще не вайб-кодинг, где стоимость ошибки кажется маленькой, пока не дойдет до прода», — предположил один из участников дискуссии.
Артем Гениев поддержал эту мысль, но с важным уточнением.
«За последние годы произошел принципиальный сдвиг. Раньше low-code платформа означала исполняемый движок — вендор-лок и потенциальные проблемы с нагрузкой, потому что ты зависишь от разработчика платформы: пока он в ядре что-то не пофиксит, ты сидишь и ждешь. Теперь стали появляться платформы, которые дают набор исполняемого кода, которым ты реально владеешь. Прививку от вендор-лока в 2022 году все прошли — достаточно жесткую и болезненную. Новые платформы — это не вайб-кодинг, который очень сложно поддерживать. Это решение, которое можно использовать в том числе при переписывании легаси», — заключил Гениев.
Если резюмировать то, к чему мы пришли за время дискуссии, — картина складывается достаточно четкая.
Писать enterprise-код без платформы в 2026 году — все равно что копать котлован лопатой при наличии экскаватора. Можно, но зачем. Платформа — это не серебряная пуля. Но те, кто ее используют получают измеримый результат: маленькие команды выпускают продукт быстрее, дешевле и с предсказуемым качеством. Легаси никуда не денется — с ним придется жить и постепенно переписывать. Но переписывать нужно на современном стеке, будь то Java, Go или Python, и обязательно с платформенной обвязкой — иначе через пять лет получится новое легаси, только на модном языке.
Главное, что я вынес из разговора: дело не в конкретном инструменте, а в подходе. Единая методология, сквозной жизненный цикл, переиспользование, автоматическая генерация рутины, контроль техдолга. Когда начинающий разработчик приходит в команду, где все это уже настроено, он за неделю делает первый осмысленный коммит — а не тратит месяц на то, чтобы разобраться, где что лежит. Это и есть платформенный подход — не маркетинг, а способ выжить при тех масштабах и скоростях, которые требует рынок.
Мы в «Диасофт» строим свою часть этого пазла — экосистему Digital Q. Коллеги из «Фланта» строят свою, со стороны DevOps и инфраструктуры. Мы пересекаемся, дополняем друг друга — и вместе закрываем тот самый end-to-end цикл от проектирования до эксплуатации.
ссылка на оригинал статьи https://habr.com/ru/articles/1028278/