Теперь существуют только MVP?

Сначала у нас МVP продукта. Потом MVP улучшения. Потом MVP улучшения улучшения.

Зачем делать нормально? Как, когда и почему пора переставать по-максимуму экономить время? Где баланс скорости и качества?

×××

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

×××

– Допускаете, что гипотеза не подтвердится? – Надо тестировать.

Чем быстрее проведем тест, тем раньше откажемся от (вполне вероятно неподтвердившейся) гипотезы и займемся чем-то полезным. Это и есть MVP.

×××

– Заранее уверены, что полезное и раскатите? – Так продумывайте сразу нормально и не тратьте время на переделку.

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

Зачем, если MVP уже как-то решит проблему? Затем, что так метрики (и опыт пользователей) будут лучше (иначе кто-то что-то не поймёт; кто-то выберет конкурентов, потому что там удобнее; и т д).

То есть улучшения вы так или иначе захотите делать. И в том числе проведёте все вышеперечисленные исследования. Просто позже. Но если сначала "как-нибудь", а потом уже "как следует", то на изначальную реализацию потратится время, а в конечной реализации возможно ничего из первоначальной использоваться не будет.

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

×××

– Ваша гипотеза слишком сумасшедшая и/или быстрая реализация MVP невозможна? – Проверяйте гипотезу без реализации (и даже без продумывания!) решения проблемы.

Речь про:
– Заглушки (когда при нажатии на кнопку клиент видит "простите, пока не работает")
– Хардкор какого-то определенного кейса (пусть людям с геолокацией Твери показывается баннер, что в парикмахерской "Солнышко" скидка 50% при записи через яндекс-карты)
– Ручную обработку (например, пообещали клиенту бонусы при определенных условиях ==> раз в неделю проверяете и руками начисляете)
– ...и другие способы исхитриться и проверить гипотезу минимальными усилиями.

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

При этом считается время любого члена команды: не только разработчика, но и дизайнера с ux-исследователем (карандашиком на листочке получится отличный макет, описывающий идею; нарисовать может любой), и аналитика, и самого продакта (то есть и продумывание + поддержка-теста + подведение-итогов должны бы быть максимально быстрыми). Это growth hacking.

Если гипотеза подтвердится, то тогда всё вышеперечисленное откатите и сделаете нормально. Под "подтвердится" здесь имеется в виду в том числе то, что измеренные метрики ещё и достаточно высоки, чтобы оправдать трудозатраты (которые с самого начала обещали быть высокими) или другие риски.

×××

Основной вывод: баланс скорости и качества достигается путём максимизации прироста-целевой-метрики, делённой на потраченное-время. Звучит банально и очевидно. Подвох в учёте определенного горизонта в будущем, а не расчёте трат времени "только здесь и сейчас".

Качество увеличивает прирост метрики. Качественно-сразу / MVP / тяп-ляп-на-костылях выбирается путём учёта мат. ожидания лишних-трат-времени сейчас (если решим туда вообще не идти) и лишних-трат-времени потом (на переделывание с выкидыванием предыдущего).