Минимально жизнеспособный продукт (minimum viable product, MVP) — продукт, обладающий минимальными, но достаточными для удовлетворения первых потребителей функциями
Сейчас очень много статей на тему. Большая часть из них посвящена стартапам и продуктовым ИТ компаниям.
Но MVP - это очень полезная в разработке вещь вообще.
И здесь я поделюсь опытом применения концепции MVP в рамках разработки в сервисных подразделениях не ИТ компаний.
Итак, у нас есть разработчик (и возможно даже не один).
Вы их руководитель.
Они на окладе и у вас не болит голова от того, чем им платить в конце месяца зарплату.
И у вас есть заказчики. Внутренние, но от этого не менее важные и любимые :-)
И однажды у кого-то в компании рождается мысль, а давайте разработем продукт Х.
Так, желаение заказчика есть, у него есть полномочия и он готов работать.
Поехали.
Хорошо, если процесс, который мы закладываем в продукт есть. И он хоть на какой-то стадии автоматизации.
Но чаще всего поставленный процесс в том же Эксель - это просто мечта аналитика. Суровая реальность чаще всего такова, что не то, что Экселя нет, нет и самого процесса. Людям нужно дать инструмент и научить их делать с помощью него работу. То, что я называю "поставить процесс".
И вот здесь начинаются сложности.
Если начать спрашивать у людей что же им нужно, какие именно функции должен содержать будущий продукт, мы скорее всего получим набор "космических хотелок" мало связанных с реальностью. Потому, что:
- "Вдруг руководитель прочтет? Надо думать на перспективу!". И заказываются некие вещи, которые, возможно, понадобятся потом, в светлом будущем.
- "На всякий случай". В этом случае заказывается все подряд, и побольше.
- "Процесс не понятен, поэтому и потребности тоже". Потребностей нет вообще.
Ок.
Можно взять все эти потребности, совсем уж "космос" убрать и начать работу.
(Про оклад у разработчиков помним? Заказчики есть, запрос есть - работаем!)
Но шансов в итоге все ж поднять процесс и внедрить продукт не очень много. Особенно если идти по классическому водопаду.
Но главное, набор "космических хотелок" будет увеличиваться.
На каждой демонстрации будут вспоминаться "забытые" новые важные "бантики" без которых "не взлететь".
Специфика внутренней разработки заключается в том, что по ходу проекта менять требования легче. Особенно добавлять их.
(Конечно у настоящих РМов и настоящих аналитиков такого не происходит. У них все проекты всегда в срок и 100% попаданием в бюджет. А ТЗ точны и понятны. Но мы сейчас не о них...)
Так вот, разработка идет и параллельно растет бэклог из "космических бантиков очень важных и нужных". Конца и края этому не видно. Особенно если пользователи особо никакой автоматизации-то и не хотят (помним про Шарика с фоторужьем?). Проект рискует превратиться в проект-камикадзе.
Тупик.
И вот здесь концепт MVP дает шанс на выживание.
Делаем минимум. На котором можно работать. Возможно неудобно, медленно, часть вещей не автоматически, но можно.
И отдаем пользователям. Точнее пытаемся отдать.
Если оно особо никому не надо - сворачиваем проект. Это еще легко сделать, так как на него не потрачено много человеко-часов работы. Демотивации почти не будет. Даже наоборот - радость от того, что не убили много времени в никуда.
Если же оно реально надо, то пользователи возьмут MVP.
Главное MVP не должен ухудшать текущее положение пользователя. В сумме. По модулю. Т.е. где-то может и неудобно, и даже сложнее, но где-то легче, а, главное, видна перспектива.
И вот тут, после того как пользователи начали РЕАЛЬНО работать с продуктом, вал "космических хотелок" заканчивается. Появляется обратная связь. Четкие конкретные предложения. Команда выходит в режим. Появляется "драйв" - от того, что каждый видит результаты своего труда (одни попросили-получили, вторые сделали и оно нужно, оно принято).
Все. Дальше шансов нет - проект завершится успехом.
И, даже если проект небольшой, все равно это будет здорово.
