Книга: Пользовательские истории. Искусство гибкой разработки ПО

Почему никто не любит МЖП

Почему никто не любит МЖП

Термин «минимально жизнеспособный продукт» (МЖП) давно используется в индустрии программного обеспечения. Хотя первое его употребление приписывают Фрэнку Робинсону, сейчас более популярны определения Эрика Райса или Стива Бланка. Хотя множество умных людей пытались объяснить, что такое МЖП, многие, включая меня, так и не могут толком разобраться в этом понятии. В каждой организации, где мне доводилось слышать этот термин, под ним подразумевалось что-то свое. Бывало даже, что люди, работавшие в одной организации, в разговорах друг с другом подразумевали под МЖП разные вещи.

Как и большинство слов в словаре, этот термин имеет несколько значений. Я приведу три примера определений: одно плохое и два хороших.

Начнем с плохого.

Но МЖП – это не продукт, с которым могут работать ваши пользователи, – разве что в самых простых обстоятельствах, да и то при условии высокого болевого порога. Тем не менее я регулярно вижу организации, пытающиеся довести до ума ужасные продуктовые решения, чтобы «кто-нибудь мог использовать продукт», хотя каждому участнику этой работы очевидно, что он сам не стал бы с ним мучиться.

Если бы Globo.com воспользовалась этим определением для своего первого релиза, то, скорее всего, получила бы плохой результат. Проделанная работа не впечатлила бы никого. Компания потерпела бы убытки, и для нее гораздо лучше было бы вообще ничего не выпускать.

Когда говорят о живом организме, под словом «жизнеспособный» обычно понимают, что организм может выжить в нашем мире. К программному обеспечению это тоже относится.

Это определение мне нравится больше всего. «Минимальный» – субъективная характеристика, поэтому вам нужен конкретный субъект для определения минимума и этот субъект не вы. Точно определите, кто ваши заказчики и пользователи и что им нужно для решения их задач. Что им минимально необходимо? Я клянусь вам, это сильно облегчит обсуждение. Есть, правда, и альтернатива – когда решение принимают вышестоящие лица, но это намного хуже.

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

А сейчас мы приступим к трудной части…

Все это только гипотезы.

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

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

Это и в самом деле сложно, ведь если вы запланируете меньше необходимого, то есть меньше минимума, то у вас ничего хорошего не выйдет. А если больше (к чему, как правило, склонны люди в попытке перестраховаться), то потратите слишком много денег и велик будет риск вообще не справиться с задачей. И самый плохой вариант – может оказаться, что вы изначально выбрали неверное направление и поэтому не сделали ровным счетом ничего полезного.

Поэтому неудивительно, что определение, где фигурирует «худший продукт, который вы можете выпустить», до сих пор так распространено.

Оглавление книги