Как не потратить два миллиарда на код, который придется выбросить

Меня зовут Александр Сахаров, я директор по работе с партнерами в «Диасофт». Последние пять лет мы строим экосистему Digital Q – набор low-code платформ для enterprise-разработки в микросервисной архитектуре. Внутри у нас около двух тысяч разработчиков, и мы на собственном опыте ^[1] знаем, что бывает, когда каждая вторая команда изобретает велосипед.

Но в этой статье я хочу показать не только наш взгляд. На конференции Deckhouse Conf 2026 мне удалось собрать за одним столом людей, которые каждый день живут внутри этой проблемы: это руководители в ИТ в крупнейших банках и телеком компаний, помогал мне Артем Гениев из «Фланта», руководитель бизнес-юнита «Экспресс 42» – ребята, которые строят платформу со стороны DevOps и инфраструктуры.

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

Принесли код – а он черный ящик

Любой, кто хоть раз принимал результат заказной разработки, узнает эту историю.

«С чего все начинается? Где-то в бизнесе владелец продукта говорит: мне нужна автоматизация процесса. Бизнес-аналитики лезут в документацию, долго пишут бизнес-требования, согласуют с владельцем, потом отдают на сторону разработки – как правило, подрядной организации. Те пишут ТЗ, задают вопросы, им отвечают. Дальше процесс реализации, поставка кода, функциональное тестирование. И вот функционал вытаскивается на бизнес. Но принимать его приходят не те люди, которые делали постановку. Приходят те, кто реально этим процессом пользуется каждый день. И – о чудо – оказывается, что процесс выглядит вообще по-другому. Начинаются разборки с подрядчиком: как же так получилось? Это баг или фича? Выясняется, что фича, начинается оценка стоимости – дайте денег, дайте сроки. Все, что было заложено в план-графике, уезжает вправо. И этот цикл повторяется», – рассказывает один из участников.

Параллельно появляется еще одна проблема – документация расходится с кодом.

«Мы стараемся написать документацию качественно, и первая версия действительно соответствует тому, что  мы запрограммируем. Но в бесконечных итерациях – туда-сюда, туда-сюда – про документацию забывают ^[2]. В результате система доезжает до эксплуатации с документацией от первой версии кодовой базы. И потом выясняется, что в условном кредитном процессе забыли проверку внешнего источника. А чтобы вставить этот сервис, нужно привлечь кучу соседних команд, которые перепишут свои части», – продолжил он.

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

«Когда подрядчик приносит код, мы пытаемся развернуть его на своих контурах. Но решение падает – и начинается куча разборок: контуры не те, библиотеки не те, еще что-то. Код написали, а ошибки ^[4] вылезают даже на нефункциональном тестировании, не доходя до бизнеса. И вот эти проблемы – что мы такого нашли, что у нас процесс блокируется – бесконечны. А вот с внедряемыми low-code платформами другая ситуация: может быть, не до конца реализована та красота, о которой мечтаешь, но изменения вносятся значительно проще. И когда мы нарастим компетенции, нам будут не нужны будут классические команды с системным аналитиком, то все с платформами сводится к аналитику-настройщику и тестировщику».

Это принципиальный сдвиг. Там, где раньше нужен был целый конвейер из специалистов – аналитик, фронтенд, бэкенд, QA, – появляется возможность обойтись двумя ролями. Но для этого нужна платформа. А что вообще в 2026 году считать платформой?

Сколько людей спросишь – столько определений платформы получишь

«Что такое платформа? Этот вопрос мне всегда напоминает другой – что такое репозиторий. Сколько людей спроси, столько ответов получишь. Самый шикарный ответ, который я слышал: GitHub – это репозиторий репозиториев. С платформами все аналогично. Платформа может быть законченным решением, в котором можно создавать и модифицировать приложения в low-code или no-code подходе. А может быть набором инструментов – не обязательно от одного вендора, – но между ними должна быть сквозная методология, единый или хотя бы одинаковый пользовательский опыт. Вызов одинаковых действий должен вызывать одинаковую реакцию ^[5] системы. И любое событие – непройденный тест, незакрытый security gate – должно автоматически создавать артефакт. Но только не руками, тогда это платформа», – объяснил эксперт, один из участников обсуждения.

