Проверка регуляторностью. Кирилл Багдасарян — о работе при дефиците времени

Почему дефицит ресурсов – не однозначно проигрышная позиция? Как отличить управление от имитации? И зачем менеджеру учиться говорить «нет»?

Кирилл Багдасарян, руководитель системного и бизнес-анализа в большом финтехе, осенью 2025 года реализовал проект автоматизации банковской отчётности перед ЦБ РФ в условиях жёсткого дедлайна и ограниченных ресурсов. Проект затронул сразу несколько бизнес-направлений и ИТ-контуров: в него были вовлечены команды аналитики, разработки, тестирования, архитектуры, сопровождения, а также представители профильных бизнес-подразделений, отвечающих за корректность регуляторных данных. В общей сложности работа велась на стыке нескольких систем-источников, витрин данных и внутренних расчётных модулей, что делало проект комплексной перестройкой процесса подготовки отчётности.

О том, какие управленческие решения работают, когда время на исходе, а цена ошибки измеряется миллионами, Багдасарян рассказал «Аргументам и фактам».

Нельзя параллелить задачи

— Ваш проект по автоматизации отчётности перед ЦБ РФ осенью 2025 года часто приводят как пример работы в цейтноте. С чего начинается правильная реакция руководителя, когда сроки горят, а ресурсов объективно не хватает?

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

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

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

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

Управление и имитация

— То есть вы сознательно пошли на сужение коммуникации в тот момент, когда многие руководители, наоборот, требовали её расширить?

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

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

Чтобы это не превратилось в «ручное управление», я ввёл короткий, но жёсткий коммуникационный контур: ежедневная синхронизация только по блокирующим вопросам, отдельный канал для решений, влияющих на сроки или архитектуру, и единая точка входа для внешних запросов. В результате специалисты перестали тратить значительную часть дня на уточнения и переключения между контекстами.

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

Из плоскости мнений в плоскость правил

— Часто ли корень проблем в проектах банковской отчётности заключается в том, что одно и то же требование регулятора может трактоваться различными участниками процесса по-разному?

— Практически всегда. Нормативные документы регулятора масштабны и обладают высокой степенью детализации. При интерпретации этих требований разные участники — от представителей бизнеса до ИТ-архитекторов и разработчиков — могут смотреть на реализацию под разным углом.

Самое опасное здесь то, что расхождения взглядов могут долго маскироваться и всплыть только на этапе финального тестирования и валидации данных. А на этой стадии исправлять архитектуру и алгоритмы уже слишком долго и дорого. Поэтому выработку единого подхода я считаю процессной задачей. Мы чётко фиксируем границы ответственности команд и их систем, в каждой назначаем конкретного эксперта за реализацию релевантного набора требований ЦБ РФ, и в обязательном порядке документируем все заключённые договорённости.

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

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

Работающий инструмент

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

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

Мы ввели прозрачные правила жизненного цикла задачи: зафиксировали, в каком виде она поступает в работу, как распределяется ответственность по ходу её реализации, и по каким критериям (Definition of Done) она считается готовой к передаче дальше. Подобная стандартизация исключает потерю фокуса, снижает градус напряжения в команде и делает рабочий процесс предсказуемым.

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

После завершения проекта эти практики начали использоваться и в смежных командах, которые работали с данными, интеграциями и регуляторными изменениями. Фактически набор локальных проектных правил стал внутренним стандартом для похожих инициатив: его адаптировали для задач, где требовались прозрачная трассировка требований, понятные критерии готовности и управляемая коммуникация между бизнесом и ИТ.

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

Критически важна гибкость

— Можно ли сказать, что регуляторная отчётность в таком случае становится проверкой зрелости внутренних процессов?

— Абсолютно. Я часто говорю, что регуляторная отчётность — это качественная проверка процессов. Она очень быстро показывает, где в компании есть разрывы: в данных, в ответственности, в коммуникации, в документации или в архитектуре систем. Если процесс не описан, если владелец показателя не определён, если источник данных не зафиксирован, это обязательно проявится при подготовке отчётности.

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

— У вас в планах запуск собственных технологических проектов. Какой подход к формированию команды вы считаете наиболее эффективным для стартапа?

— Моя ставка — на специалистов вше среднего уровня с высоким темпом обучения. Кандидаты, которых на рынке принято называть «звёздами», зачастую приносят с собой устоявшиеся корпоративные паттерны и определённую инерцию мышления. Для стартапа же критически важна гибкость: способность перестраивать процессы на ходу, перестраиваясь под них самостоятельно, а также готовность быстро отказываться от стабильности в угоду роста.

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

Опыт с регуляторной отчётностью только усилил это убеждение. В сложных проектах выигрывает не тот, кто знает все ответы заранее, а тот, кто умеет быстро разобраться в новой предметной области, задать правильные вопросы и превратить неопределённость в понятный план действий. Для стартапа это особенно важно: там редко есть готовая методология, зато почти всегда есть нехватка времени, людей и права на долгие согласования.

— Что вы посоветуете системному аналитику, который хочет за несколько лет вырасти до руководителя в крупном финтехе?

— Перестать ждать идеальных условий — в живом бизнесе их просто не бывает. Главный навык, который необходимо развивать, — это проактивность, умение самостоятельно искать ответы на сложные вопросы и непрерывно самообучаться.

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

Ещё один важный навык — умение превращать свой личный опыт в повторяемые практики. Руководитель отличается от сильного исполнителя тем, что способен создать процесс, в котором команда будет стабильно получать качественный результат без постоянного ручного контроля. Именно поэтому я уделяю столько внимания регламентам, критериям готовности, фиксации решений и прозрачному распределению ответственности.

Если системный аналитик хочет расти, ему стоит учиться смотреть шире конкретной задачи: понимать, на какие системы она влияет, какие бизнес-риски закрывает, кто будет пользоваться результатом и как измерить качество реализации. Такой подход постепенно переводит специалиста из роли исполнителя требований в роль человека, который управляет изменениями.