Что такое MVP и как определить его границы?

MVP и как определить его границы

MVP (Minimum Viable Product) — это минимально жизнеспособный продукт, который содержит только самые критичные функции для решения основной проблемы пользователя. Это не неполный продукт, а полнофункциональный продукт, но без лишних фич.

Определение MVP

MVP должен:

• Решать одну основную проблему пользователя
• Быть достаточно полнофункциональным для использования
• Быть быстрым и дешёвым в разработке
• Позволять собрать feedback от реальных пользователей
• Открывать путь к следующим версиям

MVP НЕ должен:

• Быть половинчатым решением
• Содержать всё, что в вашем видении
• Требовать бесконечной разработки

Примеры MVP

Airbnb (начало):

Создатель просто размещал фото своей квартиры на доске объявлений
МВП: Сайт с фото, описанием и способом связи
НЕ в МВП: Система бронирования, платежи, отзывы

Это позволило валидировать идею за неделю

Dropbox:

МВП: Просто видео, показывающее, как работает синхронизация папок
Это было достаточно, чтобы понять, нужна ли людям эта функция

Instagram:

MВП: Просто фото с фильтрами и возможность делиться
НЕ в МВП: Истории, месседжи, шоппинг, рилс

Для стартапа по управлению проектами:

МВП:
- Создание проектов
- Добавление задач
- Назначение исполнителей
- Простой статус (To Do, In Progress, Done)

НЕ в МВП:
- Временное отслеживание
- Отчёты и аналитика
- Интеграции
- Кастомные поля
- Уведомления по email/Slack

Как определить границы MVP

Шаг 1: Определи ключевую проблему

Что ОДНУ проблему решает твой продукт?

Примеры ключевых проблем:
- E-commerce: Люди хотят покупать онлайн
- Jira: Люди хотят отслеживать задачи
- Slack: Люди хотят общаться в команде
- LinkedIn: Люди хотят профессионально общаться

Шаг 2: Определи основной юз-кейс

Что ОДНО основное действие делает пользователь?

E-commerce:
Пользователь хочет найти и купить товар

Jira:
Твоей команде нужно отслеживать, кто что делает

Slack:
Люди хотят обсуждать проекты в одном месте

Шаг 3: Минимальный набор функций

Что МИНИМАЛЬНО нужно, чтобы основной юз-кейс работал?

Для e-commerce:
✓ Каталог товаров (хотя бы список)
✓ Карточка товара с ценой
✓ Корзина
✓ Оформление заказа
✗ Рекомендации (хорошо иметь, но можно без)
✗ Отзывы (хорошо иметь, но можно без)
✗ Система лояльности (хорошо иметь, но можно без)

Шаг 4: Исключи "хорошо иметь"

Делай список и разделяй:

Must Have (критично):
- Регистрация
- Поиск по названию
- Покупка

Should Have (важно, но можно подождать):
- Фильтры
- Рецензии
- Сохранённые товары

Could Have (nice to have):
- Рекомендации
- Программа лояльности
- Программа реферала

Won't Do (в МВП точно не будет):
- Мобильное приложение
- Интеграция с маркетплейсами
- AI ассистент

Шаг 5: Установи критерий успеха МВП

Как ты поймёшь, что МВП успешен?

Метрики могут быть:
- 100 активных пользователей в месяц
- 50% пользователей совершили действие
- NPS > 30
- Positive feedback от 70% юзеров
- 10 платящих клиентов

Вы должны понять: 
Людям нужен этот продукт? 
Готовы ли они платить?
Хотят ли они продолжать использовать?

Техники выбора функций

Метод "Moscow":

M - Must have (обязательно)
S - Should have (желательно)
C - Could have (хорошо иметь)
W - Won't have (точно не будет)

Матрица ценность/сложность:

Высокая ценность + Низкая сложность = ДЕЛАЙ ПЕРВЫМ
Высокая ценность + Высокая сложность = РАССМОТРИ
Низкая ценность + Низкая сложность = ДЕЛАЙ ЕСЛИ ЕСТЬ ВРЕМЯ
Низкая ценность + Высокая сложность = ИСКЛЮЧИ

Кайкаку (Kaikaku) — радикальное переосмысление:

Что если мы забудем про конкурентов и сделаем ТО, что реально нужно?

Например, вместо сложной системы CRM, 
учитель может просто иметь таблицу с контактами.
Это МВП, и дальше можно расширять.

Ошибки при определении MVP

1. МВП слишком велик

❌ "МВП нашего соцсети это: профили, посты, комментарии, 
   лайки, подписки, уведомления, месседжи, истории, рилс"

✓ "МВП: Профили, возможность следить, простые посты"

2. МВП не решает никакую проблему

❌ "МВП это просто форма для ввода данных"

✓ "МВП это полная система, которая помогает..."

3. МВП слишком низкого качества

❌ "Делаём быстро и грязно, потом переделаем"

✓ "Делаём минимальный, но качественный продукт"

4. Нет плана на v2 и v3

❌ "В МВП всё, что нужно, дальше развивать не будем"

✓ "МВП это начало. В v1.1 добавим X, в v2 добавим Y"

Процесс определения МВП для проекта

1. Интервью с пользователями (2-3 часа)

• Что их главная проблема?
• Как они сейчас её решают?
• Что их раздражает больше всего?

2. Написание сценариев использования (1 час)

• Основной сценарий
• Альтернативные сценарии

3. Мозговой штурм функций (1 час)

• Все возможные функции
• Без фильтрации

4. Приоритизация (2 часа)

• Must Have
• Should Have
• Could Have
• Won't Do

5. Оценка сложности (1 час)

• Что легко, что сложно
• Что требует интеграций

6. Согласование со спонсором (1 час)

• Показываешь план
• Согласуешь сроки и бюджет
• Получаешь sign-off

Пример МВП для SaaS продукта

ПРОБЛЕМА: Менеджеры не знают, в каком статусе находятся сделки

ОСНОВНОЙ ЮЗ-КЕЙС: Менеджер создаёт сделку, обновляет статус, видит воронку

МВП ФУНКЦИИ:
✓ Регистрация/вход
✓ Создание контактов и компаний
✓ Создание сделок
✓ Смена статуса сделки
✓ Список всех сделок
✓ Воронка по стадиям
✓ Основные отчёты

МВП НЕ СОДЕРЖИТ:
✗ Интеграции
✗ Прогнозирование
✗ Кастомные поля
✗ Интеграция с email
✗ Мобильное приложение
✗ API для внешних систем

КРИТЕРИИ УСПЕХА МВП:
- 50 компаний используют
- NPS > 40
- 80% пользователей создали хотя бы одну сделку
- Получили feedback для v2

Итоговый чеклист МВП

• Четко определена одна ключевая проблема
• Основной юз-кейс документирован
• Must Have функции выделены
• "Could Have" и "Won't Do" чётко разделены
• Сложность оценена
• Есть критерии успеха МВП
• План на v2 и v3 понимаю
• Спонсор согласен и подписал
• Команда понимает, что входит в МВП

Вывод

MVP — это не неполный продукт, это фокусированное решение одной проблемы. Правильный МВП помогает быстро валидировать идею, экономит деньги и снижает риск. Business analyst должен быть стражником МВП, защищая его от scope creep и раздутия функциональности.