Спикер привел в пример стенд «Фланта» на той же конференции.

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

Артем Гениев из «Фланта» предложил посмотреть на проблему через спектр реализаций.

«Мы сфокусировались на платформе как важном инструменте построения эффективного конвейера разработки – и это подтверждается статистикой. Компании, которые поставляют ПО, как правило, являются пользователями какой-либо платформы разработки. Но между шаблонами CI/CD-пайплайнов, которые переиспользуют десять команд, и полнофункциональным центром управления, где в одном окне собраны требования, задачи, пайпы, ресурсы, тесты и мониторинг, – огромная дистанция. И то, и другое можно назвать платформой», – отметил Артем Гениев, руководитель бизнес-юнита «Экспресс 42» компании «Флант».

Вопрос в том, какой уровень платформы оправдан. И здесь начинается самое интересное – разговор о деньгах.

«Сейчас главный критерий – это TCO, то есть стоимость создания плюс стоимость владения. Логика ^[6] проста: если купить “коробку”, настроить ее под себя и затем поддерживать окажется дороже, чем написать с нуля, – значит, нужно писать с нуля. Но здесь кроется подвох. Не забывайте, что каждый разработчик приходит в IT с тайной мечтой создать свой Facebook. И первое, что он скажет, открыв чужой код: “Какой чудак это написал?”», – заметил эксперт, один из участников обсуждения.

Этот рефлекс ^[7] «перепишем с нуля» обходится дорого. Создать полноценную платформу – с автотестами, управлением релизами, проектированием, безопасностью и стандартами производства – это, по оценке Пихтовникова, команда от 50 до 100 человек фулл-тайм. Умножаем на зарплаты – получаем миллиарды рублей. Крупнейшие банки и телекомы могут себе это позволить. Но если в компании IT-подразделение меньше тысячи человек, содержать собственную платформенную команду – роскошь.

200 систем на Delphi и if-then-else на русском

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

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

Причем импортозамещение для госкорпораций – не следствие 2022 года, как принято думать.

«Крупные госкорпорации начали замещать критичные системы гораздо раньше. Первые KPI по импортозамещению, напрямую влияющие на первых лиц организаций, появились, кажется, еще в 2017 году. Именно тогда стартовал процесс миграции всего критически важного ПО. А вот засилье Axapta, SAP и Oracle – это уже наследие двухтысячных, когда Enterprise-сегмент жил по совершенно другим лекалам. Выбирая их, ты получал готовый набор методологий и отчетность по МСФО прямо “из коробки”, поэтому реальная стоимость владения действительно была ниже.

Ну а 1С… Кто в начале нулевых не пробовал на ней писать? Через этот опыт, как и через Delphi, прошли абсолютно все. Никогда не забуду конструкцию “Если – Тогда – Иначе на русском языке”. Воистину незабываемый опыт», – вспомнил он.

Сегодня задача – переписать весь этот зоопарк на современном стеке. Причем не просто переписать, а сделать это так, чтобы результат соответствовал требованиям регуляторов.

На этом фоне бизнес-заказчик формулирует три простых требования к IT.

«С точки зрения ^[9] автоматизации у бизнеса есть всего три глобальных “хотелки”. Первая – приемлемая скорость изменений. Вторая – стоимость: затраты на сами доработки, сопровождение и инфраструктуру. Мы о ней еще не упоминали, а ведь это критически важный фактор. Представьте: десять команд на заказной микросервисной разработке – это десять изолированных контуров. И не просто десять, а с множителем на среды: Dev, Test, Preprod, интеграционные слои… В итоге набегает под пятьдесят окружений! В случае же с платформой инфраструктура едина, и все команды работают внутри нее.

Третья потребность ^[10] – соблюдение SLA. Обкатанная платформа, внедренная у множества заказчиков, получает обновления и новые функции автоматически, в рамках стандартного сопровождения. Заказная разработка такой привилегии лишена. Ну и если вернуться к вопросу скорости: 80% платформенного решения уже готово, кастомизировать нужно лишь оставшиеся 20%. И это обеспечивает реально высокий темп разработки», – резюмировал эксперт.

Велосипед, который изобретают тысячу раз

Тут я не удержался и вставил свои пять копеек – потому что именно эта боль ^[12] стала главным драйвером того, что мы делаем в «Диасофт» последние пять лет.

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

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

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

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

