Поделиться
Анастасия Барджеева: Технологическое совершенство не гарантирует выживание продукта на рынке
По оценкам экспертов, технология «низкого кода» (low‑code) и генеративный ИИ уже сокращают время вывода новых функций с месяцев до недель, и в 2026 г. это становится нормой для зрелых команд. На этом фоне резко растёт цена ошибки в релизах: каждый сбой или задержка вывода продукта на рынок напрямую бьёт по выручке и репутации. Над этой проблемой в последние годы работает delivery manager (эксперт по управлению процессами разработки и поставки, проектирующий систему изменений и отвечающий за устойчивость и предсказуемость всего жизненного цикла разработки продукта) и ментор технологических команд Анастасия Барджеева, запуская масштабные высоконагруженные проекты в условиях ограниченных ресурсов и нестабильной внешней экономической ситуации. Как выстраивать предсказуемый выпуск релизов, что помогает превратить рост цифровых инвестиций в стабильные изменения в продакшене и почему без участия системного лидера, отвечающего за процессы разработки и поставки, система никогда не станет по-настоящему стабильной — в интервью с экспертом.
CNews: Анастасия, ИТ-рынок сейчас живет в парадоксе: инструментов для ускорения разработки стало больше, но предсказуемость релизов в крупных проектах по-прежнему остается одной из главных болей бизнеса. Часто считается, что стабильность системы — зона ответственности инженеров, а сроки — менеджеров. По вашему опыту, к чему приводит такое разделение и насколько оно эффективно в 2026 году?
Анастасия Барджеева: Разделение ответственности на «техническую» и «административную» в современных высоконагруженных системах приводит к системной деградации: архитектура развивается отдельно от процессов поставки, а бизнес — отдельно от технологических ограничений. Стабильность продукта — это не только качество кода, но и зрелость жизненного цикла разработки ПО, прозрачность управления изменениями и контролируемая стоимость изменений (cost of change). Именно поэтому роль эксперта по управлению процессами разработки и поставки трансформируется в роль архитектора процессов поставки — человека, который проектирует систему изменений так же осознанно, как CTO проектирует техническую архитектуру. Без системного подхода бизнес получает либо «идеальный долгострой», либо нестабильный продукт, неспособный к масштабированию и устойчивому развитию.
CNews: Вы управляли рядом крупных ИТ-проектов с разной спецификой — например, портал Роструда для бесплатного поиска работы и коммерческие продукты игровой индустрии. Какую общую проблему вы нащупали при реализации проектов в коммерческих и гос.структурах и как удалось её решить?
Анастасия Барджеева: Основная проблема — непредсказуемо долгий вывод продукта на рынок при формально корректной архитектуре. Сроки удалось сократить на треть за счёт более точной проработки требований и процессов на старте. Грань между пользой и бюрократией проходит там, где документация перестает отвечать на вопрос «как это работает в связке» и начинает описывать очевидные вещи. Аналитика должна снижать риски и ускорять команду, а не существовать лишь для отчетности. Задача системного управления процессами разработки и поставки — сохранить этот баланс. В одном из проектов нам удалось сократить время, за которое идея превращается в работающий продукт в руках пользователей почти на 30% за счёт ранней декомпозиции рисков и выстраивания прозрачного потока поставки. В продуктовых B2B-проектах это позволило выводить решения в продакшен за 6–9 месяцев от концепции, поддерживая при этом высокий уровень доступности (uptime 99,9%) и предсказуемость релизного цикла.
CNews: Сфера онлайн-гейминга, в которой вы работаете уже несколько лет, — жесткая регулируемая среда с традиционно большим числом пользователей. Один из продуктов попал в шорт-листы нескольких международных премий. С какими сложностями вы столкнулись в этом проекте, и что помогло справиться?
Анастасия Барджеева: Сложность заключалась в том, что необходимо было спроектировать универсальную архитектуру, позволяющую предоставить единый и стабильный интерфейс для интеграции операторов и при этом обеспечить возможность подключения любых типов игр от различных провайдеров без мажорных изменений системы. Ключевой задачей было выстроить интеграционную модель, при которой подключение нового провайдера не требовало архитектурного рефакторинга и не влияло на стабильность продакшена. Кроме того, система проектировалась с учётом регуляторных требований сертификации, а помимо функциональности оценивались скорость релизов и устойчивость платформы. В таких случаях удается справиться при помощи анализа рыночных архитектурных решений и интеграционных практик, что позволяет спроектировать архитектуру и интерфейсы, учитывающие особенности работы с разными провайдерами и не противоречащие регуляторным требованиям.
CNews: В процессе работы над сложными ИТ-продуктами вы сформулировали воспроизводимую модель организации среды разработки и поставки изменения, которую так и называете environments & delivery flow, в переводе «организация сред разработки и поток поставки изменений». Какие ее элементы позволяют обеспечивать стабильность продукта без снижения темпа релизов?
Анастасия Барджеева: Я рассматриваю эту модель как часть общей архитектуры продукта — не как операционный инструмент, а как структурный слой системы, влияющий на устойчивость, скорость изменений и стоимость сопровождения. Эта модель формировалась на практике при запуске высоконагруженных B2B-систем и показала воспроизводимый результат в разных проектах. Один из ключевых блоков — методика выстраивания среды разработки и поставки. Она включает оптимальную модель использования окружений с учётом требований безопасности, лицензирования и особенностей разных юрисдикций, а также формализованные процессы релизов и оперативных исправлений. Кроме того, важно придерживаться системы уровней требований, использовать шаблоны постановки задач под разные цели (бизнес, разработка, интеграции) и единые принципы описания логики и ограничений. Такой подход позволяет сократить количество ошибок на этапе реализации, упростить коммуникацию между командами и эффективно распараллелить процесс разработки.
Отдельная методика связана с выстраиванием процессов разработки (SDLC), работы с бэклогом и рисками. Для заказной разработки она фокусируется на ранней проработке объёма, рисков и ресурсов, а для продуктовой — на гибком управлении бэклогом, приоритизации и устойчивости поставки в условиях постоянных изменений.
CNews: Насколько понимаю, эти принципы вы использовали и в работе над одной из высоконагруженных подсистем информационного госпортала «Работа России» в разгар пандемии, когда ресурсы экстренно перенаправлялись на поддержку населения. Как вы перестраивали процессы, чтобы внешние факторы буквально не похоронили сроки реализации федерального проекта?
Анастасия Барджеева: Реализация проекта «Стажировки и практик» стала для нас уникальным опытом работы в абсолютной неопределенности, его удалось запустить менее, чем за год. С жесткими условиями тогда столкнулись буквально все ИТ-компании, но как показала практика, чем жестче условия, тем более гибким и выверенным должно быть управление. Чтобы минимизировать воздействие неблагоприятных внешних факторов, необходимо максимально четко выделить «критический путь» проекта и синхронизировать архитектурные, ресурсные и регуляторные ограничения в единой модели управления. Успех в таких условиях обеспечивается за счет гибкости процессов и прозрачной коммуникации со стейкхолдерами. Если бы мы действовали иначе, выпустить минимально жизнеспособный продукт проекта за 8 месяцев при высокой неопределенности и дефиците ресурсов было бы невозможно.
CNews: При реализации таких проектов, как «Работа России», руководители обычно сталкиваются с конфликтом требований сразу нескольких сторон. Какие инструменты вы используете, чтобы снимать такие противоречия еще на этапе прототипа?
Анастасия Барджеева: Здесь также важна системность. В первую очередь необходимо зафиксировать всех стейкхолдеров и их цели, а затем свести требования в единую модель — с отображением потоков данных, зон ответственности и точек пересечения интересов.
Далее важно совместно пройти пользовательские сценарии и прототипы, чтобы выявить противоречия на уровне логики и архитектуры взаимодействия, а не уже в коде.
На этапе макетов стороны договариваются о распределении ответственности и допустимых компромиссах. Такой подход позволяет управлять конфликтами требований на ранней стадии, когда стоимость изменений минимальна.
Если этого не сделать в начале, противоречия неизбежно проявятся позже, но их устранение будет значительно дороже и рискованнее для проекта.
CNews: В вашей карьере был период, когда вы полгода замещали CTO — редкий опыт для менеджера поставки. По вашим наблюдениям, насколько на практике конфликтуют фокусы этих ролей?
Анастасия Барджеева: Я воспринимаю эти роли не как конкурирующие, а как взаимодополняющие элементы системы управления цифровым продуктом. Конфликт между руководителем процессов разработки и поставки и CTO возникает только в незрелых системах управления. В зрелой организации технологическая архитектура и архитектура поставки проектируются как единая модель. CTO отвечает за технологическую устойчивость и архитектурный задел, а лидер процессов разработки и поставки — за управляемость изменений, контролируемую стоимость изменений и скорость реализации ценности для бизнеса.
CNews: Учитывая ваш опыт работы и в госсекторе, и в коммерческих системах с высокими нагрузками, как, по-вашему, изменится роль менеджмента поставок в ближайшие годы?
Анастасия Барджеева: Во-первых, в ежедневной работе станет значительно больше аналитики и инструментов ИИ, позволяющих прогнозировать риски и управлять скоростью изменений. Во-вторых, будет расти ожидание, что руководитель процессов разработки и поставки отвечает не только за координацию, но и за устойчивый поток изменений: управление техническим долгом, стандарты качества, автоматизацию и сквозные метрики по всему жизненному циклу разработки. В-третьих, роль станет более продуктовой и стратегической — связующим звеном между архитектурой, продуктом и бизнесом, переводящим технологические решения в язык рисков, инвестиций и скорости вывода ценности на рынок. В ближайшие годы конкурентное преимущество будет не у компаний, которые быстрее пишут код, а у тех, кто умеет системно управлять скоростью изменений. Менеджмент поставки трансформируется из координационной в архитектурную функцию, отвечающую за устойчивость цифровых систем, прозрачность изменений и предсказуемость бизнес-результата.
Короткая ссылка
