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