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