Импортозамещение в официальных отчетах уже давно выглядит завершенным этапом. Реестр отечественного ПО растет, вендоры говорят о «зрелых платформах», компании отчитываются о замене ключевых систем. Но в разговорах с ИТ-директорами звучит совсем другое: на бумаге все закрыто, а в реальной эксплуатации картина неоднородная. Где-то российские решения действительно взяли на себя критичные процессы, где-то замена ограничилась формальной установкой продукта, который живет параллельной жизнью и мало влияет на бизнес. Именно об этой разнице между «закрыли импорт» и «реально работает» говорили участники виртуального круглого стола, организованного IT-World и Санкт-Петербургским клубом ИТ-директоров.
Как понять, что система «прижилась»
Модератор Константин Кутырло (СМ-Клиника) предложил начать с простого, но болезненного вопроса: по какому признаку вообще можно считать, что замещающая система не просто установлена, а действительно выполняет свою функцию в бизнесе. Формальные критерии (наличие российского ПО, галочка в плане импортозамещения, акт внедрения) уже никого не убеждают. Гораздо правдивее звучат живые определения. Например, как сказал Никита Крылов (СК «Город»): «Когда в 18 часов заканчивается рабочий день, мы уходим домой и не беспокоимся о том, что завтра это не будет работать». То есть система переживает рабочий день без подвигов дежурной смены и без ночных «авралов после внедрения».
Еще один слой — сравнение с тем, что было до замены. В понимании Максима Гречука («Системы Практической Безопасности») импортозамещение можно считать состоявшимся, если привычный для пользователей функционал и ключевые бизнес-процессы в «допустимом, приемлемом объеме реализованы на новом ПО». Не всегда удается сохранить весь комфорт, который давали прежние зарубежные решения, и это приходится честно признавать: «реальность такая». При этом сама замена, по словам Максима, почти неизбежно меняет и процессы, и повседневную жизнь сотрудников. Пользователи очень привязаны к привычному образу работы, и любое внедрение вызывает у них стресс. Задача ИТ-команды — минимизировать этот стресс настолько, чтобы после перехода действительно «можно было спокойно уходить домой после шести», а не жить в режиме постоянного ожидания, «что завтра опять что-нибудь упадет». Именно с такого прикладного понимания «реально работает» и начался разговор о том, что на самом деле происходит с импортозамещением в российских компаниях.
Совместимость, культура разработки и цена ошибки
Один из самых болезненных узлов импортозамещения — конфликт между «допустимым уровнем функционала» и пользовательскими привычками. Даже когда российская система формально закрывает нужные процессы, интерфейс «из двухтысячных» или непривычная логика работы легко превращаются в стоп-фактор. Как подчеркивает Никита Крылов, в приоритете должна оставаться целостность данных и устойчивость системы: пусть интерфейс выглядит старомодно и часть выгрузок приходится собирать вручную, но это осознанный шаг в рамках выбранного решения, который ИТ-директор обязан честно проговорить с бизнесом. При этом, по его мнению, при выборе продукта важно смотреть не только на текущий функционал, но и на то, в каком направлении развивается сам вендор или интегратор.
На стороне пользователей проблема выглядит иначе. Кирилл Тимофеев (ОБИТ) напоминает, что на старте вендоры почти всегда обещают: «мы можем закрыть все потребности». Но на практике часть функций «работает очень формально» — «он вроде есть, но его вроде нет»: кнопки и галочки присутствуют, а реальный сценарий не совпадает с ожиданиями людей, привыкших к прежним системам. В этих случаях без управляемых изменений уже внутри компании не обойтись: нужно объяснять, где функциональность действительно замещена, а где ее приходится добирать за счет стека из нескольких продуктов, чтобы суммарно дотянуться до уровня прежнего импортного решения.
Если говорить о пользовательском опыте, далеко не весь российский софт — это «старые окна из 90-х». Значительная часть современных систем уже работает в вебе, с интерфейсами уровня «скорее 2026 года». Проблема привычки особенно чувствуется там, где десятилетиями использовали Word и Excel, а теперь людям предлагают Р7 или «МойОфис». «Даже мы, ИТ-директора, впадаем в легкий ступор», — добавляет Анатолий Московский (Санкт-Петербургский клуб ИТ-директоров). При этом сам рынок движется вперед, и многое зависит от того, насколько вендор готов подстраивать roadmap под реальные потребности: те, кто «очень плотно работает с заказчиками», успевают не только закрывать баги, но и «закладывать на порядок больше возможностей, чем было у европейских аналогов».
Для производителя формально внедренный продукт — это всего лишь подписанный акт: «акт подписали — вроде все успокоились, при этом процессы никуда не идут». Чтобы «самому спокойно уйти домой», по словам Михаила Зарембо («РуПост», входит в «Группу Астра), вендору нужно, чтобы заказчик был обеспечен необходимой документацией, инструкциями и техподдержкой, которая закрывает большинство кейсов без эскалаций. Важно и то, что в цепочке всегда есть третье звено — интегратор, который «работает клеем» между заказчиком и разработчиком. При этом эксперт рекомендует в проектах отталкиваться от бизнес-задач, а не от повторения того или иного функционала западных решений на 100%. А переходя на привычки пользователей, он предлагает идти в парадигме «80 на 20»: если 80% типичных ежедневных функций, которые выполняют пользователи, не прерываются, это уже успех, а оставшиеся 20% — приоритизируются и вносятся в roadmap, постепенно доращивая продукт.
С выходом 27-го релиза 1С (8.3.27.Х) выяснилось, что на большей части отечественных ОС клиент 1С просто не работает: устанавливается, пытается стартовать, но… выдает ошибку и… всё. Библиотеки не совместимы. В итоге «релизы 8.3.27 более-менее нормально могут работать только на Ubuntu и Debian, хотя 8.3.25 нормально работал и на «Астре», и на RedOS». Это, как отмечает Игорь Орлов (Санкт-Петербургский клуб ИТ-директоров), уже не психология пользователей, а «аспекты культуры разработки и взаимодействия с клиентами». При этом по пальцам одной руки можно пересчитать продукты, «которые действительно не требуют ежедневной поддержки вендора», — в большинстве российских внедрений участие производителя и партнеров в эксплуатации гораздо выше, чем раньше было с западным софтом. Отсюда и вывод: нужна культура совместного, комплексного тестирования стеков, а не только отдельных продуктов.
Антон Кузнецов (Санкт-Петербургский клуб ИТ-директоров) согласен с идеей «80% функционала», но подчеркивает, что проблема часто начинается еще до внедрения — с отсутствия партнерского подхода. Когда вендор или интегратор приходит с позицией «у вас так работать не будет, переделайте», это почти гарантированно вызывает отторжение. Совсем другая история там, где продуктовая команда вместе с заказчиком разбирает бизнес-процессы, объясняет, почему их нужно изменить, и помогает перестроить. Тогда и внедрение, и последующая поддержка имеют куда больше шансов пройти без «просадок». Параллельно рынок проходит этап естественного отсева: продуктов слишком много, «в каждом направлении должно остаться от двух до пяти», только тогда стабилизируются цены и появится стимул у вендоров серьезно инвестировать в интеграцию друг с другом.
В этой ситуации выбор часто оказывается в позиции лотереи: приходится делать ставку на решения, которые через несколько лет могут перестать развиваться или просто исчезнуть. Долгие годы российские вендоры жили за счет «узких ниш» и эксклюзивных фич, а теперь вынуждены закрывать базовые потребности бизнеса и догонять по качеству и устойчивости. На этом фоне один из немногих рабочих ориентиров для ИТ-директора — опора на игроков с длинной историей и экосистемными линейками, которые развиваются более системно и предсказуемо, чем множество новых продуктов, появляющихся и исчезающих с рынка.
Цена несовместимых релизов
За разговором о зрелости отечественных продуктов участники вышли на тему качества релизов и совместимости стеков. Импортозамещенная «экосистема» в реальности оказывается набором подвижных частей, где версионирование и документация становятся не менее важными, чем сам функционал.
Один из практических вопросов касается базовой гигиены эксплуатации: почему бы не вводить у себя «фриз» версий и обязательный стейджинг — небольшую среду, повторяющую «боевую» инфраструктуру, где все обновления проходят обкатку до продакшена. На фазе тестирования, например, можно снять большую часть проблем и заранее включить в работу техподдержку вендора. На фоне спокойных циклов Microsoft, выпускавшей Office раз в год, а серверные продукты раз в несколько лет, российские поставщики, по мнению Анатолия Московского, «ускоряются» слишком сильно: свежие версии выходят через месяц-два после очередного апдейта и бизнесу приходится жить в режиме постоянного обновления.
Михаил Зарембо полностью согласен, что стейджинг сегодня критичен, особенно когда продукт «встраивается в инфраструктуру и интегрирован много с чем». При этом честно признает, что производители физически не успевают тестировать все со всем: продуктов стало слишком много, многие бросились в концепцию «суперапов» и экосистем, а интеграция между конкурирующими решениями зачастую никому коммерчески не выгодна. В результате «трудозатраты по инициализации совместимости» перекладываются на заказчика, который единственный может заставить двух вендоров сесть и разбираться вместе. Частые релизы тоже не случайны: рынок требует одновременно и исправления багов, и закрытия «тех самых 80%» насущных бизнес-потребностей. По словам спикера, сами продуктовые команды «мечтают сделать фича-фриз и просто вычистить баги», но гонка за функциональностью этого не позволяет.
Проблема совместимости упирается и в то, на чем сами разработчики собирают и тестируют свои продукты. Так, многие громкие флагманы импортозамещения — от 1С до CAD-систем — долгие годы разрабатывались и проверялись не на российских ОС. Отсюда и курьезные, но болезненные ситуации, вроде релиза 1С, который не работает ни на одной из популярных отечественных платформ, хотя формально и то и другое — «импортозамещенные решения». По оценке Игоря Орлова, полностью импортонезависимую экосистему собрать пока крайне сложно, поэтому компании вынужденно «импортозамещаются частями», получая набор разрозненных «фиговых листков», а не цельную архитектуру.
Даже там, где функционально все складывается, часто подводит документация. Например, типичный кейс: в новой версии продукта перестает работать порт, протокол или «интересная фича», которая была описана в прошлой документации. Пока ИТ-служба методом проб и ошибок, повторных обращений в поддержку и поисков «того самого разработчика» выяснит, что нужно лишь «открыть один порт или добавить библиотеку», бизнес уже сталкивается с простоями и регрессиями. Отсюда прямой запрос к вендорам — заполнять и актуализировать документацию не менее тщательно, чем писать код.
На все это накладывается еще один риск: перегретый рынок и нехватка «насмотренности». Сегодня ни у интеграторов, ни у заказчиков нет устойчивого опыта по типовым сочетаниям продуктов — вариантов стеков так много, что каждая новая комбинация часто становится экспериментом с «нулевым пациентом». Уже потом кто-то будет рассказывать на конференциях: «так делать классно» или «никогда так не делайте». Сейчас же время одновременно интересное и опасное: ошибка в выборе стека или релиза вполне может обернуться фатальными последствиями — и для ИТ-директора, и для компании.
Ландшафт из «фиговых листочков» как общий управленческий риск
Еще один слой дискуссии — ответственность за тот самый «ландшафт из фиговых листочков». Ранее речь шла в основном о качестве релизов и стыковке стеков, но модератор разворачивает вопрос к вендорам и участникам: если на рынке все равно есть решения, которые занимают львиную долю (1С, несколько массовых CRM и т. д.), почему бы не сосредоточиться хотя бы на системной проверке совместимости именно с ними, а не пытаться «успеть все и сразу»?
Такая работа действительно идет, под нее создаются отдельные команды, которые собирают статистику по самым используемым продуктам и строят приоритетные матрицы тестирования, утверждает Михаил Зарембо. Но даже в этих сценариях «не без проблем»: гонка релизов, сезонные пики (конец года, сжатые циклы выпуска), человеческий фактор и sheer number of products приводят к тому, что «большое количество тестирований дает большое количество недочетов и упущений». Разнообразие решений — большой плюс рынка, но обратная сторона этого плюса ощутима каждый раз, когда всплывает несовместимость двух формально «поддерживаемых» версий.
Дальше разговор закономерно смещается к роли самих архитекторов. После метафоры про импортозамещение «из фиговых листочков» возникает неудобный вопрос: все ли можно списать на незрелость продуктов и тестирование, или часть проблем — «наша, как архитекторов того ландшафта, который мы с вами создали»? Ответы оказываются неоднозначными.
С одной стороны, корень многих сбоев — именно в культуре разработки и выпуска. Продуктивные релизы базового платформенного ПО должны быть консистентны и предсказуемы. «Обновление из продуктивного репозитория не должно приводить к разрушению работоспособной системы, которая не восстанавливается после коррекции репозитория — приходится переустанавливать заново, — подчеркивает Игорь Орлов. — Накатив обновление или вернувшись к предыдущему релизу, вы должны получить цельную работоспособную систему, а не лотерею». Если релиз выходит с утечками памяти или ломает совместимость с тем, на что сам же вендор официально ссылается, ответственность лежит в первую очередь на платформенном поставщике. Особенно это критично для криптографии, операционных систем, крупных платформ, от которых зависят десятки других решений.
С другой стороны, архитектурные «скелеты в шкафу» тоже никуда не деваются. Например, типичный кейс: на пилоте все выглядит идеально, интеграции сходятся, тестовые группы довольны. А при масштабировании вдруг в каком-нибудь дальнем филиале обнаруживается «маленькая виртуальная машинка» с одиноким, но критичным приложением, о котором не знали ни архитекторы, ни интеграторы. На деле это оказывается «замковым камнем», вокруг которого крутится вся работа филиала — импортозаместить его невозможно, интегрировать не удается, и весь проект встает. В этом смысле, признает Анатолий Московский, ИТ-архитектура тоже виновата: неполное обследование, отсутствие документации на процессы и теневая инфраструктура превращаются в стоп-фактор.
Ситуация особенно остра для компаний под жестким регулированием: «они вынуждены быть паровозами», идти впереди остальных по импортозамещению, и именно на них болезненней всего отражаются частые обновления ОС, систем защиты, несовместимости с тем же «Касперским». Отсюда запрос к крупным вендорам — операционных систем, безопасности, базовых платформ: больше работы в тандеме, больше совместного тестирования «на верхнем круге» ключевых систем, чтобы каждое обновление заранее проходило через набор опорных ИС и версий.
На этом фоне Кирилл Тимофеев резюмирует двойственное положение ИТ-директоров: «мы, с одной стороны, виновники, но с другой — заложники». С одной стороны, действительно не хватает «культуры тестирования и выпуска» у части поставщиков — когда в минорном обновлении меняют API, и после наката вдруг «отваливаются» сервисные сценарии. С другой — глубокое методологическое тестирование каждой комбинации стека многократно увеличивает стоимость владения, а выбора у архитекторов немного: сложные бизнес-процессы, зависимость от базовых систем вроде 1С или CRM и давление сроков заставляют идти на осознанный риск. В результате импортозамещение оказывается постоянным балансированием между архитектурной дисциплиной и объективными ограничениями рынка.
Между договором и реальностью
Разговор об архитектуре и качестве релизов вывел участников к еще одному болезненному сюжету: где заканчивается зона ответственности заказчика и начинается ответственность вендора и интегратора, если выбранное решение так и не стало полноценным боевым?
Юридически все предельно приземленно: «как написано в договоре». И именно здесь часто закладываются будущие проблемы. В формулировке «и т.д.» можно спрятать до 90% объема работ, и дальше каждая сторона будет трактовать этот «хвост» по-своему. Игорь Орлов подчеркивает, что злоупотребления с любой стороны — заказчика, партнера или вендора — в итоге убивают проект: интегратор, однажды уйдя «в минус», в следующий подобный заход больше не пойдет, неудовлетворенный заказчик включит сарафанное радио, а вендор, не видя спроса, свернет направление. Отсюда простой вывод: нужны и грамотные договоры, и ответственное управление проектами, и публичное признание тех кейсов, где все получилось — с российскими продуктами «ни разу не хуже западных», будь то 1С, отраслевые решения или набирающие обороты инструменты вроде RuDesktop, о которых «до ограничений почти никто не знал».
Со стороны вендора Михаил Зарембо предлагает смотреть на внедрение как на работу хорошо выстроенного ресторана. Производитель ПО — это поставщик продуктов и автор «меню» (функционала, API, SDK). Заказчик — владелец ресторана, который понимает, что нужно гостям и какую атмосферу он хочет получить, то есть задает бизнес-процессы и сценарии. Интегратор в этой модели — шеф-повар, который из имеющихся ингредиентов и возможностей кухни обязан «сварить блюдо», устраивающее всех. От качества «продуктов» и «ножей» — кода, документации, стабильности API — напрямую зависит результат. В интеграционной реальности, где все связано через API, любые незадокументированные изменения в интерфейсах неминуемо бьют по стыкам. Поэтому базовая обязанность вендора — не только часто обновлять продукт, но и дисциплинированно сопровождать изменения документацией и поддержкой.
Интегратор, по его словам, отвечает не за абстрактное «все настроим», а за доказательство того, что конкретные бизнес-сценарии заказчика реально выполняются на новом стеке. Половина проекта интеграции — это техника (руки и экспертиза вендора и партнера), вторая половина — организация: инвентаризация процессов, план миграции, работа с пользователями. Переезд, например, почтовой системы — в первую очередь организационный процесс: «инструментарий у нас есть, но при неправильной организации он не спасет».
На этом фоне особенно опасной выглядит популярная привычка «оставить пилот и объявить его продом». Так, пилот, который без полноценного проекта просто превращают в боевую систему, в 90% случаев заканчивается инцидентами. Корректная последовательность другая: пилот — для проверки гипотез и сценариев, затем отдельный проект внедрения с паспортами, документацией, повторной настройкой и, желательно, с участием вендора на правах надзора. Именно в такой триаде — осознанный заказчик, дисциплинированный вендор и сильный интегратор — границы ответственности становятся прозрачнее, а риск «не долететь до продакшена» заметно снижается.
На вопрос, где проходит граница ответственности, когда импортозамещающее решение «не взлетает», участники признали: формально все решает договор, но по факту виноваты обычно все трое — заказчик, интегратор и вендор. Потому что каждая сторона часто действует «с легкой бесшабашностью»: заказчик думает, что «и так понятно, штука классная, они точно смогут», интегратор — что «вроде рядом делали, давайте приклеим и здесь», вендор — что «за полгодика доработаем, точно получится». В результате все трое оказываются «обманутыми в ожиданиях».
На крупных внедрениях это особенно заметно. Бывают проекты, где два года только описывают процессы и пишут требования, а к моменту старта половина реальности уже изменилась: бизнес-процессы перестроились, пришли новые инициативы — и даже идеальный по бумаге проект несет в себе высокий, пусть и «здоровый», риск. Сюда же накладывается проблема roadmap'ов. По словам Кирилла Тимофеева, планы вендора — это всегда намерение, а не обязательство: «некоторые фишки мы ждем третий год, хотя в дорожной карте они давно обещаны».
Но если какая-то функция из roadmap критична, ее место — не в маркетинговой презентации, а в договоре. «Мы покупаем решение при условии, что к 1 августа эта функция появляется, а если нет — возвращаем деньги» — такой формат, по мнению Антона Кузнецова, единственный способ превратить намерения в обязательства. Соглашается он и с тем, что формально «виноваты все», но акцент все же смещает в сторону заказчика. Если компания плохо понимает собственные процессы и потребности, ей очень легко «продать не то». Там, где у заказчика есть зрелая практика скаутинга и предварительной экспертизы — как в крупных банках или госкорпорациях, которые годами исследуют рынок перед внедрением, — риск промаха сильно ниже.
Вендоры и интеграторы при этом не освобождены от ответственности: от них ждут вовлеченной работы с требованиями, умения объяснять, какие ожидания нереалистичны, и проговаривать то, что самим кажется «очевидным». Но без осмысленной позиции ИТ-директора на стороне заказчика баланс не складывается.
Баланс между покупкой и разработкой
Тема выбора между «коробкой» и собственной разработкой неожиданно оказалась одной из самых острых. Практика показывает: идеального готового решения, которое полностью закрывает потребности бизнеса, чаще всего нет — и так было еще до массового ухода западных вендоров. В итоге ИТ-директору приходится балансировать между двумя рисками: опереться на продукт с живым roadmap'ом (который по сути остается обещанием, а не гарантией) или ввязаться в разработку своего решения и взять на себя весь будущий технический долг.
По словам Максима Гречука, отправная точка — доля покрываемых требований и сложность процесса. Если продукт закрывает 70–80% критичных потребностей, логикой становится «допустимый уровень замещения» и разумный компромисс: жить с коробкой, постепенно донаращивая функциональность, в том числе за счет доработок у вендора. Когда же покрытие едва дотягивает до половины, приходится искать собственную архитектуру: брать простое решение и допиливать вокруг него. Один из кейсов Максима — интеграция 1С и Битрикс, которую на тот момент «из коробки» заставить работать не удалось. Пришлось строить слой микросервисов, и уже через полтора года в компании летало полторы сотни таких связок. Вендоры позже «догнали» и улучшили стандартную интеграцию, но нужный бизнес-эффект компания получила задолго до этого: пользователи начали пользоваться сервисом и получать пользу здесь и сейчас.
Но у такой стратегии есть теневая сторона. Собственная разработка легко превращается в черную дыру ресурсов и может «убить основной бизнес». Разработка — отдельный профессиональный мир со своей культурой, процессами и требованиями. Даже сильная команда программистов не обязательно понимает доменную область и не обязана приживаться в производственной, торговой или медицинской компании. Быстро «на коленке» написанный продукт редко оказывается готов к долгой жизни: его нужно сопровождать, чинить, адаптировать под новые задачи. Для малого и среднего бизнеса это нередко путь к тому, чтобы похоронить компанию вместе с неудачным продуктом. Решение идти в собственную разработку, подчеркивает Игорь Орлов, — это вопрос осознанного принятия риска на уровне владельца или генерального директора.
Михаил Зарембо предлагает называть внутреннюю разработку «авансом в счет будущего техдолга». Скорость получается здесь и сейчас, но расплачиваться потом придется годами: поддержкой, интеграциями, безопасностью. В качестве фильтра он предлагает несколько простых вопросов: насколько критична система для бизнеса, насколько глубоко она интегрируется с другими ИТ-системами и не снижает ли уровень безопасности. Следующий блок вопросов — про зрелость самой компании: есть ли деньги, опыт разработки, продуктовые и аналитические команды, которые понимают, что именно нужно бизнесу, и могут этим управлять, а не просто «запилить фичу». Если на этих этапах появляются сомнения, рациональнее выбирать коробочное решение с понятной экосистемой и жить в логике совместной эволюции продукта и roadmap'а, а не в логике «сами напишем лучше».
При этом участники сходятся в том, что полностью уйти от собственной разработки все равно не получится. Потому что российский рынок исторически живет в логике «уникальных бизнес-процессов»: даже компании одного масштаба в одной отрасли зачастую работают по-разному. В такой реальности здравый компромисс — иметь небольшую внутреннюю команду автоматизации, которая сшивает между собой разные продукты и микросервисы, но не превращается в фабрику по созданию «своих Jira и Slack». Чем глубже собственный код влезает в базовые системы, тем выше риск легаси, которое потом мешает обновляться и ломает стандартные интеграции.
Размер компании и горизонт планирования тоже сильно влияют на выбор. Для небольшого частного бизнеса, собственная разработка может быть оправдана только тогда, когда автоматизация быстро принесет дополнительный доход и компания готова дисциплинированно ее вести: документировать решения, регулярно сравнивать их с рынком и не держать в проде «самописку двухтысячных» только потому, что «мы так привыкли». Для крупных игроков и вендоров сценарий «залить деньгами» возможен, но и там возврат инвестиций тянется годами. Даже гигантам сложно окупить внутренние разработки, когда они пытаются продавать их вовне.
Фактически граница между «покупаем» и «пишем сами» в этой дискуссии описывается не в терминах технологий, а в терминах зрелости: управленческой, архитектурной и финансовой. Если у компании есть четкое понимание своих процессов, готовность брать на себя долгосрочные обязательства по развитию продукта и ресурсы на это — собственная разработка может стать конкурентным преимуществом. Во всех остальных случаях разумнее считать коробочные решения не компромиссом, а способом не превратить импортозамещение в дорогостоящий эксперимент с непредсказуемым финалом.
***
В финале дискуссии участники сходятся в важной оговорке: с российским ПО «все не так плохо», как иногда принято говорить. Есть сильные продукты и области, где о зарубежных альтернативах уже давно никто не вспоминает. Но при этом сохраняется целый набор ограничений. Главное из них — перенасыщенный рынок, где слишком много похожих решений, часть которых, по общему ощущению, должна постепенно уйти. В этих условиях выбор платформы для CIO превращается в лотерею: даже при аккуратной проработке стека всегда остается риск сделать ставку на продукт, который через пару лет перестанет развиваться.
Второй пласт проблем — культура разработки и тестирования. Даже зрелые команды вендоров грешат быстрыми релизами, не всегда успевают отрабатывать совместимость и документировать изменения, а заказчики не всегда выдерживают дисциплину стейджинга и внутренних испытаний перед обновлением боевого контура. В результате на одной стороне — перегретый рынок и спешка вендоров, на другой — уязвимая архитектура, которой сложно жить без «песочницы» и четких регламентов.
Обсуждение показало, что путь от формального «закрыли импорт» к честному «реально работает» лежит где-то посередине между этими крайностями. Это и более трезвый выбор продуктов в условиях избытка, и повышение требований к культуре разработки и тестирования, и готовность самих заказчиков инвестировать в архитектуру, стейджинг и диалог с вендорами.