Почему сильные специалисты не всегда создают сильные команды: опыт руководителя финтех-проектов

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

Фото: из личного архива Ирины Титовой

Ирина Титова, руководитель проектного офиса

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

Ирина Титова, руководитель проектного офиса, более 15 лет работает на стыке IT и финтеха. В ее опыте управление распределенными командами численностью более 60 специалистов, построение проектных офисов в крупных финансовых компаниях и развитие модели "единого окна" между бизнесом и IT. В международных финтех-проектах ее управленческие подходы помогали сокращать сроки вывода продуктов на рынок и делать работу команд более предсказуемой.

В интервью Pravda.ru Ирина Титова объяснила, почему в финтехе недостаточно быть сильным специалистом только в своей области, как управлять проектами на разных рынках и почему скорость разработки начинается не с ускорения работы программистов, а с умения команды видеть общую картину.

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

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

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

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

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

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

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

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

Это не попытка сделать каждого универсальным специалистом. Глубокая экспертиза остается основой. Но без понимания смежных областей она не всегда превращается в результат для бизнеса.

— Вы руководили запуском финансовых продуктов в шести странах. Что международные проекты показывают о роли такого подхода?

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

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

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

— Можно ли сказать, что регулирование становится частью самого финансового продукта?

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

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

Я не считаю, что скорость и контроль противоречат друг другу. Зрелая команда движется быстро именно потому, что заранее понимает обязательные ограничения.

— Почему менеджеру и аналитику недостаточно полагаться только на разработчиков в вопросах технологий?

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

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

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

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

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

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

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

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

— В ваших проектах удавалось существенно сокращать сроки вывода продуктов на рынок. Что именно приходилось менять?

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

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

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

— Какие компетенции особенно важны для руководителя проектного офиса и как компаниям развивать таких специалистов?

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

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

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

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

— Как понять, что развитие таких компетенций дает результат?

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

Важен и срок вывода продукта на рынок. Если команда лучше понимает взаимосвязи между функциями, она быстрее принимает решения и меньше времени тратит на исправление ошибок, которые можно было предотвратить.

Еще один результат — доверие между бизнесом и IT. Когда технологическая команда умеет говорить не только о сроках и ограничениях, но и о продукте, рисках и бизнес-результате, она становится полноценным партнером бизнеса.

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

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