Что означает MMF?

MMF — это сокращение от Minimum Marketable Feature, что в переводе означает «Минимально продаваемая функция». MMF представляет собой наименьший набор функциональности в продукте, который уже имеет коммерческую ценность для клиента и может быть выпущен на рынок как самостоятельная единица.

Концепция MMF является ключевой в Agile-разработке и Lean-подходе. Она помогает командам сосредоточиться на поставке реальной ценности клиентам как можно раньше, вместо того чтобы тратить месяцы на создание больших и комплексных решений, которые могут оказаться невостребованными.

В отличие от [MVP (Minimum Viable Product)](/ru/mvp - minimum viable product), который описывает минимальный жизнеспособный продукт в целом, MMF фокусируется на отдельной функции в рамках уже существующего или разрабатываемого продукта. MMF — это строительный блок, из которых складывается целостный продукт.

Чтобы набор функциональности мог считаться MMF, он должен соответствовать нескольким критериям:

Минимальность (Minimum)

MMF должна содержать минимально необходимый объём функциональности. Это не означает «урезанная» или «некачественная» функция. Это означает, что в неё включено только то, что необходимо для достижения поставленной цели, без избыточных элементов. Каждый дополнительный элемент должен быть обоснован ценностью для пользователя.

Продаваемость (Marketable)

Это ключевое отличие MMF от обычной задачи или [пользовательской истории](/ru/historia de usuario). MMF должна быть достаточно значимой, чтобы её можно было «продать» клиенту — то есть представить как самостоятельное улучшение продукта, за которое клиент готов заплатить или которое повышает привлекательность продукта на рынке.

Функциональность (Feature)

MMF — это законченная функция, а не техническая задача или исправление бага. Она решает конкретную проблему пользователя или удовлетворяет конкретную потребность. Рефакторинг кода или обновление инфраструктуры, хотя и важны, не являются MMF.

MMF vs MVP

Характеристика	MMF	[MVP](/ru/mvp - minimum viable product)
Масштаб	Отдельная функция продукта	Целый продукт
Цель	Доставить ценность через конкретную функцию	Валидировать гипотезу о продукте
Контекст	В рамках существующего продукта	Начало нового продукта
Количество	Продукт содержит множество MMF	Обычно один MVP на продукт
Результат	Готовая к использованию функция	Минимальный продукт для обучения

MMF vs User Story

[Пользовательская история](/ru/historia de usuario) описывает потребность пользователя в формате «Как [роль], я хочу [действие], чтобы [результат]». Одна MMF может состоять из нескольких пользовательских историй. Например, MMF «Оплата через Apple Pay» может включать истории: «Как покупатель, я хочу добавить карту Apple Pay», «Как покупатель, я хочу оплатить заказ через Apple Pay», «Как покупатель, я хочу получить подтверждение оплаты».

MMF vs Epic

Epic — это большой объём работы, который может быть разбит на несколько пользовательских историй. Epic и MMF похожи по масштабу, но ключевое различие в том, что MMF всегда ориентирована на рыночную ценность, тогда как epic может описывать и технические улучшения.

Применение подхода MMF даёт командам и организациям ряд значительных преимуществ:

Ускорение времени выхода на рынок

Разбивая продукт на MMF, команда может начать поставлять ценность клиентам значительно раньше. Вместо того чтобы ждать завершения всего релиза, отдельные MMF могут быть выпущены по мере готовности, обеспечивая непрерывный поток ценности.

Увеличение возврата инвестиций (ROI)

Каждая MMF начинает приносить [ROI](/ru/roi - return of invest) с момента своего релиза. Чем раньше функция попадает к пользователям, тем раньше организация начинает получать от неё выгоду. Это особенно важно в контексте [Cost of Delay](/ru/cost of delay), где задержка поставки имеет реальную стоимость.

Снижение рисков

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

Приоритизация на основе ценности

MMF помогает команде и [Product Owner](/ru/product owner) вести содержательные разговоры о приоритетах. Вместо абстрактных обсуждений «что важнее» можно сравнивать конкретные единицы ценности: какая MMF принесёт наибольшую выгоду при наименьших [затратах](/ru/cost of delay)?

Повышение мотивации команды

Регулярная поставка завершённых и ценных функций повышает удовлетворённость и мотивацию команды. Разработчики видят, как их работа приносит реальную пользу пользователям, а не исчезает в бесконечном списке невыпущенных задач.

Определение MMF требует тесного взаимодействия между бизнесом, продуктом и разработкой. Вот пошаговый процесс:

Шаг 1: Определить бизнес-цель

Начните с вопроса: «Какую проблему клиента мы решаем?» или «Какую ценность мы создаём?» Это должна быть конкретная, измеримая цель, привязанная к [KPI](/ru/kpi - key performance indicator) или OKR.

Шаг 2: Описать целевой сценарий

Опишите полный сценарий использования функции от начала до конца. Какие действия выполняет пользователь? Какой результат получает?

Шаг 3: Определить минимальный набор

Задайте вопрос: «Что можно убрать из этого сценария, не потеряв при этом основную ценность?» Уберите все «хорошо бы иметь» элементы и оставьте только то, без чего функция теряет смысл.

