Анастасия Барджеева: "Программный код — это юридический механизм"

Лидер команд разработки и продуктового управления — о том, как превращать противоречивые требования государства и бизнеса в устойчивую ИТ-архитектуру и почему в гостехе аналитика важнее скорости.

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

Как строить системы, где за одним цифровым столом должны договориться несколько сторон? Как обеспечить прозрачность и отказоустойчивость там, где требования меняются быстрее, чем пишется код? Обсуждаем это с Анастасией Барджеевой, экспертом в области системного анализа, специалистом, который отвечает за организацию, координацию и контроль всего жизненного цикла разработки ИТ-продуктов. В её портфолио — запуск с нуля архитектурно сложных продуктов в условиях экстремально сжатых сроков. Один из наиболее знаковых кейсов — реализация подсистемы "Стажировки и практики" для портала "Работа России". В разгар пандемии, при дефиците ресурсов и противоречивых требованиях стейкхолдеров (от Минтруда до ведущих вузов страны, таких как МГУ), Анастасии удалось в сжатые сроки провести продукт от прототипа до промышленного запуска, создать устойчивую экосистему трехстороннего документооборота.

Анастасия, программный код в госсистемах становится юридическим механизмом. Как меняется подход к проектированию систем, если ошибка в логике обработки данных может иметь юридические последствия?

Подход меняется фундаментально: мы перестаем строить просто "удобные сервисы" и начинаем проектировать формализованные правовые алгоритмы, где логика системы становится эквивалентом юридической нормы. Если упростить — система не должна допускать двоякого толкования. В такой работе акцент смещается с производительности на прозрачность и детерминированность процессов. Любая неоднозначность в требованиях здесь превращается в реальный риск — от недействительности сделки до нарушения государственного регламента. Проектирование превращается в создание среды, где каждое действие можно проверить и однозначно интерпретировать, а системная аналитика становится фундаментом, который гарантирует, что цифровой путь документа в точности соответствует юридической логике вне зависимости от сложности инфраструктуры.

Для проекта "Работа России" вы самостоятельно разработали прототип и провели реализацию продукта. Этот кейс включал взаимодействие с госорганами, вузами и бизнесом. В чем была основная сложность? Как учитывать различия в процессах при разработке продукта со стейкхолдерами нескольких независимых сторон?

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

Вас приглашают к аудиту процессов, менторству менеджеров и аналитиков в компании разных уровней. Как вы рекомендуете решать технические и бюрократические споры в ситуациях, когда стейкхолдеры имеют противоположные требования?

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

Госпроекты часто считаются медленными в производстве. У вас же получилось сократить время вывода на треть со сниженным количеством критичных ошибок и доработок после релиза. Что помогает ускорить разработку и запуск?

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

В вашей карьере был период работы в крупном ИТ-холдинге, где вам доверили в одиночку вести продукт для госуправления от прототипа до выхода в продакшн. Как в условиях масштабной корпорации и сложного государственного заказа одному человеку удается не только выстроить архитектуру с нуля, но и фактически стать гарантом качества системы, миновав риски размытия ответственности?

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

Как менеджер поставки продукта вы находитесь в центре треугольника "Закон — Бизнес — Технологии". Какими инструментами должен пользоваться ответственный за реализацию продукта, чтобы требования законодательства не превращались в "костыли" в программном коде, а ожидания стейкхолдеров не нарушали архитектурную чистоту продукта?

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

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

Следующий шаг — переход от модели "запроса" к модели "события", где система начинает работать проактивно и становится незаметной для пользователя. Это означает переход от реактивных сервисов к проактивным системам. Нужно уйти от разрозненных витрин данных к единой инфраструктуре цифрового доверия, которая синхронизирует интересы государства и бизнеса в момент возникновения жизненной ситуации. Бесшовность появляется, когда системы разных ведомств и частных платформ начинают работать на общих принципах обмена смыслами, а не просто документами. В итоге пользователь перестает взаимодействовать с системой как с бюрократическим инструментом и начинает получать результат как сервис без лишних действий и барьеров.