В корпоративном кредитовании команды часто живут в двух реальностях. С одной стороны — безупречные бэкенд‑метрики, соблюдённые SLA и работающие по логам процессы. С другой — поддержка, которая ежедневно приносит пачки отзывов «Ничего не работает», и клиенты, которые уходят, потому что «всё сложно» и «непонятно».
Но здесь всё логично. Мы начинаем с вопроса «Какой экран сделать?» вместо «Какую задачу решает человек?». Мы оцениваем идеи через призму рисков и ограничений ещё до того, как успели их сформулировать. Мы строим карты экранов, а не пути клиента. Мы создаем фичи, которые никому не нужны, чтобы закрыть KPI, которые никого не волнуют. Проблемы не решаются, а экраны строятся.
Меня зовут Мия, я Digital Product Owner в корпоративном банкинге. Больше 20 лет в финтехе, сейчас развиваю продукты в корпоративном банке. Работаю на стыке UX, продукта и системной архитектуры: превращаю тяжелую банковскую логику в живые клиентские сценарии. Не верю в «фичи ради фич» и лишний балласт. Хороший продукт не путает человека, а помогает ему быстро принять решение и сделать следующий шаг. Вся суть — в умении вовремя спросить: для кого мы это делаем, какую задачу решаем и что будет потом.
В этой статье для продактов я описала несколько рабочих подходов, которые помогли нам расширить поле решений, увидеть клиента шире и найти точки роста там, где их обычно не ищут. Без дорогих исследований и без пересборки архитектуры. Под катом:
как «посадить осьминога» на кредитный комитет, чтобы сгенерировать продуктовые гипотезы;
как сделать бюджетный CJM силами команды разработки;
как метрика Time to Interactive помогла объяснить «призрачный» негатив клиентов, когда по бэкенд‑логам всё было «зелёное».
История №1. Осьминог на кредитном комитете: как мы искали продуктовые идеи с помощью МФО
Полгода назад, подводя итоги 2025 года и формируя цели на 2026‑й, я поставила перед собой задачу разработать продуктовую стратегию — долгосрочный вектор, который можно перевести в конкретные решения для клиентов и бизнеса. В скором времени был и вижен, и стратегия. Но, скорее всего вы знаете, что продуктовая стратегия отвечает на вопрос «Куда мы идём». Также, скорее всего, вы знаете, что она не объясняет, какие именно продукты, сервисы и процессы должны привести нас к этой цели.
Для этого нужно распаковать стратегию в продуктовые гипотезы: найти новые сценарии, посмотреть на привычные процессы под другим углом и понять, какие решения могут быть востребованы клиентами. В корпоративном кредитовании такая задача особенно непростая. Здесь есть устоявшийся профессиональный язык: лимиты, залоги, ковенанты, финансовая отчётность, риск‑аппетит, кредитные комитеты, регуляторные требования.
Эта система координат необходима для качественной работы. Но при поиске новых идей она же может слишком рано включать внутреннего критика, когда во время стандартного брейншторма в команде почти сразу включается конвергентное мышление, в котором участники начинают оценивать предложения ещё до того, как они сформулированы: «Это не пройдёт комплаенс», «Таких данных у нас нет», «Смежные системы не возьмут в работу», «Это слишком дорого». Порой чувствуешь себя Фаустом, разговаривающим с Мефистофелем: «Я — дух, всегда привыкший отрицать».
Но если вам уже надоело просто «допиливать» существующие продукты и хочется выбить команду из шаблонного мышления, попробуйте не обычный брейншторм, а метод фокальных объектов (МФО). Это метод генерации новых идей через перенос свойств случайных объектов на объект, который требуется усовершенствовать.
Фокальным он называется потому, что именно на исходном объекте сосредоточен весь перенос признаков. В МФО тренируется дивергентное мышление — расширение пространства вариантов. На этом этапе важны количество, разнообразие и неожиданные связи.
Метод состоит из нескольких последовательных действий:
Выбрать продукт, процесс или задачу, которую нужно переосмыслить.
Сформулировать цель изменений.
Случайно выбрать несколько объектов, не связанных с исходной задачей.
Выписать свойства и функции этих объектов.
Перенести свойства на фокальный объект.
Развить получившиеся сочетания в продуктовые гипотезы.
Оценить идеи и выбрать те, которые можно проверить.
Ключевой момент — случайные объекты не являются готовыми аналогами продукта. Они нужны как источник непривычных свойств.
Давайте покажу на примере.
Сформулировать кейс
МФО лучше начинать с чёткого описания задачи. Если этого не сделать, обсуждение быстро станет слишком абстрактным. В нашем случае фокальным объектом был процесс получения, использования и сопровождения оборотного финансирования для корпоративных клиентов.
Кейс сформулировали так: «Как сделать оборотное финансирование для среднего бизнеса более прозрачным, предсказуемым и адаптивным, не ухудшая качество кредитного портфеля и не увеличивая операционную нагрузку на банк?»
Это уже достаточно конкретная задача, она задаёт направление поиска.
Дальше задали контекст клиента. К примеру, у нас это была производственная компанию со следующими особенностями:
Выручка зависит от сезонности.
Закупки сырья нужно финансировать заранее.
Отгрузки клиентам происходят с отсрочкой платежа.
Часть оборотного капитала заморожена в запасах.
...
Важно своевременно информировать банк об изменениях в бизнесе и не допускать ухудшения качества портфеля.
На этапе генерации ограничения временно откладываются, но их всё равно нужно зафиксировать заранее. К примеру, у нас их было около десятки: кредитная политика, риск‑аппетит, требования регулирования, комплаенс и защита данных, доступность клиентских данных и т.д. и т.п.
Чтобы идеи не остались разговором, заранее определили, какой результат считаем полезным:
сокращение времени получения финансирования;
повышение прозрачности условий и доступного лимита;
рост использования одобренных лимитов;
снижение ручной работы;
более раннее обнаружение ухудшения финансового состояния;
сохранение или улучшение качества кредитного портфеля.
Как проходит сессия
Для сессии можно использовать генератор случайных слов, книгу, журнал, карточки или предметы, которые находятся в переговорной. Обычно достаточно 3‑5 объектов. Желательно, чтобы они были из разных областей и не напоминали банковские продукты. Например, осьминог, вулкан, гардероб, телескоп, муравейник.
В этой статье разберём один объект — осьминога. Он кажется особенно неподходящим для корпоративного кредитования, а значит, хорошо показывает механику метода.
На первом этапе мы не связываем объект с кредитованием. Просто описываем, как он устроен и как себя ведёт:
У него несколько щупалец.
Щупальца могут действовать параллельно.
Часть нервной системы распределена по телу.
Он быстро адаптируется к среде.
Меняет цвет и фактуру.
Исследует пространство через прикосновение.
Умеет прятаться
При угрозе выпускает чернила и меняет сценарий поведения.
Важно не ограничиваться очевидными прилагательными вроде «морской» или «мягкий». Для МФО полезнее свойства, функции и механики:
действует одновременно в нескольких направлениях;
реагирует локально;
подстраивается под обстоятельства;
получает информацию через множество контактов;
создаёт защитный манёвр;
меняет внешний сигнал в зависимости от ситуации.
Теперь начинаем переносить признаки на фокальный объект
На оборотное финансирование в нашем случае. У корпоративного клиента редко бывает только одна потребность в ликвидности. Одновременно ему могут требоваться деньги на:
закупку сырья;
финансирование запасов;
исполнение контракта;
выплату заработной платы;
закрытие кассового разрыва;
…
валютные платежи.
В традиционной конструкции все эти задачи могут обслуживаться одним общим лимитом. Клиент видит общую доступную сумму, а банк — единый объект кредитного риска.
Но переносим свойство «Несколько рук работают параллельно, но относятся к одному организму», и вот у нас есть гипотеза параллельных контуров финансирования:
закупочный подлимит;
контрактный подлимит;
сезонный подлимит;
лимит на краткосрочные кассовые разрывы;
отдельный лимит на гарантии или аккредитивы.
Все подлимиты могут входить в общий риск‑лимит клиента, но иметь разные цели, условия использования и триггеры контроля. Для клиента это может сделать структуру финансирования более понятной. Для банка — повысить прозрачность использования средств и точность оценки риска по отдельным потокам.
Примечание. Все свойства показывать нет смысла, статья выйдет чрезмерно объёмной, остановимся на одном.
Как из ассоциации получить проверяемую гипотезу
Перенос свойства — это только начало. Чтобы получить гипотезу, каждую ассоциацию нужно докрутить. Полезно задавать несколько последовательных вопросов:
Какое свойство мы перенесли?
Как оно могло бы проявляться в продукте?
Для какого клиента это имеет ценность?
Какую проблему клиента решает?
Какие данные или события запускают новый сценарий?
Что меняется в процессе?
Какие риски появляются?
Как проверить идею на небольшом пилоте?
Например, рассмотренное свойство про щупальца сначала даёт ассоциацию, что кредитный продукт должен иметь несколько независимых направлений использования. Но если идти дальше, то мы можем разделить единый лимит на подлимиты по бизнес‑задачам. А если ещё дальше, то — предоставить клиенту модульную структуру оборотного финансирования, где отдельные подлимиты имеют собственные параметры, но контролируются в рамках общего риск‑лимита.
Итоговая гипотеза такая: «Для компаний с несколькими параллельными потребностями в оборотном капитале протестировать структуру подлимитов по типам финансирования и сравнить её с единым лимитом по показателям прозрачности использования, скорости выборки, загрузки менеджеров и качества портфеля».
Так случайная ассоциация превращается в объект продуктовой проверки.
Как провести такую сессию у себя
До встречи нужно подготовить:
описание фокального объекта;
цель изменений;
краткое описание клиента и его проблемы;
список ограничений;
критерии оценки;
способ фиксации идей;
фасилитатора.
Желательно, чтобы в сессии участвовали люди с разной профессиональной оптикой: продукт, продажи, риск, операции, аналитика, ИТ и клиентский сервис. Но на этапе генерации их роли не должны превращать обсуждение в серию ранних запретов.
Этап генерации (45–60 минут):
представить кейс и объяснить правила;
выбрать 3–5 случайных объектов;
выписать свойства каждого объекта;
переносить свойства на фокальный объект;
фиксировать все идеи без критики;
развивать идеи уточняющими вопросами.
Ваша доска в Miro может выглядеть так:
Фасилитатору важно останавливать фразы вроде «Это невозможно» и «Так никто не делает». Вместо этого можно спросить:
«Представим, что это возможно. Как выглядел бы сценарий?»
«Какую проблему это решает?»
«Какая часть идеи кажется наиболее ценной?»
«Что из этого можно проверить без полноценной разработки?»
Этап отбора. После завершения генерации команда возвращается к конвергентному мышлению. Идеи можно оценить по пяти критериям (клиентская ценность, экономика, риск, право/комплаенс, реализуемость).
Необязательно сразу выбирать идею, которая набрала максимальный балл по всем критериям. Иногда ценность сессии как раз в том, чтобы обнаружить гипотезу с высокой клиентской ценностью, но требующую отдельной проверки данных или правовой модели.
К примеру, мы за одну сессию мы получили более 60 идей. Но количество не так важно. Две из трёх гипотез, скорее всего, не появились бы в стандартном обсуждении: они выглядели слишком нетипично для привычного языка корпоративного кредитования. А три прошли первичную фильтрацию и дошли до проработки прототипов.
Важно. Не любая странная ассоциация превращается в хорошую бизнес‑идею. Здесь дело в другом: МФО временно снимает ограничения с этапа генерации, чтобы команда получила более широкий набор вариантов, затем ограничения возвращаются в работу, а идея проверяется на клиентскую ценность, экономику, риск, право, данные, ИТ и операционную модель. |
Ограничения метода
У метода есть несколько ограничений.
Во‑первых, МФО плохо работает, если кейс сформулирован слишком широко. «Как улучшить корпоративное кредитование?» — плохая постановка. «Как сократить неопределённость клиента при использовании возобновляемого лимита?» — значительно лучше.
Во‑вторых, случайные объекты должны действительно быть случайными. Если команда заранее выбирает только «полезные» или технологичные предметы, метод быстро превращается в обычную аналогию.
В‑третьих, нельзя смешивать генерацию и оценку. Если специалист по рискам начинает комментировать каждую идею в момент её появления, команда снова возвращается в конвергентный режим.
В‑четвёртых, итогом должны быть не просто необычные сочетания, а проверяемые гипотезы. Иначе сессия останется хорошим упражнением на воображение.
Метод фокальных объектов — это не замена рискам и аналитике, а способ отключить внутренний стоп‑кран ещё до того, как идея родится. В корпоративном кредитовании мы привыкли сразу искать ограничения, из‑за чего часто просто «допиливаем» существующие продукты. Необычные метафоры вроде «осьминога» помогают выскочить из этой колеи и задать неудобные вопросы: «а что, если делать лимиты гибкими», «ловить сигналы бизнеса раньше отчётности» и уйти от крайностей «всё доступно или всё заблокировано»?
Смысл МФО в том, чтобы сначала выбить команду из шаблонного мышления и веером нагенерировать смелых решений, и только потом прогнать их через суровый фильтр корпоративной реальности.
Бонус‑кейсы с воркшопов: идеи, которые «созревали» вместе с рынком
Снятие налички на кассе магазинов
В своё время, на подобных воркшопах ещё в 2018 году, мы нагенерировали мысль, что можно было бы снимать деньги с карты на кассах магазинов. Тогда эта идея в прод не пошла, но уже в 2026‑м это рабочий способ получить наличку. Но некоторые идеи «созревают» вместе с рынком и инфраструктурой. Задача продакта — не убивать их сразу, а фиксировать и возвращаться, когда контекст изменится.
Досрочное погашение и онбординг в проблемных точках
Ещё одна из идей, которую придумали мои ребята на одном из треков, — онбординг клиента в процессах, где у него что‑то «подбуксовывает». Например, на этапе заявки что‑то не получается — может документы никак не хотят прикладываться к заявке. Тогда в моменте появляются подсказки, клиент проходит микро‑онбординг, и у него всё получается. Ведь часто проблема не в том, что клиент «не хочет», а в том, что он «не может» в конкретной точке пути. Микро‑онбординг в момент затруднения может дать больший эффект, чем общие инструкции на старте.
Жизнь клиента корпоративного кредитования простирается далеко за пределы сервиса. Я хочу дотянуться до клиента дальше, чем сейчас, и сделать его жизнь проще. На таких сессиях может прийти много идей по разным векторам. Не факт, что ты их сразу заберёшь в бэклог делать, но они тебе дадут стимул «на подумать». Вот основная идея этих воркшопов.
История №2. Как сделать CJM, когда оно стоит как крыло от самолёта
Хватит про осьминогов, давайте ближе к привычному — к CJM.
Когда мы начали писать стратегию на будущий год (из предыдущей истории), я подумала: а что, если посмотреть на сервис не как на набор экранов и виджетов, а как на отпечаток какого‑то этапа пользовательского пути и построить CJM: с чем пришёл, зачем и что делает потом.
Но классический узкий сценарий вроде «оформить заявку» нам не подходит, так как я — владелец высоконагруженного сервиса‑оркестратора в финтехе. Это сотни тысяч операций, сложная бизнес‑логика под капотом, множество точек входа в смежные сервисы и постоянная передача потоков данных другим системам. Также сервис участвует в нескольких этапах жизненного цикла корпоративного кредита:
осознание потребности — понять, сколько денег нужно привлечь, на каких условиях и в какие сроки;
подача и рассмотрение заявки — подать заявку, пройти проверки, отслеживать статусы;
оформление сделки — подписать документы и получить средства;
сопровождение и выборка — следить за остатком лимита, платежами, процентами и условиями договора;
рефинансирование или погашение — закрыть долг либо продлить финансирование на новых условиях.
Поэтому хотелось построить не карту одного экрана, а расширенную сквозную карту клиентского пути — от возникновения потребности в финансировании до погашения кредита и закрытия лимита. Настоящий CJM, а не набор экранов, который за него выдают.
Речь шла не об одном пользователе. На разных этапах со стороны клиента в процесс включаются CFO, генеральный директор, казначей, бухгалтер, юристы и прочие специалисты. То есть точнее говорить не о линейном пути одного пользователя, а о сквозном сервисном сценарии с разными ролями.
В теории для построения CJM вам нужны настоящие клиенты, потому что аббревиатура и расшифровывается как «карта пути пользователя». Построить CJM по‑классике — это сходить ножками к топ‑менеджерам, пробить рекрут, провести глубинные интервью, понаблюдать за работой клиентов, пройтись по реальным кейсам
Но наша аудитория — крупный корпоративный бизнес. В реальности это квест уровня «хард»: надо попробовать найти ЛПР какой‑нибудь авиакомпании, пробить стену службы безопасности, а потом, обойдя переносы и отмены, добраться до кабинета с табличкой «Оставь надежду, всяк сюда входящий». И вот твоё исследование умерло, так и не начавшись
, но не попало в ад, потому что оно уже там.
А гипотезы и понимание направления развития продукта нужны были команде уже вчера.
Как собрать настоящий путь от триггера до результата, если твоя ЦА — крупный корп?
Ответ: бюджетно.
Однажды я подготовила фрейм в Miro, где накидала сценарии, которые пользователи могут проходить в процессе корпоративного кредитования, а потом внезапно и без объявления собрала 20 человек из команд разработки (свою и смежную) — разработчиков, аналитиков, дизайнеров, — и разбила на группы, раздала этапы и отдала на разграбление два swimlane:
триггеры и мотивы: какую задачу юзер на самом деле пытается решить?
действия: что он делает фактически и где страдает от ручного труда?
Этапы кредитного процесса у юрлиц разбиваются на крупные блоки:
осознание потребности;
подача заявки, выбор банка для подачи заявки;
сам старт заявки;
заключение договора и так далее.
Каждой группе досталась часть этого этапа. Задача групп: заполнить этап по шаблону (триггер, цель, действия, инструменты, touchpoints).
И тут начался самый кайф. К примеру, одна группа представила:
«Я — казначей, в календаре стоит встреча, чтобы обсуждать инвестиционный проект, и мне, как казначею, нужно примерно понять, сколько средств компания может выбрать в текущий момент и сколько будет стоить финансирование по условиям договора; успеет ли компания получить деньги к дате платежа поставщику?»
Для этого казначею нужен рабочий инструмент: детальные данные по лимиту и сублимитам, процентные периоды, графики, экспорт в Excel, возможность подготовить бюджет или ПДДС, быстрый переход к оформлению транша. Его задача — корректно собрать данные, проверить их и провести операцию без ручных ошибок.
А потом в этой пьесе появился CFO. И ему не нужен экран, перегруженный деталями каждого транша и всеми графиками погашения, ему нужно понять, может ли компания позволить себе эту сделку и не упрётся ли в ограничения лимита?
Другая команда взяла этап выборки траншей и последующего мониторинга платежей. Они решили разложить этот этап на примере приезда Канье Веста. Смоделировали реальный аврал организатора: от суматошного поиска денег на выкуп билетов и перелёт команды до суровой рутины. На CJM вместо абстрактного шага «выдать кредит» нарисовали карту конкретных вех: отдельный транш под срочную бронь билетов, отдельный — под логистику и поездку. Для каждого этапа в карте четко зафиксировали жизненный повод, дату, подтверждающую бумагу и конкретный источник погашения — например, первые поступления от билетных операторов.
Отдельный блок карты посвятили мониторингу — периоду, когда деньги с продаж билетов ещё только начинают капать. На CJM отметили ключевые контрольные точки: скорость распродажи билетов, отчёты операторов и риск переноса концерта. Вышло максимально жизненно и наглядно — именно на таком «абсурдном» живом кейсе всплыло понимание, как сухая банковская логика работает в реальной жизни.
Канье к нам так и не приехал, но если что — мы не ждём, а готовимся.
В итоге выросла солидная простыня, которая начинается от осознавания потребности и заканчивается закрытием кредита.
В процессе вылезли такие глубокие мотивы, о которых даже я — РО с 20-летним бэкграундом в финтехе — не подумала бы с ходу.
Главный эффект воркшопа
Он в том, что мы увидели, насколько по‑разному внутри команды понимаем путь клиента.
Позже на карту мы наложили тачпойнты и искали дыры. Например, «клиент приходит не за отчётом, а за уверенностью». Если интерфейс в этот момент просто «выплёвывает» файл, он формально функцию выполнил, но реальную боль не закрыл.
Два часа воркшопа, на котором я «заставила» команду разработки представить себя на месте клиента — и у нас родилось десяток гипотез. Да, это пока не доказанные факты, а наши коллективные галлюцинации. Но теперь с этим объёмным, живым «монстриком» можно идти валидироваться об реальную ЦА, аналитику и саппорт.
А главный инсайт в том, что мы как раз определяем, что наш сервис далеко не везде достаёт клиента. Это раз.
Второе — у клиента могут быть в одном этапе совершенно две разные роли. Например, тот же ЛПР, у которого набор информации для принятия решения отличается от операционного сотрудника, которому нужно работать с операционной выборкой траншей.
Такие инсайты появились в ходе проработки. Я хотела вытряхнуть команду за пределы сервиса. Построить карту экрана в сервисе не сложно. Но это карта шагов в сервисе, а клиентский путь гораздо больше.
Ограничения внутреннего воркшопа
Воркшоп нельзя рассматривать как замену реального интервью с клиентом, потому что это некорректно. У внутреннего воркшопа есть серьёзные ограничения:
команда слишком хорошо знает систему изнутри;
участники говорят терминами продукта и баз данных, а не бизнеса клиента;
команда может бессознательно оправдывать неудобные решения;
внутренние процессы легко принять за пользовательские потребности;
красивая доска в Miro создаёт иллюзию, что мы уже знаем, как живут клиенты.
Поэтому такая карта не может быть истиной в последней инстанции. Она показывает не «как всё устроено на самом деле», а что команда предполагает и какие гипотезы нужно вынести на проверку. Об этом важно помнить.
Но до воркшопа на грумингах звучало «Давайте выведем на экран ещё один финансовый показатель», команда проектировала UI/UX из позиции «Смотрите, сколько у нас данных и что мы умеем», а за спиной тихо строилась фабрика фичей.
В своё время именно с этим явлением мы и столкнулись. Фабрика отлично демонстрировала технические возможности системы, но плохо помогала человеку выполнять работу, так как у команды не было единой картины пользовательского пути: владелец продукта, аналитики, разработчики и дизайнеры по‑разному представляли, что происходит с клиентом до клика по нашей кнопке, и что он делает после.
Сейчас у нас вопросы другие: «Какую задачу этот показатель решает? Для какой роли? На каком этапе? Что человек сделает с ним дальше?»
И, пожалуй, в этом главный смысл карты гипотез. Она не создаёт иллюзию знания, она показывает, где именно знаний пока не хватает.
Иногда первый полезный шаг в UX‑исследовании — не бежать сломя голову «в поля», а честно зафиксировать, что именно ваша команда думает о пользователе прямо сейчас. А потом пойти и проверить это на реальных клиентах. Но это уже совсем другая история.
История 3. Как метрика Time to Interactive помогла победить «призрачный» негатив клиентов
Любой крупный финтех — это баланс между идеальной архитектурой и скоростью Time‑to‑Market. Когда‑то давно для запуска сервиса был сделан базовый заявочный процесс:
клиент оформляет заявку в интерфейсе;
заявка последовательно проходит через 4 банковские системы;
на выходе она либо исполняется автоматически, либо попадает на ручную регистрацию сотруднику бэк‑офиса.
Главный нюанс: единой мастер‑системы со сквозной статусной моделью у процесса не было.
Построить полноценный сервисный слой статусной модели с хранением, перезаписью и агрегацией состояний из четырёх систем — дорого и долго. На этапе MVP бизнес выбрал дать клиенту цифровую функцию прямо сейчас, пусть и без красивой истории статусов. Это нормальный компромисс для запуска, но потом бывают последствия.
Последствиями были пачки негативных отзывов от пользователей, которые приносила поддержка, с одной и той же формулировкой — «Ничего не работает!». Если открыть логи, то видно, что заявки уходят, четыре банковские системы по цепочке успешно их обрабатывают, а операции исполняются. По договору у банка есть 2 дня на обработку (SLA), и система железобетонно укладывается в этот срок. Backend‑инженеры рапортуют, что всё штатно.
Но клиентский негатив продолжает расти, а фидбек «Ничего не работает» ясности не добавляет. Если по логам бэкенда всё проходит штатно, значит, проблема возникала ещё до отправки формы?
Как мы сместили фокус с серверных метрик на пользовательский опыт
Мы решили это проверить и сместили фокус с серверных метрик на пользовательский опыт и измерили Time to Interactive (TTI) — но не в классическом смысле общей готовности страницы, а точечно: разницу между моментом отрисовки страницы и моментом отрисовки нужного нам элемента — главной целевой кнопки. То есть не «когда страница в целом стала интерактивной», а конкретно «когда стала кликабельна кнопка, которая ведёт клиента дальше по сценарию».
Результаты замеров — это шок‑контент. Уберите от экранов детей, стажёров и джунов: средний TTI кнопки составлял 18 секунд.
Один час на планете Миллер равен семи годам на Земле. А 18 секунд ожидания кнопки в финтехе — это вечность для нервной системы клиента. За это время человек успевает сделать три глотка кофе, подумать, что страница «зависла» или сайт «сломался», яростно покликать по неактивной кнопке, закрыть вкладку и уйти писать разгневанный отзыв.
Наша гипотеза подтвердилась — клиенты сталкивались с раздражающей задержкой. Они считали сервис нерабочим ещё до того, как кнопка успевала разблокироваться. Отсюда и отзывы «Не работает». Пока ждёшь 18 секунд, можно действительно решить, что так и есть.
Что мы нашли в цепочке инициализации
Начав раскапывать цепочку инициализации страницы, мы обнаружили классическое легаси‑узкое место: для отрисовки и активации кнопки интерфейс обращался к старым хранимым процедурам в БД, которые прямо на лету рассчитывали сложные графики и условия на медленных таблицах. Хан Соло запускал гипердвигатель быстрее, чем наш интерфейс дожидался ответа от них ответа.
Пока этот тяжёлый расчёт не завершался, фронтенд не активировал ключевое действие.
Решение оказалось на удивление простым: мы перестали брать сложные графики из хранимых процедур и заменили их на остатки со счетов учётной системы — данные, которые уже есть в готовом виде и не требуют тяжёлых расчётов на лету. Тяжёлые вычисления полностью ушли из критического пути блокировки интерфейса.
Выводы
Не верьте только бэкенд‑логам. Если по метрикам сервера всё «зелёное», это не значит, что пользователь счастлив. Негатив может формироваться на этапе ожидания UI.
Ищите неочевидные метрики. Классический TTI меряет готовность страницы в целом, но в сложных интерфейсах полезнее замерять время до готовности конкретного ключевого элемента — той самой кнопки, от которой зависит следующий шаг клиента. Такая точечная метрика может влиять на конверсию и VoC сильнее, чем идеальный SLA самой бизнес‑операции.
Отсутствие сквозной статусной модели — не приговор. Даже если у вас нет бюджета на пересборку архитектуры и мастер‑систему статусов, оптимизация первичного взаимодействия (TTI) позволяет закрыть боль клиентов без миллионных инвестиций в бэкенд.
Заключение: что остаётся после таких историй
Продуктовая работа в корпоративном кредитовании — это не гонка за количеством фич, а искусство задавать правильные вопросы в нужный момент. Иногда самый ценный шаг — не бежать «в поля» и не заказывать дорогое исследование, а честно зафиксировать, что команда уже думает о клиенте, и проверить эти гипотезы.
Осьминог на сессии, «бюджетный CJM» на разработчиках и точечный TTI вместо классических отчётов — это не трюки, а способ сместить фокус с «что умеет система» на «какую задачу решает человек».
Если после этой статьи вы хотя бы раз спросите...:
«А какую проблему это решает?»
«Для какой роли?»
«На каком этапе?»
«Что человек сделает с этим дальше?» —
…значит, эти истории уже сработали.
Ваша задача как продакта — не знать все ответы, а создавать условия, в которых команда начинает видеть клиента и бизнес чуть шире, чем вчера.
Читайте также:
Штормить никогда не перестанет: почему реализация концепции спустя несколько лет — это нормально
Как мы сбежали из «KPI-караоке»: наш базовый минимум метрик, который реально работает