В предыдущей серии мы рассказывали о том, что такое MVP, и в общих чертах описали структуру работы над созданием MVP.
МVP — это продукт, который обладает минимальными, но достаточными функциями для удовлетворения запросов первых потребителей. Он создается для получения обратной связи от рынка и формирования гипотез дальнейшего развития продукта.
Приведем пример: допустим, вы хотите создать платформу для онлайн школы. Определяем минимальный необходимый набор функций, которыми платформа должна обладать: возможность создания личного кабинета для учителя и ученика, возможность записаться, получить подтверждение записи, общее пространство, в котором будет проходить урок — виртуальный класс. С этим уже можно идти на рынок и предлагать продукт первым пользователям. А дальше, в процессе работы можно добавлять разные приятные и полезные функции: чат, sms-подтверждение, интеграция с банком для простоты оплаты, собственная библиотека, автоматизированная проверка домашних заданий и так далее, и тому подобное, и любое другое, на что хватит воображения. Но первые ученики уже работают!
Здесь интересно отметить, что лет 20-30 назад, когда информационные технологии только проникали в бизнес, не был еще найден оптимальный подход к работе, первым значимым этапом являлся так называемый “прототип”, некая потемкинская деревня. По сути, модель, где ничего не работает и пользоваться ей нельзя. Затем проект поступал в разработку. Сейчас разработка ведется по итеративному Agile-подходу, небольшими двухнедельными спринтами, с постоянным тестированием и внесением корректировок. А в то время про Agile еще не слышали, разработка шла очень значимый промежуток времени, вся целиком. В итоге, зачастую заказчик получал совсем не то, что хотел. Долго, дорого, неэффективно.
Опытным путем был выработан метод, который позволял с одной стороны сделать продукт с минимальным набором функций, которым уже могли бы пользоваться конечные потребители, а с другой стороны, сделать это за конечный промежуток времени (3-6 месяцев — тот период, когда заказчик психологически готов инвестировать, еще не видя результата), небольшой командой (3-10 человек) и с вполне понятным бюджетом. На сегодняшний день концепция MVP является наиболее удобной и отвечающей потребностям рынка.
Принципиально важен первый этап разработки MVP — “Проектирование бизнес-процессов”. Это самое начало, когда необходимо четко определить сам продукт, выделить главное, отсеять все дополнительное, выкристаллизовать идею. Обычно это происходит в ходе первых интервью, которые проводит бизнес-аналитик с заказчиком. Рассматриваются все исходные материалы, документация, выясняются главные пожелания клиента.
Клиенты очень ценят, когда мы обращаемся к ним с предложением
определить границы бюджета. Часто бывает, что-то можно оптимизировать в затратах на разработку и при этом не скажется на проверке бизнес-идеи. В итоге, количество потерь и издержек сокращается, а вероятность успеха MVP за счет быстрой проверки гипотез повышается!
Еще один принципиальный момент: если вы планируете создавать MVP, то в вашей команде обязательно должен быть человек, владеющий всей полнотой информации о будущем продукте, Product Owner. И он должен быть готов посвящать работе над проектом не менее 4 ЧАСОВ в день на протяжении всего первого месяца работы.
Бизнес-аналитик проводит с заказчиком интервью, в ходе которого определяется задача, собирается вся возможная информация, документация о проекте, определяется Product Owner (это может быть как сам заказчик, если у него есть на это время, либо тот, кого он назначит).
И затем наступает принципиально важный момент: определение функционального периметра будущего продукта, иначе говоря, тот самый минимальный набор функций. Это не всегда легко и безболезненно, поэтому здесь у нас разработан подход, как именно выделить суть:
- Мыслим ШИРОКО — определяем глобальное видение продукта.
- Мыслим “ВГЛУБЬ” — в чем суть продукта? На какую потребность ориентирован и как ее удовлетворяет?
- Определяем СОДЕРЖАНИЕ — очерчиваем основные направления, сценарии, роли и функционал
- Оставляем МИНИМУМ — определяем приоритеты между сценариями и функционалом
- Проверяем ЖИЗНЕСПОСОБНОСТЬ — возвращаемся к вопросу ценности минимального набора сценариев для клиента.
И это все позволяет нам определить границы MVP и собрать целостную картинку из результатов всех предыдущих шагов.
Бывает по-разному, но чаще всего предприниматели, создающие свои первые проекты MVP, находятся во власти своего замысла и ослеплены будущим успехом проекта. В таких ситуациях наша задача — встать на сторону первых клиентов и дать развернутую обратную связь на продукт или услугу.
Теперь, когда с проектированием бизнес-процессов закончено, можно пригласить архитектора, который будет заниматься непосредственно архитектурным решением. Но об этом в следующих сериях!