Потому что в большинстве случаев мы ошибаемся
MVP - или минимально жизнеспособный продукт - это модное слово, которое стало популярным благодаря Эрику Райсу в его книге Экономичный стартап. Концепция проста; выпустить как можно быстрее с минимально необходимыми функциями, чтобы запустить цикл обратной связи.
Тем не менее, когда мы входим в проект MVP, мы оказываемся в море незавершенных задач, меняющихся требований и разработчиков, которые просто не могут выполнить поставку в срок и в рамках бюджета. Мы сталкиваемся с плохим случаем сползания прицела или вынуждены выпускать что-то, что не подходит для публичного использования.
Так где же все пошло не так? А как выглядит настоящий MVP?
Раздеть его и раздеть его голый
Проблема с большим количеством попыток MVP заключается в том, что слишком много требуется слишком рано.
Смысл выпуска MVP для новых приложений заключается в том, что выпускаются основы и добавляются дополнительные функции в последовательном и непрерывном цикле выпуска.
Однако, когда все становится обязательным, упускается смысл выпуска минимального продукта. Это может привести вас к созданию продукта, основанного на том, что, как вы думаете, хочет покупатель, а не на том, чего он действительно хочет.
Смысл отказа от ваших функций для создания базового приложения заключается в том, чтобы вы могли быстро выпустить его для своей аудитории. Это предотвращает застревание вашего проекта в разработке на два года только для того, чтобы обнаружить, что ваш рынок ушел от тренда.
Цикл обратной связи отсутствует, когда вы постоянно развиваете, но не можете освободиться. Ваш MVP застревает в подвешенном состоянии, и любая получаемая вами обратная связь носит субъективный и внутренний характер.
Качество - это основа, задающая темп будущих поставок
Минимально жизнеспособный продукт - это больше, чем просто рабочий продукт - ему по-прежнему нужны хорошие привычки и основы в коде, инфраструктуре и процессах, чтобы стать эффективным MVP, способствующим расширяемости и росту.
Когда MVP построен на хорошей основе, добавление будущих функций становится проще и быстрее. Когда основы слабы или имеют несколько трещин под давлением непрерывных расширений, скорость реализации функций вашего приложения будет замедляться.
Создание MVP не означает, что нужно прибегать к функциям и надеяться, что они не упадут. Скорее, это процесс продуманного создания плана игры, который может адаптироваться к требованиям рынка.
Существует четкий путь к тому, куда вы хотите пойти с приложением как с бизнесом, но у него также есть возможность при необходимости менять направление, если требования рынка изменятся.
Подумайте о «минимальном отличном продукте»
При наличии облачных технологий и квалифицированных разработчиков создание продукта, не отвечающего нормам, больше не будет использоваться на высококонкурентном рынке.
MVP теперь является синонимом предоставления минимально привлекательных продуктов, которые не только возвращают ваше приложение к основам, а затем строят его на основе цикла обратной связи или стратегического отставания функций, но также обеспечивают беспроблемный опыт, который заставит вашего клиента захотеть использовать ваш продукт или услуга снова и снова.
Это означает, что дизайн интерфейса приятен на вид и интуитивно понятен, скорость загрузки оптимизируется с помощью инфраструктуры в зависимости от географического положения и функций, которые решают проблему.
Типы функций, из которых состоит продукт
Есть два типа функций: основная функция и функция улучшения. Решая, какую функцию выпустить, многие ошибочно принимают улучшитель за основную функцию.
MVP требует, чтобы фундаментальная функция была определена и выпущена в первую очередь, прежде чем что-либо еще. Эта основополагающая часть также является пространством для споров и дискуссий, что приводит к смещению и задержке проекта.
Распространенной стратегией предотвращения этого является просмотр приложения, удаление функции, и, если она по-прежнему функционирует без снижения минимально необходимого взаимодействия с пользователем, это улучшающая функция. Если это стратегическое и основное требование, это фундаментальная функция.
В любом приложении есть не так много основных функций, но бесконечное количество функций улучшения. Умение различать эти два аспекта может помочь предотвратить запуск вашего проекта со временем и превышением бюджета.
Последние мысли
Не все команды равны, и хотя принято считать, что все, нанятые в качестве разработчиков, имеют одинаковый качественный результат, хорошая команда сможет предоставить код, способный противостоять требованиям растущей со временем кодовой базы.
Без этого ваш цикл предоставления функций будет увеличиваться до полной остановки.
Когда проекты MVP начинают терять способность выполнять поставку, высока вероятность того, что просто слишком много функций, которые нужно предоставить. Иногда это происходит потому, что приложение стало слишком сложным по своему дизайну для чего-то, что должно было быть простым.
Хороший и эффективный MVP - это тот, который упрощен за счет минималистского подхода к доставке продукта. Он ориентирован на основные функции и взаимодействие с пользователем, а не на вспомогательные функции, которые, по предположениям компании, необходимы пользователям.
В соавторстве с Дэйвом Уэсли - основателем SRG разработка программного обеспечения для здравоохранения для не береговых территорий.
