Если бы Globo.com воспользовалась этим определением для своего первого релиза, то, скорее всего, получила бы плохой результат. Проделанная работа не впечатлила бы никого. Компания потерпела бы убытки, и для нее гораздо лучше было бы вообще ничего не выпускать.
Когда говорят о живом организме, под словом «жизнеспособный» обычно понимают, что организм может выжить в нашем мире. К программному обеспечению это тоже относится.
Минимально жизнеспособный продукт – это продукт минимального объема, при выпуске которого успешно достигаются желаемые результаты.
Это определение мне нравится больше всего. «Минимальный» – субъективная характеристика, поэтому вам нужен конкретный субъект для определения минимума и этот субъект не вы. Точно определите, кто ваши заказчики и пользователи и что им нужно для решения их задач. Что им минимально необходимо? Я клянусь вам, это сильно облегчит обсуждение. Есть, правда, и альтернатива – когда решение принимают вышестоящие лица, но это намного хуже.
В настоящее время я предпочитаю термин «минимально жизнеспособное решение». В большинстве случаев, когда я сотрудничаю с организациями, мы не работаем над полностью новыми продуктами. Чаще всего это какие-то новые функции или возможности, улучшения уже имеющихся функций. Поэтому термин «решение» здесь более уместен. Поэтому давайте пересмотрим мое определение.
Минимально жизнеспособное решение – это самое простое решение, при воплощении которого в жизнь успешно достигаются желаемые результаты.
А сейчас мы приступим к трудной части…
Все это только гипотезы.
Когда мы отделяем какой-то набор функциональностей программы и называем это минимально жизнеспособным решением, мы не можем точно знать, что это так.
Проблема с оценкой результатов заключается в том, что увидеть их вы можете лишь тогда, когда все уже сделано. Определяя, что войдет в релиз, вам приходится предполагать, что будет. Придется представить себе заказчиков, которые купят ваш продукт, и пользователей, которые выберут именно его, если смогут, а кроме того, учесть, что вы реально успеете сделать за имеющееся время. Вам придется предполагать, сколько нужно сделать, чтобы пользователи были довольны. Очень много предположений.
Это и в самом деле сложно, ведь если вы запланируете меньше необходимого, то есть меньше минимума, то у вас ничего хорошего не выйдет. А если больше (к чему, как правило, склонны люди в попытке перестраховаться), то потратите слишком много денег и велик будет риск вообще не справиться с задачей. И самый плохой вариант – может оказаться, что вы изначально выбрали неверное направление и поэтому не сделали ровным счетом ничего полезного.
Поэтому неудивительно, что определение, где фигурирует «худший продукт, который вы можете выпустить», до сих пор так распространено.
Новый МЖП вообще не продукт!
Некоторые из вас, вероятно, чувствовали небольшое раздражение, читая эти две главы. Возможно, вы сейчас думаете: «Джефф упускает из виду кучу важных вещей!» И, возможно, вы правы. Самые важные моменты, которые вы обсуждаете во время составления историй и карт историй, чаще всего такие.
• Где у нас самые большие и рискованные предположения? Где неопределенность?
• Что и где мы можем узнать, чтобы заменить предположения реальной информацией?
Таким образом, мы приходим к следующему определению МЖП, ставшему популярным благодаря книге Эрика Райса «Стартап по методологии Lean» (The Lean Startup, издательство Crown Business). Как часто случается, Эрику пришлось усвоить то, о чем мы сейчас говорили, на собственном горьком опыте. Эрик работал на компанию, выпустившую жизнеспособный, как там думали, продукт, но оказалось, что это не так. Эрик поступил разумно, устремив свое внимание на изучение фактов – проверку всех тех предположений, которые сделали в компании перед выпуском первого релиза МЖП. Он заключил, что мы должны ставить небольшие эксперименты, делать прототипы и проверять наши гипотезы о том, что минимально и жизнеспособно. Если вы последуете примеру Эрика, что я рекомендую сделать, ваш первый продукт будет, по сути, экспериментом, а также следующий и так до тех пор, пока не убедитесь, что сделали нечто действительно стоящее.
Минимально жизнеспособный продукт – это также нечто наименьшее из того, что вы можете сделать или создать, чтобы доказать или опровергнуть предположение.
Поскольку ребята из Globo.com смогли запланировать разработать меньше, они не обманывали сами себя. Они осознавали, что предстоит еще много работы, чтобы доказать правоту своих предположений, так что теперь и они, и все остальные должны закладывать в план много исследовательской работы. С этого мы и начнем разговор в следующей главе.
Глава 3. План быстрых исследований
Это мой друг Эрик, стоящий перед своим бэклогом и доской задач в кабинете своей команды. Эрик – владелец продукта; он и его команда тяжело работают, чтобы выпустить успешный продукт, но пока не добились этого. Впрочем, это не слишком беспокоит Эрика, ведь у него есть стратегия достижения успеха. И она обязательно сработает.
Эрик работает на компанию под названием Liquidnet – огромную торговую сеть для крупных инвестиционных организаций. Задолго до того, как Эрик сфотографировался перед своей доской, кто-то в этой компании обнаружил группу заказчиков, которых Liquidnet могла бы обслуживать лучше, а также выдвинул пару предложений, как это сделать. Эрик был в команде, которая начала работу с этими идеями. Это работа владельцев продукта. Не думайте, что эти люди всегда работают только со своими собственными идеями, это не так. Одна из самых больших сложностей в работе владельца продукта – принять чье-то предложение и продвигать его до воплощения в жизнь или, напротив, доказать его несостоятельность. Лучшие владельцы продуктов вроде Эрика включают в эту работу всю команду.
Начните с обсуждения перспектив
Эрик начал свою работу вовсе не с составления бэклога пользовательских историй. Оттолкнувшись от отличной идеи, пришедшей кому-то в голову, он рассмотрел ее как благоприятную возможность для всей компании, чем она на самом деле и являлась. Он говорил об идее с руководством компании, обсуждалось следующее.
В чем состоит идея?
Кто эти заказчики? Что за компании, как мы предполагаем, будут покупать продукт?
Кто наши пользователи? Какие типы людей в этих компаниях, мы считаем, будут использовать продукт и для чего?
Почему он им нужен? Какие задачи заказчиков и пользователей решит продукт и почему они не могут решить их сегодня? Какие преимущества получат эти люди, купив продукт и начав его использовать?
