Почему MVP и тесты гипотез — это плохо: адаптация lean startup под бигтехи

В любой компании нужно решать, над чем и как работать. Одна из широко распространённых методологий для принятия таких решений в IT — lean startup, то есть небольшие итерации с тестированием гипотез. Этот подход настолько привычен для индустрии, что многие команды даже не отдают себе отчёт, что используют его.

Проблема в том, что lean startup не работает «в лоб», если вы не стартап:: я знаю много команд, чье использование MVP и тестов гипотез обернулось впустую потраченным ресурсом и привело к разочарованию в подходе.

Привет! Это Арсений Проценко, я лидирую AI‑команду в продажах в Точка Банк. В статье поделюсь опытом, который пришёл нашей команде за последние годы. Обсудим, что не так с lean в больших компаниях и как можно изменить lean под наши реалии.

Что не так с применением lean в бигтехах

Поскольку компетенции у меня в AI‑продуктах, причем внутренних, говорить буду на примере этого положения дел.

Классический цикл lean startup

Суть подхода lean проста. Вместо того, чтобы долго делать большой продукт и затем его разом выпускать, мы делим работу на маленькие итерации: выбираем узкое место в продукте, улучшение в котором даст больше знаний или пользы → делаем → проводим тест и подводим его итоги → решаем, что делать дальше.

Если нужно найти и довести до профита проект или продукт, цикл выглядит примерно так:

Если верить автору методологии, внедрение этого цикла должно:

• ускорять доставку ценности;

• сокращать траты ресурсов на построение ненужного;

• повышает шансы команды сделать полезный продукт и не закрыться.

Неожиданные побочные эффекты

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

Побочные эффекты внедрения lean такие:

• Потери времени времени на множество «лишних» тестов.

• Потери эффективности и качества продукта из‑за вечного MVP.

• Закрытие сложных проектов с большим потенциалом.

Визуально:

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

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

Таким образом, lean в исходном виде часто даёт больше вреда, чем пользы.

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

Почему lean “как есть” не работает в энтерпрайзе

Чтобы исправить проблему, сначала нужно её проанализировать. В этом разделе поговорим о нескольких факторах, которые, как я думаю, привели к тому, что lean исказился и стал обременением.

Фактор 1: идея быстрых тестов новых продуктов редко применима к сложным процессам

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

Почему тесты проходят медленно:

• В сложной системе, где много участников, изменение процессов занимает значительное время.

• В зрелой системе меньше дизраптящих запусков и мгновенных реакций. На то, чтобы заметить и измерить рост метрики на 5–10%, могут уйти месяцы. 

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

Фактор 2: внешние факторы, которые портят тесты

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

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

Пример из жизни:

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

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

Этот замкнутый круг, где есть ощущение, что до результата осталось совсем чуть‑чуть. Но такое состояние легко затягивается на год и больше.

Фактор 3: ожидания быстрых успехов приводят к ошибкам

Удачных AI‑проектов, способных сделать компанию эффективнее, немного, а отобрать и реализовать их — трудно. Для большинства новых команд и их стейкхолдеров это становится большим сюрпризом :‑)

В том числе сказывается тотальный хайп вокруг AI в статьях, медиа и пресс‑релизах банков которые стали использовать AI и увеличили t2m в 10 раз, а конверсию — в два.

Во многом ориентация на подобные истории и приводит к тому, что команда идёт в быстрый и дешёвый тест, ожидая быстрой победы. Затем ничего не получается. Удивленная команда исправляет ошибку (одну из пары десятков), делает перезапуск — и снова провал. И вот команде два года, деньги потрачены, а на столе ни одного окупившегося продукта.

Мы сами много раз принимали такой стиль работы из‑за нереалистических ожиданий. В одном из первых проектов команды, где ML и значительную часть бэка когда‑то написал я лично, я ожидал, что мы покажем профит за 3–4 месяца. В итоге реальный срок — 18 месяцев, и это ещё повезло…

Из‑за настолько большого разрыва между ожиданием и реальностью, я не вкладывался в качественную ML‑инфраструктуру, и в итоге модели сбоили и обнуляли аплифты экспериментов более полугода.

В общем, самообман редко приводит к чему‑то хорошему. Так и здесь — более трезвое понимание того, что будет трудно, точно пойдет на пользу.

Фактор 4: культура гейтов приводит к ожиданию денег от тестов, а это плохо работает

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

Суть гейтов проста: каждый проект, на пути от идеи до масштабирования или закрытия, проходит через N этапов (гейтов). В конце каждого этапа команда защищает текущие результаты и получает новые инвестиции в случае успеха. Чем более зрелый этап, тем больше спрашивают про деньги. Гейты могут называться по разному, но суть примерно одна.

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

Это искажение, как и прошлые, противоречит изначальной идее и приносит вред. Дело в том, что идеи, которые впоследствии что‑то сильно меняют, редко дают мгновенный эффект

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

Как изменить подход, чтобы стало лучше

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

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

Сравнение визуально:

Ниже — рекомендации, которые позволяют прийти из второй ситуации к третьей:

С умом сокращаем число рисков, которые идут через тест

Варианты действий с риском в продукте:

1. Провести тест.

2. Сделать оффлайн проверку, не требующую запуска теста ‑например, посмотреть аналитику.

3. Принять риск.

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

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

1. Критичность. Если риск реализуется, это означает небольшой пивот или закрытие направления? Небольшие пивоты можно проводить уже после масштабирования.

2. Ваша способность прикинуть на глаз. Можно ли снизить энтропию, посмотрев аналитику за пару часов или оперевшись на интуицию и опыт?

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

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

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

Вы можете идти к решению двумя путями:

• Аналитический перебор.

• Аналитика с опорой на чутьё.

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

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

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

Тестируем конкретный риск, а не профит

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

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

Примеры плохих тестов «на профит»:

1. Если дать AI‑тренажер менеджерам по продажам, то выполнение плана вырастет на 15%.

2. Если мы запустим ML, который будет помогать рекрутерам выделять самые релевантные резюме, то эффективность найма вырастет на 20%.

Примеры хороших тестов:

Риск: практика с AI‑тренажером не приведет к изменению реальной продажи.

Тест: после прохождения сценария по предложению продукта X, предложения этого продукта, которые включают два корректных преимущества, вырастут на 30%.

Риск: ML не сможет выделять релевантные резюме.

Тест: конверсия из открытия резюме от ML в отметку рекрутера, что резюме подходит, вырастет на 20%.

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

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

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

Пример:

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

Дело было в ручнике — заказчик из продаж писал мне в личку, что ему нужно; я передавал описание разработчику; затем в обратную сторону высылалась выборка клиентов в таблице. Если в выборке что‑то было не так, шли несколько раундов правок. Часто создание хорошего сегмента из‑за занятости участников и пересылки файлов занимало столько времени, что к завершению работы акция, под которую делали сегмент, уже заканчивалась :‑)

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

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

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

Что делать, если вы успешно прошли тесты

Если стрим успешно прошёл проверки из вашего спартанского минимума рисков, следующее, что нужно сделать — кратно нарастить инвестиции и поставить следующую цель. Обычно следующая цель — успешное масштабирование направления и оценка (уже полноценная) денежных метрик.

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

Что в итоге

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

1. Быстрее и эффективнее идти к проектам, дающим пользу и окупающим затраты

2. Не убивать большие идеи, которые не дают результат мгновенно.

Спасибо за прочтение, буду рад вопросам и критике в личке и комментариях!