От продуктов к потребностям. Как меняется работа команд

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

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

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

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

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

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

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

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

Для оценки экономики я показываю отдельный условный пример, с вкладом, инвестициями и страхованием жизни. Вклад с вероятностью оформления 60% и ожидаемой чистой приведённой стоимостью (NPV) 5 000 даёт взвешенный вклад 3 000. Для инвестиций 25% от 8 000 дают 2 000. Для полиса 10% от 15 000 дают 1 500. Сумма в этой упрощённой модели — 6 500 ожидаемой ценности отношений с клиентом.

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

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

По моим наблюдениям в 2025–2026 годах, после перестановок долго обсуждали, за что отвечают руководители и с кем договариваться для выполнения конкретных задач. За изменениями в бизнесе последовали перестановки в ИТ. Часть управленческих привычек сохранилась, а согласований в некоторых случаях стало больше. Так сложность модели превратилась в издержки ежедневной работы.

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

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