Привет, Хабр! Меня зовут Александр Сахаров, я директор по работе с партнерами в «Диасофт». Последние пять лет мы строим экосистему 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 цикл от проектирования до эксплуатации.