Это статья на основе поста Хенрика Книберга «Понимание MVP — и почему вместо него я предпочитаю ранний тестируемый / годный к употреблению / привлекательный продукт».
Пару лет назад Хенрик нарисовал эту картинку и использовал её в презентациях о гибкой и бережливой разработке:
Этот рисунок завирусился. Он появляется повсюду, даже в профильных книгах, типа "User Story Mapping" Джеффа Паттона. Многие говорят, что этот набросок действительно отражает суть итеративной и инкрементальной разработки, Lean-стартапа, MVP и всего прочего. Но некоторые неверно истолковывают его. Это вполне естественно, когда вы вырываете картинку из контекста. Некоторые критикуют рисунок за упрощение вещей, и это правда. Картинка очень метафорична.
Речь идёт не о реальной разработке автомобиля, а о продукте в целом. Метафора — автомобиль. Но цель не построить автомобиль, а решить задачу «Как добраться из точки А в точку Б».
Первый пример — не так
Верхний ряд иллюстрирует распространённое заблуждение об итеративной, постепенной разработке продукта (a.k.a Agile).
Проекты часто терпят неудачу, потому что хотят выполнить всё и сразу: построить продукт на 100% и зарелизить в конце. Однако, когда Agile приводится как альтернатива, люди отказываются от идеи выпустить незавершённый продукт — кому нужна половина автомобиля?
Вообразите это: «Вот, сэр, наша первая итерация, переднее колесо. Что вы думаете?»
Клиент говорит: «Какого чёрта ты показываешь мне шины? Я заказывал АВТОМОБИЛЬ! Что мне с этим делать?» (Здесь термин «клиент» используется в качестве общего термина для обозначения таких людей, как менеджеры по продукту, владельцы продуктов и пользователи). С каждой поставкой продукт становится ближе к завершению, но клиент всё ещё злится, потому что он не может фактически использовать продукт. Это всё ещё частичный автомобиль. И наконец, когда продукт готов, клиент говорит: «Спасибо! Наконец-то! Почему вы просто не показали это сразу и не пропустили все другие бесполезные релизы?»
В этом примере клиент доволен конечным продуктом, потому что это именно то, что он заказывал. Но обычно это не так. Большой период прошёл без реального пользовательского тестирования. Продукт, скорее всего, пронизан недостатками в дизайне, основанными на неправильных предположениях о том, что нужно людям. Так что довольный заказчик в конце — это довольно идеалистично.
Этот пример представляет собой «убитый аджайл». Технически это может быть инкрементная и итеративная поставка, но отсутствие реального цикла обратной связи делает его очень рискованным — и совершенно не гибким.
Отсюда и заголовок «Не так».
Второй пример - вот так!
Теперь поговорим о примере из второй строки.
Здесь используется совершенно другой подход. Начнём с того же контекста — заказчик заказал машину. Но на этот раз мы не просто строим машину. Вместо этого мы сосредотачиваемся на основной потребности, которую хочет решить клиент. Оказывается, его основной потребностью является «мне нужно быстрее добраться из А в Б», и автомобиль — лишь одно из возможных решений этого. Помните, автомобиль — это просто метафора, подумайте о любой ситуации, связанной с разработкой продукта.
Таким образом, команда обеспечивает самое меньшее решение, чтобы клиент проверял его и давал обратную связь. Некоторые могут назвать его MVP (минимально жизнеспособным продуктом), но Хенрик предпочитает называть его «Самый ранний тестируемый продукт».
Как ни назови, но клиент вряд ли будет доволен этим. Это и рядом не стояло с машиной. Но это нормально! Мы не пытаемся сделать клиента счастливым на данный момент. Мы могли бы порадовать нескольких ранних пользователей, но наша главная цель сейчас — просто учиться. В идеале команда заранее чётко объясняет это клиенту, поэтому он не слишком разочарован.
Однако, в отличие от колеса в первом сценарии, скейтборд уже является полезным продуктом, который помогает клиенту добраться из А в В. Не очень эффективно, но это чуть-чуть лучше, чем ничего. Поэтому мы говорим клиенту: «Не волнуйтесь, проект не завершён, это была только первая из многих итераций. Мы по-прежнему стремимся построить автомобиль, но пока, пожалуйста, попробуйте это и дайте нам обратную связь». Думайте масштабно, но выпускайте продукт небольшими функционально жизнеспособными приращениями.
Мы можем узнать некоторые действительно неожиданные вещи. Предположим, клиент говорит, что он ненавидит скейтборд. Мы спрашиваем, почему, и он отвечает: «Я ненавижу такой цвет». Мы такие: «Эээ… цвет? Это всё?» И клиент говорит: «Да, сделай его синим! Кроме этого, все хорошо!». Вы только что сэкономили много денег, не создавая всю машину! Маловероятно, но кто знает?
Ключевой вопрос: «Какой самый дешёвый и быстрый способ начать узнавать?» Можем ли мы доставить что-то ещё раньше, чем скейтборд? Как насчет билета на автобус?
Поможет ли это решить проблему клиента? Может быть, да, а может и нет, но мы обязательно кое-что узнаем, передав это в руки реальных пользователей. Lean Startup предлагает отличную модель: она основана на перечислении реальных гипотез о пользователях и их систематической проверке.
Вам не нужно тестировать продукт на всех пользователях и вам не нужно создавать весь продукт для тестирования чего-либо. Тестирование прототипа даже на одном пользователе научит команду в большей степени, чем вообще ничего.
Но ладно, вернёмся к примеру с скейтбордом.
Поиграв с ним в офисе, клиент говорит: «Хорошо, довольно весело, и он быстрее доставляет меня к кофеварке. Но он нестабильный. Я легко с него падаю». Поэтому на следующей итерации мы пытаемся решить эту проблему или хотя бы узнать о ней больше.
У скейтборда появляется ручка, это, кажется, самокат? (рис. 2) Теперь клиент может объехать офис, не сваливаясь!
Он счастлив? Не совсем, он всё ещё хочет машину. Но пока он на самом деле использует продукт и даёт нам обратную связь. Его самая большая жалоба сейчас в том, что трудно преодолевать большие расстояния, например, между зданиями, из-за маленьких колес. Итак, следующий выпуск продукта превращается в нечто вроде велосипеда.
По ходу дела мы узнаём кое-что: клиенту нравится ощущение свежего воздуха, ветерок в лицо. Клиент живёт в университетском городке, и транспорт тут нужен только для перемещения между зданиями. Велосипед может оказаться гораздо лучшим вариантом, чем предполагалось изначально. Тестируя этот продукт, мы можем узнать, что дорожки слишком узкие для автомобиля. Мы просто сэкономили клиенту кучу времени и денег и дали ему лучший продукт за меньшее время!
Теперь вы можете подумать: «Но разве мы не знали об этом? Через предварительный анализ контекста и потребностей клиента?» Хороший вопрос. В большинстве реальных сценариев разработки продуктов вы всё равно удивляетесь, когда передаёте первый релиз в руки реального пользователя. И это не смотря на то, сколь глубоко вы проводили исследование до начала работы.
Так что да, сделайте предварительный анализ, узнайте как можно больше, прежде чем начинать разработку. Но не тратьте на это слишком много времени. Вместо этого начните создавать и выпускать прототипы, и тогда будет настоящее обучение.
Вернёмся к истории. Возможно, клиент хочет большего. Иногда ему нужно съездить в другой город, и для этого поездка на велосипеде слишком медленная и утомительная. Итак, в следующей итерации мы добавим движок.
Эта модель особенно подходит для программного обеспечения, так как его можно «трансформировать» по ходу работы, в отличие от более жёстких вещей. Но даже с такими вещами можно работать, делать прототипы и наблюдать, как клиент использует продукт. Просто тогда итерации имеют тенденцию быть немного длиннее (месяцы вместо недель). Даже настоящие автомобильные компании, такие как Toyota и Tesla, делают много прототипов (эскизы, 3d-модели, натуральные модели и т. д.).
Что теперь? Опять же, возможно, клиент доволен мотоциклом. Мы могли бы закончить проект раньше, чем планировалось. Большинство продуктов пронизаны лишней сложностью и функциями, которые никто не использует. Итеративный подход — это способ найти самый простой и дешёвый способ решения проблемы клиента.
Или, опять же, клиент может продолжить разработку, с изменениями или без. На самом деле мы можем получить тот же автомобиль, который изначально предполагался. Однако гораздо более вероятно, что мы получим жизненно важные идеи по пути и в итоге разработаем что-то немного другое. Например, кабриолет.
Клиент очень доволен! Почему? Поскольку мы узнали, что он ценит свежий воздух, мы получили кабриолет. В конце концов, он получил машину, но лучше, чем планировалось изначально!
Какой у тебя скейтборд?
Первый сценарий (поставка одного колеса) — отстой, потому что мы продолжаем выпускать вещи, которые клиент вообще не может использовать. Если вы знаете, что делаете (возможно, вы уже сотню раз создавали подобные вещи), тогда продолжайте и выпустите всё сразу.
Однако большинство усилий по разработке продукта слишком сложны и рискованны для этого. Итак, ключевой вопрос: каков твой скейтборд?
При разработке продукта, первое, что вы должны сделать (после описания проблемы, которую вы пытаетесь решить для кого-то), — это определить эквивалент вашего скейтборда. Думайте о скейтборде как о метафоре самой маленькой вещи. Её вы можете передать реальным пользователям и получить реальную обратную связь. Или используйте «билет на автобус», если эта метафора работает лучше.
Это обеспечит жизненно необходимую петлю обратной связи и даст вам и заказчику контроль над проектом. Вы сможете учиться и вносить изменения, а не просто следовать плану и надеяться на лучшее.
Давайте рассмотрим примеры из жизни:
- Spotify сперва разработали потоковый сервис для трёх песен, который откликался почти мгновенно.
- Minecraft был выпущен после 6 дней кодирования. Можно было выкапывать блоки и ставить их в других местах.
- Большой правительственный проект тестируется только в одном регионе и с одной-двумя функциями, которые облегчают бюрократию.
- Lego сначала тестируют новые миры на бумажных фигурках и детях в офисе.
Улучшение «MVP»
Мы подошли к теме MVP — минимально жизнеспособному продукту.
Основная идея хороша, но сам термин вызывает много путаницы. Автор статьи встречал много клиентов, которые говорили: «Я ни в коем случае не хочу, чтобы поставка MVP была последней!». Слишком часто команды выпускают так называемый минимально жизнеспособный продукт, а затем переходят к другому проекту. Клиент остается с глючным, незаконченным продуктом. Для некоторых клиентов MVP равно MRC (минимально зарелизенная хрень).
Я знаю, что всё сводится к плохому управлению, а не к термину MVP, но все же ... этот термин вызывает недопонимание. «Минимальный» и «Жизнеспособный» означают разные вещи для разных людей, и это вызывает проблемы.
Так что вот альтернатива.
Прежде всего, замените слово «минимальный» на «ранний». Основная идея выпуска MVP состоит в том, чтобы получить обратную связь на раннем этапе. Немногие клиенты хотят «минимум», но большинство клиентов хотят «рано»! Итак, это наше первое изменение:
Минимальный => Самый ранний
Затем уберите слово «Жизнеспособный», так как оно слишком расплывчато. Твой «жизнеспособный» = мой «ужасный». Итак, давайте будем более явными и разделим это на три разные вещи:
Самым ранним тестируемым продуктом является билет на автобус или скейтборд. Это может не решить проблему, но такой выпуск генерирует хоть какую-то обратную связь.
Самый ранний пригодный для использования продукт — возможно, велосипед. Первый релиз, который действительно будут охотно использовать ранние пользователи.
Возможно, самым ранним привлекательным продуктом является мотоцикл. Первый релиз, который клиенты полюбят, расскажут друзьям и захотят купить.
Я подумал о добавлении еще более раннего шага «Самый ранний продукт с обратной связью», который представляет собой бумажный прототип или эквивалент, который вы используете, чтобы получить свой первый отзыв от клиента. Но четыре шага... кажется это уже слишком много. Тем не менее, это тоже важный шаг.
Конечно, люди все еще могут неверно истолковать «Самый ранний тестируемый/пригодный для использования/привлекательный», но это, по крайней мере, чуть-чуть более конкретно.
Итоги
Спасибо, что дочитали до этого момента. Итак, ключевые мысли:
- Избегайте поставки всего и сразу при разработке сложных, инновационных продуктов. Делайте это итеративно и постепенно. Вы уже знали это правило. Но на самом ли деле выполняли?
- Начните с определения вашего «скейтборда» — самого раннего тестируемого продукта. Стремитесь выше, но усмирите свою гордость и начните с выпуска скейтборда.
- Избегайте термина MVP. Будьте более откровенны в том, о чём вы на самом деле говорите. Самый ранний тестируемый/пригодный для использования/привлекательный — это всего лишь один пример. Используйте те термины, которые меньше всего запутывают ваших заинтересованных лиц.
- И помните, рисунок скейтборда-автомобиля — это просто метафора. Не воспринимайте это слишком буквально.