Time to market, т.е время доведения новой разработки до пользователя — один из ключевых параметров создания любого продукта. В банках это касается и разработки бэк-офисных продуктов, и доработки фронтальных (в мобильных приложениях или WEB). Мы поговорим о разных типах решений.

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

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

Рассмотрим стандартную ситуацию: есть команда проекта, и она его делает. В последние полтора десятилетия в крупных банках команды живут в режиме спринтов длительностью 2-4 недели. Но чтобы внедрить продукт, команда и продуктолог взаимодействуют с другими подразделениями: юристами, комплаенсом, ИБ, IT, со всеми их обязательными процедурами и «ритуалами». Причем эти службы чаще работают не по спринтам и живут по своему таймлайну.

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

Рассмотрим Т-Банк (тогда еще «Тинькофф») в период его роста, 10–15 лет назад. Важная задача ставилась и контролировалась зачастую с самого верха — и к команде исполнителей, и к команде согласующих структур мог «спуститься» менеджер высокого ранга и оперативно одобрить, продвинуть, протолкнуть внедрение. Забавно, что конкретные доработки, фичи продуктов в таких «живых» системах могут быть оперативно согласованы и внедрены, в то время как у крупных игроков эти же бизнес-требования будут отправлены в корзину.

Банки из топ-10 имеют свои процессные правила игры. Здесь могут работать десятки и даже сотни продуктовых команд, и у каждой свои приоритеты. Здесь и задачи повышения доходности в течение какого-то количества месяцев, и нормативные регуляторные требования. Регуляторика тоже имеет жесткие даты внедрения и не подлежит переносу, а задачи обоих типов зачастую нужно завершить срочно, к концу текущего продуктового спринта. И все эти задачи с сотней высоких приоритетов сталкиваются в «узком горлышке» — у согласующих структур.

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

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

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

Показательный пример — европейский опыт. В 2025 году Европейский центробанк временно ограничил Revolut в запуске новых продуктов из-за недостатков в их approval-процессах (процессах согласования). Это показывает, что проблема не только внутренняя, но и внешняя — регуляторы тоже следят за тем, как банки согласовывают новое.

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

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