Шаг 4: Проверить «продаваемость»

Спросите себя: «Если мы выпустим только это, будет ли клиент рад? Решит ли это его проблему? Готов ли он за это заплатить?» Если ответ «нет», возможно, вы отрезали слишком много — нужно добавить элементы обратно.

Шаг 5: Декомпозировать на пользовательские истории

Разбейте MMF на [пользовательские истории](/ru/historia de usuario), которые можно реализовать и протестировать в рамках спринта.

Допустим, компания разрабатывает платформу для онлайн-обучения. Product Owner определил, что пользователи хотят возможность получать сертификаты о прохождении курсов. Полная функция «Сертификация» может включать:

• Генерация PDF-сертификата
• Настраиваемые шаблоны сертификатов
• Проверка подлинности сертификата по QR-коду
• Интеграция с LinkedIn
• Аналитика по сертификатам
• Автоматическая рассылка сертификатов по email

MMF: генерация PDF-сертификата + автоматическая рассылка по email. Это минимальный набор, который уже представляет ценность: пользователь завершает курс и получает подтверждение. Остальные элементы могут быть добавлены в последующих итерациях.

В Scrum

В Scrum MMF часто соответствует [Product Goal](/ru/product goal) или группе элементов [Product Backlog](/ru/product backlog), которые вместе формируют релизоспособный инкремент. [Product Owner](/ru/product owner) приоритизирует MMF в бэклоге, а команда поставляет их в серии спринтов.

В Kanban

В Kanban MMF может быть отслеживаема как элемент работы более высокого уровня. Команда визуализирует прогресс MMF на [канбан-доске](/ru/kanban board) и измеряет [lead time](/ru/lead time) от начала работы над MMF до её поставки.

В SAFe

В [SAFe](/ru/safe - scaled agile framework) MMF является центральной концепцией. Они планируются на уровне [PI Planning](/ru/pi planning) и поставляются в рамках [Program Increment](/ru/pi - program increment). SAFe использует принцип WSJF (Weighted Shortest Job First) для приоритизации MMF на основе соотношения ценности и размера.

В Lean Startup

В подходе Lean Startup MMF помогает валидировать гипотезы о ценности продукта. Каждая MMF — это эксперимент: выпускаем минимальную функцию, измеряем реакцию пользователей и принимаем решение о дальнейшем развитии на основе данных.

Существует ряд распространённых ошибок, которых следует избегать:

• Слишком маленькая MMF: если функция не решает проблему пользователя целиком, она не является «продаваемой» и это не MMF, а просто задача
• Слишком большая MMF: если MMF занимает больше 2-3 спринтов, скорее всего, её можно и нужно разбить на более мелкие MMF
• Техническая задача под видом MMF: обновление базы данных или рефакторинг — это не MMF, даже если они важны для продукта
• Игнорирование «продаваемости»: фокус только на минимальности без учёта ценности для клиента приводит к бесполезным релизам
• Отсутствие обратной связи: выпуск MMF без сбора обратной связи лишает команду главного преимущества — возможности учиться и адаптироваться

Сколько пользовательских историй обычно содержит одна MMF?

Типичная MMF содержит от 3 до 10 [пользовательских историй](/ru/historia de usuario). Если историй меньше двух, вероятно, функция недостаточно значима для самостоятельного релиза. Если историй больше 15, стоит проверить, можно ли разбить MMF на несколько более мелких.

Кто отвечает за определение MMF?

Определение MMF — это совместная ответственность [Product Owner](/ru/product owner) (знает ценность для бизнеса и клиента) и команды разработки (знает техническую сложность и ограничения). В идеале, MMF определяется в ходе Discovery-процесса с участием обеих сторон.

Может ли исправление бага быть MMF?

Как правило, нет. Баг — это дефект существующей функциональности, а не новая ценность. Однако если исправление критического бага напрямую влияет на выручку или удержание клиентов и может быть «продано» как улучшение, его можно рассматривать как MMF.

Как связаны MMF и Continuous Delivery?

Continuous Delivery создаёт техническую возможность для частого выпуска MMF. Если релиз требует недель подготовки, преимущество маленьких MMF теряется. CD обеспечивает инфраструктуру, позволяющую выпускать MMF по мере их готовности с минимальными накладными расходами.

Как приоритизировать MMF между собой?

Наиболее эффективные методы приоритизации MMF: 1) WSJF (Weighted Shortest Job First): ценность, делённая на размер; 2) [Cost of Delay](/ru/cost of delay): стоимость задержки поставки MMF; 3) Impact Mapping: связь MMF с бизнес-целями и целевыми показателями; 4) Кано-модель: классификация MMF по степени влияния на удовлетворённость клиентов.

Применима ли концепция MMF за пределами программного обеспечения?

Да. Концепция MMF универсальна и применима в любой области, где нужно поставлять ценность инкрементально: маркетинг (минимальная рекламная кампания), образование (минимальный учебный модуль), hardware (минимальный набор функций устройства). Принцип один: определить наименьшую единицу ценности, которая имеет смысл для клиента как самостоятельное предложение.