Менеджеры любят mvp, но зачастую делают говно

Есть идея? Давайте быстро и дешево протестируем. Соберем силами одного бизнес-аналитика процесс и запустим в прод. Здравый подход, чтоб не убить впустую силы команды. И деньги компании конечно же.

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

Вот три наиболее популярных сценария:

1. Тест успешный. Масштабируем текущий костыль на 100%. Но развитие стопорим, тк нет фокуса. Мол, достигли какой-то результат, давайте дальше похолдимся.

2. Тест успешный. Катим на 100%. Дальше наслаиваем новую логику все тем же аналитиком. Архитектура усложняется, падений становится больше. Но бизнес-метрики растут.

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

Почему мне эти сценарии не нравятся?

1. Костыли ускоряют, но долгосрочно создают испанский стыд и плохой клиентский опыт. Если на этапе теста две недели у 5% падает интеграция, этим можно пренебречь. Но жить так дальше опасно.
Во-первых, генерятся обращения в поддержку. Принуждать клиента тратить время плохо(
Во-вторых, эффект «неработающего сервиса» клиент экстраполирует на всю компанию. Он не скажет «Продакт Игорь идиот». Он напишет, что у ТБанка приложение говно. В итоге ухудшается лояльность ко всей компании.

2. Костыли реально могут дать классный бизнес-эффект и шикарно прокрасить А/Б. Менеджеры радуются что 10% усилий дали 80% результата. В итоге ребята быстро растут до синьоров. Есть цифры за спиной. Но такой менеджер не способен создать долгосрочно хороший и надежный продукт. У него тупо нет опыта.

3. Создается культура терпимости к косякам. 5% отвалов у сервиса 1 не создают панику. 3% отвала у сервиса 2 тоже. Сервис 3 недоступен раз в неделю, но дальше работает. Внутри создается ощущение что все ок, шестеренки крутятся. Метрики растут!
Но во вне компания из технологического лидера превращается в багованное приложение. Со временем это замечают больше клиентов. И остановить снежный ком порой уже невозможно. Точка невозврата и вот вы уже не лидер.

Как их избежать?

Заранее обсуди с топами как будешь двигаться при положительном результате теста. Донеси, что нужен переход к MLP*-решению. Проговори какие роли нужны, сколько будет стоить команда. И за каким совокупным эффектом вы гонитесь, что принесет фича ?

Если лиды не готовы тратить ресурсы в это направление, то зачем твой тест силами одного аналитика??? Оказаться в одном из трех сценариев выше?

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

——
Minimum lovable product (MLP) — это первичная версия продукта, которая нравится пользователям. По сути, MLP — это MVP с продуманным пользовательским интерфейсом и опытом пользователя. Такой продукт решает проблемы пользователя и создает эмоциональную связь клиента с продуктом.

Такое точечное включение под блогеров - не норма. Обусловлено критичностью и искренним желанием быстрее помочь всем пострадавшим.

Мы с командой стараемся внутри Обслуживания Т-Банка создать системные рельсы эскалации. Чтобы любой человек смог решить свою проблему независимо от того блогер он или нет.

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

Но эта история была очень необычной и прикольной) Мне понравилось)))