Привет! Я Сеня, в лидирую AI‑команду в Точка Банке, которая работает с продажами и маркетингом. Наши модели и сервисы решают, какой менеджер должен ответить клиенту, кому дать промокод, кому показать ремаркетинг, что сказать клиенту на его возражение.
Моя команда появилась, когда ChatGPT ещё не существовала, а в моде был катбуст... По сути, в самом начале мы наняли несколько джуна и сказали: «придумайте, чем заняться, и попробуйте заработать денег». Заказчиков мы могли выбирать сами: вокруг нас были десятки команд, каждая из которых была уникальной, жила в своём стиле, отвечала за свои процессы, метрики и клиентов.
Теперь команда у нас кратно больше, в ней есть сеньоры, ROI крутейший, но и исчисление провалившихся с позором проектов идёт на много десятков.
Почему я решил написать эту статью и о чём она?
Когда живешь в такой команде, твой базовый вопрос — какие проекты делать, чтобы метрики выросли. Нам тогда рассказали, что есть такие ICE/WSJF/… Потом мы поняли, что на нашем уровне энтропии такие штуки — полная чушь (и дальше расскажу, почему). Встал вопрос, как иначе выбирать, какие проекты брать в работу.
Ответ мы ищем до сих пор, но хочется поделиться опытом наших ошибок для начинающих и продолжающих подобный путь.
В этой статье предложил фреймворк: как выбирать, где копать и что копать, если вы AI‑команда, которая должна зарабатывать деньги, но обладает свободой выбора.
Давайте признаем, что в индустрии есть множество AI‑команд, которые не стремятся к измерению пользы от своей работы и получают проекты в основном «сверху».
Почему в нашем случае нельзя просто использовать фреймворки типа ICE и наслаждаться жизнью
Приоритезации по ICE/WSJF/MoSCoW лучше работают на уровне фичей, чем направлений или продуктов в новом домене. Они в целом не подходят для большого уровня абстракции.
Если вы сформировали AI‑команду, и надо решить чем она будет заниматься, скорить по ICE придётся такие идеи:
Через AI генерировать коммерческие предложения (КП) для клиентов. Эти КП должны растить конверсию в покупку.
Подсказки менеджеру по продажам, что сказать клиенту на его возражения, чтобы добиваться роста конверсий.
На что подсказки будут влиять? Влияет ли КП на итоговый результат? Возможно ли проект сделать?
Скоринг будет либо пальцем в небо, либо вы потонете в месяцах аналитики в попытке снизить энтропию и выбрать оптимальный проект.
История из жизни. Однажды мы всё‑таки пытались использовать ICE, на доске у нас было 57 идей проектов. Сейчас зашёл на доску тех времен и сверил с реальностью проставленные тогда оценки импакта, простоты, реализовавшихся рисков и уверенности. Корреляция +-0.
Я не буду душиться и отдельно рассматривать альтернативы типа WSJF, но суть там похожая.
А что тогда делать?
Если непонятно, что делать, давайте для начала решим где делать — в каком домене и для какого процесса. Затем уже будем придумывать, чем займёмся в потенциально крутых доменах.
Этап 1: выбор домена
Решить, где и с кем надо что‑то делать, обычно сильно проще, чем выбрать конкретную идею.
История из жизни. При старте работы мы потонули в объёме контекста и идей, которые нам приносило множество смежных команд. Мы старались занести каждую на доску и отранжировать — и объём доски быстро перевалил за много десятков. В какой‑то момент мы бросили идею собрать все гипотезы, которые есть, на доску по всем смежным командам. Нам потребовалось снизить энтропию, ведь чтобы разобраться сразу и во всём и оценить каждую идею нужно было потратить много месяцев.
По итогу мы пришли к тому, что для начала надо выбрать домен — в нашем случае это каналы продаж. Выбирать легко, так как мы понимаем влияние каждого домена на бизнес: например, сколько клиентов идёт через него, их доходность. И, конечно, сложности, общие для всех идей в домене. У нас таких крупных доменов оказалось не больше 5. Мы сделали ставку на 2 из них и кратно сократили число гипотез, из которых надо было выбрать лучшие.
Алгоритм выбора домена:
Выбираем метрику, к которой будем сводить размер домена. В нашем случае — рубли.
Следующие шаги похожи на tam sam som, которыми пользуются бизнес‑аналитики/продакты. Но кто бы нам, джунам, сказал что такое есть и подходит для внутренних AI‑команд так же хорошо, как для внешних рынков…
Верхний потенциал: оцениваем сколько <рублей> в целом проходит через домен.
Очевидно, тут численно выйдут вверх те домены, которые влияют на результат компании больше всего.
Возможный потенциал: отрезаем неуправляемую часть метрики.
Например, если рассмотреть конверсию в получение кредитных продуктов, мы увидим, что одни клиенты отваливаются по своей инициативе, а другие — по решению комплаенса. Если в вашем случае на комплаенс влиять нельзя, лучше вырезать эту часть и не врать себе, что в домене золотые горы, когда на деле до них невозможно дойти.
Здесь в сортировке выплывают наверх домены с наибольшим действенным потенциалом.
Риски: проверяем наличие вещей, которые ставят крест на домене.
Разумеется, тут может быть куча пунктов, во многом завязанных на вашу область и нюансы компании. Я расскажу о двух неочевидных, которые в нашем случае вносят большой вклад.
Риск 1: новые и быстрорастущие домены
Риск особенно актуален, если вы встречаетесь с потенциальными заказчиками и спиливаете с них список проблем, идей или мест, где нужно пригодиться.
Как обычно думают ребята из бизнеса — у них в голове есть топ-1-3-5 вещей, которые они прежде всего меняют в своей команде сейчас. Например, если в этом году компания решила податься в экосистемность, все на встречах с вами будут очень много говорить и думать про это.
Проблема со стороны AI‑команд в том, что AI гораздо проще взлететь в «скучных», старых местах. Потому что:
Много накопленных данных.
Понятны алгоритмы, паттерны и ограничения, которые можно заложить в модели.
Чаще всего через старые процессы идёт кратно больше денег, чем через новые и только запускающиеся.
В новых проектах сначала нужно сделать базу. Если в вашей компании нет CRM, вам не нужна наикрутейшая CRM со всеми крутилками и свистелками — нужна база. Также, если в новый процесс пробовать воткнуть AI, часто можно споткнуться о миллион нерешённых пока что вопросов.
История из жизни. У нас так и вышло: все проекты, которые устойчиво растили метрики — это классический ML, который внедрили в процессы старше 5 лет. Данных куча, база сделана, каждый процент роста оказывает большое влияние на проект.
Риск 2: качество контрагентов
Есть домены, в которых люди не идут на контакт, не держат обещания, не хотят что‑то менять. Есть домены, где люди фонтанируют идеями, не умеют приземлиться из воздушного замка на землю и отрезвить их не получается.
AI‑проекты гораздо чаще умирают из‑за людей, которые пытаются внедрять их в проекты, чем из‑за технических сложностей. Да, корпоративные системы приоритизации такое очень не любят! Но это как с подбором команды — сделать что‑то крутое можно далеко не любым составом.
Не буду расписывать рецепт, как проверить, что с командой у вас всё получится. Но точно стоит насторожиться, если к вашим потугам что‑то сделать не проявляют интереса, а заказчик фонтанирует большим количеством идей без понимания образа результата.
Итог:
Вы получаете отсортированный набор доменов. Они достаточно крупные, чтобы не скатываться в скоринг 57 карточек.
Из них исключены домены с красными флагами по списку, обогащенному триггерами с учётом вашей области.
На картинке ниже — гипотетический пример, как может выглядеть сравнение доменов.
Этап 2: работа с доменами
На прошлом этапе мы получили небольшой список процессов/мест в компании, где стоит искать идеи. Каждый домен мы свели к оценке в метрике.
Дальше нужно найти хорошие гипотезы, чем можно заняться в рамках домена, отделив их от плохих. Классический ICE в большинстве случаев оказывался для нас слишком надуманным.
Вот такой путь мы проходим, чтобы оценить гипотезу.
Шаг 1: реалистичный потенциал гипотезы
Всё базово, по сути импакт из ICE. Нужно оценить, сколько можно заработать штукой, если отбросить физически‑невозможные части метрики. Например, если мы с помощью ИИ отвечаем на вопросы в поддержке — сколько мы экономим на зарплатах операторов.
Получаем цифру в метрике (в нашем случае в рублях), к которой сводим домен. Например, у нас был домен: конверсия из клиента, который согласился открыть в счёт в банке, в открытие счета. Изначально потенциал этого домена выглядел очень большим. Но углубившись в него мы поняли, что 70% отвалов — либо комплаенс, либо иные причины, на которые невозможно влиять с нашей стороны. Это позволило более трезво оценивать перспективы запусков.
Шаг 2: Т2Е / time to experience
Когда команда только запускалась, нам казалось логичным прикидывать время на реализацию проекта, а затем выводить вверх более простые со сравнимым профитом. Сейчас команда полностью отказалась от такого подхода.
Почему мы отказались от оценки easiness / трудозатрат:
Во‑первых, на таком масштабе энтропии подобные оценки — полный булщит. Например, первый проект команды мы изначально хотели запустить за 3 месяца. На самом деле, путь до первых растущих конверсий, которые доказаны в AB, занял 1,5 года. И тут проблема не в нехватке знаний: то, как придётся шатать бизнес‑процессы и сколько времени займет psy‑op на пользователей вообще нельзя нормально прикинуть.
Почему вместо easiness я предлагаю T2E
Time to experience (T2E) = сколько времени нужно, чтобы сделать первый запуск, который кратно снизит энтропию.
Два примера:
Вы хотите благодаря ML выбирать, по какому типу монетизации работать с партнёром. ML можно обучить за 1 месяц, но перед запуском пилота есть много юридических проволочек. Их решение может занять от 3 месяцев (в реальности чаще превращается в 6). T2E ≥ 3.
Вы хотите построить систему, где ML выбирает, кому дать промокод, а кому нет. Сама идея масштабная, и вы вряд ли построите её быстрее, чем за год. Но можно собрать ML на коленке за 3 недели, запуститься на одном промокоде, разослать коммуникации руками. T2E ≥ 1.
По сути мы хотим сказать, что не так важно, простой сервис или сложный. Важнее то, как быстро можно запустить пилот, который идею либо убьет (слава богу), либо докажет её живучесть и силу.
Красные флаги и риски
Постарался наполнить этот раздел накопленным нами опытом: что чаще всего не взлетает и стоит деприоритезировать.
Риск № 1: AI для поиска нового и умного vs AI для повторения тупого миллион раз
Либо к вам с такими идеями приходили, либо обязательно придут. Примеры формулировок:
AI для поиска инсайтов.
AI‑советник, который подскажет, что делать с твоими инвестициями.
AI‑мультиагент, который решает, что сейчас нужно делать команде.
Подобные идеи обычно рождаются, потому что:
Медиа и поп‑культура формирует образ искусственного интеллекта как сверхмощного разума, который кратно умнее человека.
Человек склонен искать новые инструменты для решения сложных проблем, о которых он переживает и не знает, как их решать.
После такого понятно, почему к вам приходят с запросом на AI‑космолет, который скажет, что нужно делать, чтобы метрики выросли.
Напротив, скучные, давно уже решенные проблемы интереса не вызывают, и о внедрении AI туда не думает ни заказчик, ни вы, если проводили с ним касдев.
Выводы:
Не запускайте сервисы, которые ищут инсайты и дают советы.
Можно попробовать флипнуть, если применимо, в сторону прямого влияния. Например, из «пусть AI рекомендует менеджерам клиентов, которым стоит дать промокод» в «пусть AI выбирает клиентов, которым мы автоматически отправим промокод».
Риск № 2: большое количество прокси
Примеры идей с большим количеством прокси, через которые надо пройти для нанесения пользы:
Мы поможем менеджеру по продажам написать содержательное саммари звонка. В этом саммари мы на основе звонка напишем, какие услуги можно допродать при следующем касании, чтобы следующий менеджер продал больше.
Мы сделаем дашборд с инсайтами из продаж, чтобы выделять происходящее на рынке и на основе этого улучшать свой продукт.
Например, несколько лет назад наша команда делала проекты, в которых мы давали рекомендации тимлидам продаж. Когда ни один из проектов ничего не дал, мы призадумались. Ключевой проблемой окрестили длину цепочки, через которую надо пробраться, чтобы что‑то в бизнесе стало лучше:
Для начала наш сервис и модели должны были хорошо работать:)
Затем нужно было строить большой операционный процесс, чтобы наладить нашу работу с тимлидами.
Затем проверить, что ничего не ломается между тимлидом и непосредственно продавцом в команде тимлида.
А потом, что рекомендации, которые дали продавцу, он действительно применил.
И потом (дай бог!) клиент, услышав новый питч от продавца, реально что‑то купил.
Имея столько точек отказа можно быть уверенным, что как минимум одна отстрелит, и профит обнулится.
Среди гипотез с длинной цепочкой бывают выигрышные, но вероятность успеха, по нашему опыту, ниже. Чем больше прокси, тем меньше вероятность неуспеха.
Что делать?
Стараться каждую гипотезу направить в сторону прямого влияния. На примере помощи в написании саммари по звонку, можно пивотнуться в «AI анализирует продажи клиенту, выделяет продукты которые стоит допродать, затем мы отправляем оффер клиенту через email». Здесь точек отказа кратно меньше.
Если уменьшение прокси невозможно, либо детально прорабатываем риски для каждой точки отказа (часто лень), либо деприоритезируем (часто не лень).
Риск №3: несобранные данные и ненастроенные процессы
Тут я не буду говорить, что не надо идти в места, в которых бардак в данных, а процессы работают на ручнике.
С одной стороны, думаю всем понятно, что гораздо приятнее делать LLM‑агента в среде, где написана документация о том, как что‑то делать на ручнике, куча данных и инфы. А ML обучать там, где всё уже сложено в датамарт. С другой стороны, в отличие от двух предыдущих рисков, на которые повлиять нельзя, этот риск (иногда) закрывается наваливанием большого количества ресурсов.
Это важно понимать, чтобы не бояться проектов, которые кажутся на старте неподъёмными. Как я говорил, наша команда запустила больше двух десятков проектов, в которые было вложено 1–4 месяца времени. Но сервисы, которые окупают команду, делались минимум год, и на старте не было ни процессов, ни данных — полный хаос.
Нам пришлось строить бизнес‑процессы, в которые затем мы закатывали ML. Таким образом, если бы мы сказали «данных нет, идём дальше», мы бы остались у разбитого корыта.
Как принять решение, куда идти, на основе полученных результатов
Допустим мы взяли полученные домены, описали гипотезы в этих доменах и быстренько оценили их на риски без расчётов easiness, confidence и тп. Как по этим данным решить, что сейчас уходит в работу, а что — нет?
Как я говорил выше, на таком уровне энтропии заявлять, что мы придумали универсальный фреймворк, по которому можно посчитать циферку и пойти туда, где она больше — обман. Но точно можно начать с принципов ниже. Иллюстрировать текст будет таблица № 2 (совпадения с нашей работой случайны и вздорны).
Принцип № 1: оценка потенциала всегда важнее, чем оценка простоты
Оглядываясь назад, я понимаю, что гипотезы, которые мы хотели запустить за 3–6 месяцев и окупить их либо умирали, либо доходили до устойчивого влияния за годы. Из‑за этого риска часть команд переходят к скрупулезному просчитыванию каждого своего действия заранее: системные и дата‑аналитики анализируют гипотезу несколько недель, крутят риски и придумывают сложные фреймворки приоритезации.
Вместо этого наша команда идёт другим путем — заранее признаёт энтропию и её силу. Если мы не можем предсказать, насколько сложным окажется подъём на гору, сколько расщелин и диких зверей нам встретится, мы будем смотреть на одну вещь — высоту горы. Мы хотим, чтобы она была огромной, и это было очевидно.
Принцип №2: сложный стрим лучше неконтролируемого
Мы понимаем, что в основном гипотезы умирают от проблем, о которых мы на старте даже не думали. Но при этом мы не спешим бежать от сложностей, которые видим заранее и чувствуем, что их решение находится в нашей власти.
Как я говорил выше, в команде нет вообще ни одной гипотезы, которая дошла до устойчивого профита быстрее, чем за год. В связи с этим необходимость тяжелой работы нас напрягает куда меньше, чем риски, которые в случае проблем мы не сможем как следует митигировать.
Принцип № 3: если можно вложить больше внимания в один стрим или разделить внимание на два стрима, лучше сфокусироваться на одном, пока он не масштабирован
Горький опыт научил нас, что худшее — это когда есть пять стримов, которые не хочется закрывать из‑за потраченных на них сил, а затем наблюдать, как из‑за внешних условий и нехватки внимания команды они медленно умирают.
Этот опыт научил нас, что если есть возможность по‑черчелевски вкладывать больше ресурсов в одно направление — это занятие куда более толковое, чем запускать два стрима и надеяться, что хотя бы один их них заведётся с полтычка.
В этой статье мы:
Разобрались, почему развивающейся AI‑команде недостаточно просто использовать ICE и другие численные приоритезации, чтобы выбрать проекты для запуска.
Разделили выбор направления на поиск домена и гипотезы.
Предложили, как срезать недостижимый профит, не закапываясь в оценку каждой идеи.
Объяснили, почему отказались от оценки простоты и перешли к оценке времени до первого реального опыта (time to experience).
Привели несколько рисков на уровне домена или гипотезы, от которых стоит бежать.
Отдельно поговорили о ненастроенных процессах и отсутствующих данных, и почему от таких стримов не стоит бежать.
Рассказали, как выбрать, чем заниматься, когда гипотезы собраны.
Обсудили, как выбрать количество гипотез, над которыми мы работаем единовременно.
Надеюсь чтение было полезным! И вы чаще узнавали себя в историях нашего успеха, чем в наших ляпах:).
Я не считаю советы выше универсальными, работающими везде и во всех условиях. Будет круто, если вы, наоборот, опираясь на особенности своей компании и доменов, обогатите список рисков и сигналов о силе гипотезы чем‑то своим.
Всем желаю меньше нейрослопа и больше скорингов!