Психология требований: MVP и MLP для снижения неопределённости и тревоги заказчика
Многие аналитики знают, как тяжело воспринимают функциональные заказчики длинные тексты требований на разработку системы. И их можно понять. Если аналитики и руководитель проекта могут быть постоянно погружены в задачи по подготовке требований, то у заказчиков есть основная работа за пределами проекта, которая порой съедает всё их внимание. Они вынуждены переключаться. И в сложных, длительных, больших проектах некоторые заказчики начинают теряться, путаться, что-то упускать. В таких условиях может формироваться основа для будущих конфликтов команды разработчика даже с лояльными и добросовестными заказчиками.
Есть много полезных идей, как организовать работу с письмами, документами и встречами на проекте. Но это не всегда спасает. Все мы по-разному воспринимаем информацию: одним подходит текст, другие лучше воспринимают информацию на слух, кто-то предпочитает рисунки и схемы, а некоторым нужно «потыкать» систему.
Продолжая рубрику «Психология требований», я хочу поговорить о MVP (Minimum Viable Product, минимально жизнеспособный продукт) и MLP (Minimum Lovable Product, минимально привлекательный или любимый продукт) как инструментах, которые могут упростить взаимодействие с заказчиком.
Напомню, что понятие MVP стало известным в начале 2000-х благодаря работам Фрэнка Робинсона, а в 2011 году Эрик Рис своей книгой «Бережливый стартап» (The Lean Startup) помог расширить аудиторию сторонников концепции MVP. Идею этого подхода легко понять – разумно начинать разработку программного продукта с основной функциональности, получая обратную связь от заказчика/пользователей и проверяя гипотезы с помощью прототипов будущей системы.
Рисунок 1. Слайд из презентации вебинара «Почему заказчик "не знает, чего хочет": бизнес-анализ и психология требований»
На вебинаре «Почему заказчик "не знает, чего хочет": бизнес-анализ и психология требований» мы уже говорили, что формализация не равна пониманию, что люди думают образами, а не требованиями. К сожалению, даже хорошо структурированная информация о формируемых требованиях на проекте не исключает риска того, что заказчики начнут путаться, будет нарастать неопределённость. В таких условиях можно наблюдать «странную» реакцию с их стороны: одни будут замыкаться в себе и отстраняться от взаимодействия с командой разработчика, другие будут активизироваться, но в негативном контексте, будут давить, нагнетать, торопить делать ЧТО-ТО (но зачастую вовсе не то, что надо делать). И всё это могут быть контрпродуктивные защитные реакции. Такие стрессовые условия мешают рационально мыслить.
В ряде случаев может помочь визуализация идеи с помощью прототипов, которые заказчик посмотрит и выдаст свои впечатления, замечания, пожелания. Но такой формат не всегда возможен. Иногда функциональному заказчику бывает сложно прийти к единому мнению, а жёсткие сроки и ограниченный бюджет не позволяют слишком долго обсуждать варианты реализации. Однако в ряде случаев прототипы делать можно и нужно (здесь и далее я рассматриваю прототипы как часть или способ создания MVP). Напомню, что прототипом может быть не только начальная версия базовой функциональности будущей системы, но и макеты, которые просто помогут продемонстрировать идею, а итоговая система будет создана на их примере.
Рассмотрим внедрение CRM-системы. Предположим, что MVP – это возможность создать в системе контакт, привязать сделку и получить отчёт по воронке продаж. Без интеграции с сайтом, без автоматической рассылки, без мобильного приложения. Заказчик видит: «Ага, контакт завёлся, сделка движется». Тревога снижается, и он уже спокойно обсуждает, какую функциональность делать дальше.
Про MVP можно было бы сказать, что, по сути, это возможность прохождения основных сквозных сценариев по автоматизируемому бизнес-процессу. Большая система может состоять из множества функциональных частей, и в каждой может быть свой или даже несколько MVP. Фокус внимания аналитика будет на функциональности, которая относится к основному сценарию. Альтернативные ветви бизнес-процесса можно отложить на следующий этап проекта. Это простая формула, подход, который многим знаком и который уже давно успешно используется. Быстрый выход на создание базовой функциональности системы способствует снижению стресса и напряжённости на проекте. Но есть нюанс – аналитический долг, о котором мы говорили на вебинаре «Когда методы не спасают: психология требований в эпоху Agile и ИИ». Чрезмерная погоня за демонстрацией быстрых результатов в формате MVP может обернуться недостаточной проработанностью даже основных сценариев и потенциальными сюрпризами в дальнейшем с необходимостью переделывать архитектуру решения.
Рисунок 2. Слайд из презентации вебинара «Когда методы не спасают: психология требований в эпоху Agile и ИИ»
Таким образом идея MVP помогает нам быстрее выходить на работоспособную основу системы. Заказчик видит результат, неопределённость и тревога снижаются. Защитные реакции, будь то выпадение из контакта или нагнетание, не возникают и не нарушают работу на проекте. При этом аналитики должны заботиться о том, чтобы не накапливался аналитический долг, чтобы результат был надёжным в долгосрочной перспективе.
Подход создания продукта через MVP в большей степени сфокусирован на функциональности, чтобы пользователи в принципе могли выполнять необходимые действия в системе. Несмотря на все плюсы и преимущества MVP, в 2013 году Брайан де Хафф вводит понятие Minimum Lovable Product (MLP), смещая акцент в сторону качества и обращая внимание на то, что есть некий минимальный уровень качества, ниже которого негатив восприятия заказчиком нового продукта может превышать преимущества быстрого выпуска MVP. В большей мере это касается ситуации, когда заказчик может сравнивать различные предложения на рынке и выбирать между ними. Вывод на рынок некачественного MVP может разочаровать потенциальных клиентов и привести к их потере. Недаром говорят, что «первое впечатление можно произвести только один раз». И если в условиях конкуренции предлагать просто функциональность, которая как-то решает определённые задачи, но не вызывает позитивных эмоций у пользователей, то такую систему могут заменить без сожаления. А вот с продуктом, который нравится, заказчику не захочется расставаться.
Опыт многих производителей программных продуктов подтвердил жизнеспособность подхода MLP, и эта концепция стала широко применяться. Уже на ранних стадиях создания нового продукта, при подготовке прототипов и проверке гипотез, команды разработчиков заботятся о том, чтобы продукт стал любимым, уделяют особое внимание UX/UI, выясняют с пользователями, что их радует, цепляет, что для них не просто важно с точки зрения функций, но что им нравится, поднимает им настроение.
Выявляя границы MVP и оперативно создавая наглядные прототипы, мы можем стабилизировать эмоциональный фон проекта и продуктивно взаимодействовать с заказчиком. В случае с MLP мы можем уже на самых первых этапах работ получить от заказчика ещё более позитивный отклик, ещё больший прилив внимания, усилий и активности с его стороны. Потому что основная функциональность не просто работает, а заказчику нравится, как она выглядит и как работает, и хочется продолжать взаимодействовать и с продуктом, и с командой разработчика. Заказчик вовлечён эмоционально, у него есть интерес к тому, что происходит на проекте.
Но за преимущества MLP приходится платить – на начальном этапе увеличиваются сроки и трудоёмкость разработки.
Для наглядности сравним подходы:
|
Критерий |
MVP |
MLP |
|
Цель |
Проверить гипотезу, оперативно получить какую-то часть работающей функциональности, получить обратную связь. |
Сформировать эмоциональную привязанность, лояльность. |
|
Фокус |
Функциональность, стабильность основного сценария. |
Впечатление, дизайн, «вау-эффект» даже на малом успешно функционирующем объёме. |
|
Риск |
Заказчик может счесть продукт «сырым» и потерять веру. |
Застревание в деталях, перерасход ресурсов на «полировку» решения раньше времени. |
|
Когда применять |
На старте, при высоком уровне неопределённости требований. |
Когда базовая ценность уже подтверждена и нужно удерживать приверженность заказчика проекту или продукту. |
MVP не гарантирует, что результат будет нравиться заказчику. А MLP выглядит более клиентоориентированным, но есть риск слишком сильно и слишком рано уйти в детали. При этом MLP не отменяет MVP, а скорее дополняет и расширяет возможности сотрудничества заказчика с командой разработчика. Оба подхода могут помогать в реализации проектов, но в каждом конкретном случае необходимо искать свой баланс скорости и качества.
Ведущий консультант, тренер
Проводит курсы:
Хочется выразить благодарность организаторам и участникам – было интересно и полезно!