Но главная сложность кроется в другом: команда-разработчик фактически превращается во внутреннего вендора. И здесь возникает вопрос зрелости организации – готовности этой команды не просто “пилить” свой функционал, а полноценно поддерживать его для смежных подразделений. Однако, как только эта точка невозврата пройдена, культура меняется, и все быстро привыкают к новому подходу: достаточно найти автора спецификации и просто уточнить: “А у вас это уже реализовано?”» .

Вручную управлять этим нереально. Нужен единый репозиторий, куда можно зайти, найти API, посмотреть, что уже есть. Собственно, ради этого в Digital Q и появились визуальные инструменты проектирования и каталоги переиспользуемых компонентов.

Но была и обратная сторона – как быть, когда заказчику нужно очень срочно и нет времени делать полноценное решение?

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

Однако в результате команда закономерно накапливает технический долг. Мы контролируем его крайне жестко: наглядно видим объем техдолга в разрезе каждой команды и каждого бизнес-заказчика. Как только его доля начинает превышать 30% от общего бэклога задач, мы ставим “на стоп” всю продуктовую разработку и объявляем: “Ближайшие три месяца занимаемся только исправлениями”. Ведь если мы этого не сделаем, то в перспективе просто перестанем выдерживать SLA

Почему половина платформенных инициатив проваливается

Артем Гениев приводит весьма отрезвляющую статистику: 

«Порядка 50% инициатив по внедрению платформы разработки проваливается. При этом компании-лидеры по качеству и скорости поставки ПО, как правило, платформу используют – будь то коробочное, самописное или кастомизированное решение. Согласно нашим пятилетним исследованиям, около 45% респондентов уже применяют ту или иную платформу. Однако важно понимать: платформа должна развиваться как полноценный внутренний продукт – с удобным поиском, единым пользовательским опытом и реальной востребованностью. Иначе она просто умрет».

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

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

Мы четко видим это на собственных проектах: 95% нашей разработки сегодня ведется на базе платформы Digital Q ^[13]. В результате команды из четырех-пяти человек выпускают такой же объем качественного кода, который раньше требовал штата из пятнадцати специалистов. Секрет прост: платформа забирает на себя всю рутину – кодогенерацию, автотесты, DevOps и обеспечение информационной безопасности, оставляя при этом исходный код полностью открытым».

Между вайб-кодингом и чистым кодом

Отдельная тема, которую мы не могли обойти, – вайб-кодинг. Когда разработчик промтом просит нейросеть передвинуть кнопку и получает новый интерфейс – это завораживает. Но масштабируется ли это на enterprise?

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

Артем Гениев поддержал эту мысль, но с важным уточнением.

«За последние годы произошел принципиальный сдвиг. Раньше low-code платформа означала исполняемый движок – вендор-лок и потенциальные проблемы с нагрузкой, потому что ты зависишь от разработчика платформы: пока он в ядре что-то не пофиксит, ты сидишь и ждешь. Теперь стали появляться платформы, которые дают набор исполняемого кода, которым ты реально владеешь. Прививку от вендор-лока в 2022 году все прошли – достаточно жесткую и болезненную. Новые платформы – это не вайб-кодинг, который очень сложно поддерживать. Это решение, которое можно использовать в том числе при переписывании легаси», – заключил Гениев.

Если резюмировать то, к чему мы пришли за время дискуссии, – картина складывается достаточно четкая.

Писать enterprise-код без платформы в 2026 году – все равно что копать котлован лопатой при наличии экскаватора. Можно, но зачем. Платформа – это не серебряная пуля. Но те, кто ее используют получают измеримый результат: маленькие команды выпускают продукт быстрее, дешевле и с предсказуемым качеством. Легаси никуда не денется – с ним придется жить и постепенно переписывать. Но переписывать нужно на современном стеке, будь то Java, Go или Python, и обязательно с платформенной обвязкой – иначе через пять лет получится новое легаси, только на модном языке.

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

Мы в «Диасофт» строим свою часть этого пазла – экосистему Digital Q. Коллеги из «Фланта» строят свою, со стороны DevOps и инфраструктуры. Мы пересекаемся, дополняем друг друга – и вместе закрываем тот самый end-to-end цикл от проектирования до эксплуатации.