Пару лет назад я нарисовал эту картинку и начал использовать ее в различных презентацией по гибкой разработке:
С тех пор рисунок стал вирусным! Появляется повсюду, в статьях и презентациях, даже в книге (User Story Mapping Джефф Паттон). Многие говорят мне, что рисунок действительно отражает суть итеративной и поэтапной разработки, бережливого стартапа, минимально жизнеспособного продукта (MVP) и так далее. Однако некоторые неверное его истолковывают, что вполне естественно, когда вы вырываете изображение из исходного контекста. Некоторые критикуют его чрезмерное упрощение, и это правда. Рисунок является метафорой. Речь идет не о фактической разработки автомобиля, а о разработке продукта в целом, используя автомобиль как метафору.
Первый пример - как не надо
Верхний сценарий иллюстрирует распростаненное заблуждение об итеративной, поэтопной разработке продукта (также известной как Agile).
Многие проекты терпят неудачу из-за того, что они делают "Большой взрыв" (создают продукт до 100% готовности и сдают в конце ). Я потерял счет количеству неудачных проектов, которые "погибали" из-за этого. Однако, когда Agile представляют, как альтернативу, люди иногда отказываются от идеи незавершенного продукта - кому нужна половина машины? Представьте себе это:
"Уважаемый клиент, вот наша первая итерация, передняя шина. Что вы думаете?"
Клиент такое: "Какого черта вы доставляете мне шины? Я заказал АВТОМОБИЛЬ! Что мне с этим делать?"
Кстати, здесь используется "клиент" как обобщающий термин для обозначения разных людей - менеджеры продукта, владельцы продукта, ранние пользователи.
С каждой доставкой продукт становится все ближе к завершению, но все еще злится, потому что он не может использовать продукт. Это все еще не полный автомобиль.
И, наконец, когда продукт готов, клиент говорит: "Спасибо"! Окончательно! Почему ты сразу не доставил автомобиль и не пропустил все остальные бесполезные доставки?
В этом примере он доволен конечным продуктом, потому что это то, что он заказал. На самом деле это обычно не так. Прошло много времени без фактического пользовательского тестирования, поэтому продукт, скорее всего, пронизан недостатками, основанными на неверных предположениях того, что нужно людям. Так что смайли в конце идеализирован.
Во всяком случае верхний сценарий представляет собой "кривой" agile. Технически это может быть инкрементная и итеративная поставка, но отсутствие реального цикла обратной связи делает его очень рискованным и определенно не гибким.
Отсюда и заголовок "как не надо".
Второй урок - как надо!
Теперь о втором сценарии.
Здесь мы используем совсем другой подход. Начнем с того же контекста - клиент заказал машину. Но на этот раз мы не просто строим машину. Вместо этого мы фокусируемся на основной потребности, которую клиент хочет удовлетворить. Оказывается, его основной потребностью является "мне нужно быстрее добраться из точки А в точку Б", и машина - лишь одно из возможных решений этой проблемы. Помните, что автомобиль это всего лишь метафора, подумайте о любой индивидуальной ситуации с разработкой продукта.
Таким образом, команда предлагает наименьшее из того, что они могут придумать, что заставит клиента протестировать что-то и дать обратную связь. Кто-то может назвать его минимально жизнеспособный продукт (MVP), но я предпочитаю его самым ранним тестируемом продуктом.
Вы можете называть это как хотите.
Клиента это вряд ли обрадует. Это далеко не та машина, которую он заказал. Но это нормально! Вот в чем фишка - на данным момент мы не пытаемся осчастливить заказчик. Мы можем осчастливить нескольких первопроходцев, но наша главная цель на данном этапе - просто учиться. В идеале команда за ранее это объясняет клиенту, что бы он сильно не разочаровался.
Однако в отличие от переднего колеса в первом примере, скейтборд является полезным продуктом, который помогает покупателю добраться из точки А в точку Б. Не очень хорошо, но немного лучше, чем ничего. Поэтому мы говорим клиенту: «Не волнуйтесь, проект еще не закончен, это была только первая из многих итераций. Мы все еще стремимся построить автомобиль, а пока, пожалуйста, попробуйте это и дайте нам обратную связь». Думайте масштабно, но делайте это небольшими функционально жизнеспособными шагами.
Благодаря такому подходу мы можем узнать действительно удивительные вещи. Предположим, клиент говорит, что ненавидит скейтборд. Мы спрашиваем, почему, и он отвечает: "Я ненавижу цвет". Мы в ответ: "Эээ... цвет?! И это все?". А клиент говорит: "Ага, сделайте его синим! В остальном все хорошо!" Вы только что сэкономили ресурсы, не строя машину. Маловероятно, но кто знает?
Ключевой вопрос: «Каким самым дешевым и быстрым способом мы можем начать учиться?» Можем ли мы доставить что-то еще раньше, чем скейтборд? Как насчет автобусного билета?
Поможет ли это решить проблему клиента? Может быть, а может и нет, но мы обязательно чему-то научимся, отдав это в руки реальным пользователям. "Бережливый стартап" предлагает отличную модель, основанную на составлении списка ваших фактических гипотез о пользователях и последующей систематической работе по их проверке или опровержению.
Вам не нужно тестировать продукт на всех пользователях, и вам не нужно создавать продукт, чтобы что-то тестировать. Тестирование прототипа даже на одном пользователе научит вас больше, чем ничему.
Но ладно, вернемся к примеру со скейтбордом.
Поэкспериментировав с ним в офисе, клиент говорит: «Хорошо, довольно весело, и я быстрее доберусь до кофемашины. Но это нестабильно. Я слишком легко падаю».
Поэтому на следующей итерации мы попытаемся решить эту проблему или, по крайней мере, узнать о ней больше.
Теперь клиент может передвигаться по офису, не падая!
Счастливый? Не совсем, он все еще хочет эту машину. Но в то же время он фактически использует этот продукт и дает нам обратную связь. Его самая большая жалоба заключается в том, что ему трудно преодолевать большие расстояния, например, между зданиями, из-за маленьких колес и отсутствия тормозов. Итак, в следующем выпуске продукт превращается в нечто вроде велосипеда.
Теперь клиент может передвигаться на более дальние расстояния.
По ходу дела мы узнаем кое-что: Клиенту нравится ощущение свежего воздуха на лице. Клиент находится в своем районе, и транспорт в основном связан с перемещением между зданиями.
Велосипед может оказаться намного лучшим продуктом, чем изначально предполагалось. На самом деле, тестируя этот продукт, мы можем узнать, что дорожки все равно слишком узки для автомобиля. Мы только что сэкономили клиенту массу времени и денег и предоставили ему лучший продукт за меньшее время!
Теперь вы можете подумать: «А разве мы не должны были уже знать это. посредством предварительного анализа контекста и потребностей клиента?» Хорошая точка зрения. Но в большинстве реальных сценариев разработки продукта, которые я видел, независимо от того, насколько тщательный предварительный анализ вы проведете, вы все равно будете удивлены, когда отдаете первый настоящий релиз в руки реального пользователя, и многие из ваших предположений окажутся далеко не те.
Так что да, проведите предварительный анализ, узнайте как можно больше, прежде чем начинать разработку. Но не тратьте на это слишком много времени и не слишком доверяйте анализу — вместо этого начните прототипировать и выпускать, именно тогда происходит настоящее обучение.
Впрочем, вернемся к истории. Возможно, клиент хочет большего. Иногда ему нужно поехать в другой город, а езда на велосипеде слишком медленная и утомительная. Итак, на следующей итерации мы добавляем двигатель.
Эта модель особенно подходит для программного обеспечения, так как программное обеспечение это, ну, софт. Вы можете «преобразовывать» продукт по ходу работы, в отличие от аппаратного обеспечения, которое вам, по сути, приходится каждый раз перестраивать. Тем не менее, даже в проектах с аппаратным обеспечением есть огромное преимущество в предоставлении прототипов, чтобы наблюдать и учиться на том, как клиент использует ваш продукт. Просто итерации, как правило, немного длиннее (месяцы вместо недель). Даже настоящие автомобильные компании, такие как Toyota и Tesla, делают много прототипов (эскизов, 3D-моделей, полномасштабных глиняных моделей и т. д.) перед разработкой новой модели автомобиля.
Ну что теперь? Опять же, возможно, покупатель доволен мотоциклом. Мы могли бы закончить проект раньше, чем планировалось. Большинство продуктов пронизаны сложностью и функциями, которые никто не использует. Итеративный подход на самом деле является способом сделать меньше или найти самый простой и дешевый способ решить проблему клиента.
Или, опять же, клиент может продолжить работу с изменениями требований или без них. На самом деле мы можем получить точно такой же автомобиль, как изначально предполагалось. Однако гораздо более вероятно, что мы получим важные идеи по пути и в итоге получим что-то немного другое. Так:
Клиент в восторге! Почему? Поскольку по пути мы узнали, что он ценит свежий воздух в лицо, мы остановились на кабриолете. В конце концов, он получил машину, но лучшую, чем планировалось изначально!
Итак, давайте сделаем шаг назад.
Какой у тебя скейтборд?
Верхний сценарий (доставка переднего колеса) — отстой, потому что мы продолжаем доставлять вещи, которые клиент вообще не может использовать. Если вы знаете, что делаете — у вашего продукта очень небольшая сложность и риск, возможно, вы уже создавали подобные вещи сотни раз — тогда вперед и просто сделайте большой взрыв. Постройте вещь и доставьте ее, когда закончите.
Тем не менее, большинство усилий по разработке продукта, которые я видел, слишком сложны и рискованны для этого, а подход «большого взрыва» слишком часто приводит к огромным дорогостоящим неудачам. Итак, ключевой вопрос: какой у вас скейтборд?
При разработке продукта одна из первых вещей, которую вы должны сделать (после описания проблемы, которую вы пытаетесь решить для кого) — это определить эквивалент скейтборда. Думайте о скейтборде как о самой маленькой вещи, которую вы можете дать в руки реальным пользователям и получить реальную обратную связь. Или используйте «автобусный билет», если эта метафора работает лучше.
Это даст вам жизненно необходимый цикл обратной связи и даст вам и клиенту контроль над проектом — вы сможете учиться и вносить изменения, вместо того, чтобы просто следовать плану и надеяться на лучшее.
Возьмем несколько примеров из реальной жизни.
Пример 1: Музыкальный проигрыватель Spotify
«С более чем 75 миллионами пользователей трудно вспомнить время без Spotify. Но было разное. Время, когда мы все обдумывали проходы куда пойдут новые компакт-диски. Время в нашей жизни, когда мы все "пиратили" музыку. Время, когда iTunes заставлял нас покупать песни по 2 доллара за штуку. А потом появился Spotify».
Spotify сейчас довольно модный продукт. Но все началось не так. Мне посчастливилось довольно рано принять участие в этом удивительном путешествии (и до сих пор им занимаюсь).
Как стартап в 2006 году, Spotify был основан на некоторых ключевых предположениях: люди счастливы транслировать (а не владеть) музыку, что лейблы и исполнители готовы позволить людям делать это на законных основаниях, и что быстрая и стабильная потоковая передача технически осуществима. Помните, это был 2006 год, когда потоковое воспроизведение музыки было ужасным опытом, а музыка, скопированная пиратами, была в значительной степени нормой. Техническая часть задачи заключалась в следующем: «Возможно ли вообще создать клиент, который воспроизводит музыку мгновенно, когда вы нажимаете кнопку «Воспроизвести»? Можно ли избавиться от надоедливого индикатора выполнения «Буферизация»?»
Начинать с малого не означает, что вы не можете мыслить масштабно. Вот один из первых набросков того, что они имели в виду:
Но вместо того, чтобы тратить годы на создание всего продукта, а затем выяснять, верны ли предположения, разработчики в основном сели и взломали технический прототип, вставили любую скопированную музыку, которая была у них на ноутбуках, и начали безумно экспериментировать, чтобы найти способы сделать воспроизведение быстрым и стабильным. Главным показателем было «сколько миллисекунд проходит с момента, когда я нажимаю Play, до момента, когда я слышу музыку?». Он должен воспроизводиться почти мгновенно и продолжать играть плавно, без заиканий!
«Мы потратили безумное количество времени, сосредотачиваясь на задержке, когда никого это не заботило, потому что мы были чертовски одержимы созданием ощущения, что у вас есть музыка со всего мира на вашем жестком диске. Одержимость мелкими деталями иногда может иметь решающее значение. Это то, что я считаю самым большим недоразумением относительно концепции минимально жизнеспособного продукта. Это буква V в MVP». - Даниэль Эк, соучредитель и генеральный директор
Получив что-то рабочее они начали проверять на себе и своих близких.
Первоначальная версия не могла быть выпущена для более широкой аудитории, она была совершенно необработанной и практически не имела никаких функций, кроме возможности найти и проиграть несколько жестко закодированных песен, и не было никакого юридического соглашения или экономической модели. Это был их скейтборд.
Но они без зазрения совести отдали скейтборд в руки реальным пользователям — друзьям и семье — и те быстро получили нужные им ответы. Да, это было технически возможно. И да, людям очень понравился продукт (или, скорее, то, чем продукт может стать)! Гипотезы подтвердились! Этот работающий прототип помог убедить музыкальные лейблы и инвесторов, а остальное уже история.
Пример 2: Minecraft
Minecraft — одна из самых успешных игр в истории разработки игр, особенно если принять во внимание стоимость разработки. Minecraft также является одним из самых экстремальных примеров мышления «выпускай раньше и чаще». Первый публичный релиз был сделан всего за 6 дней написания кода одним парнем! В первой версии вы мало что могли сделать — это был в основном уродливый блочный 3D-ландшафт, где вы могли выкапывать блоки и размещать их в другом месте, чтобы строить грубые структуры.
Это был скейтборд.
Тем не менее, пользователи были очень увлечены (большая часть общения между разработчиками и пользователями происходила через Twitter, довольно забавно). Среди первых пользователей были я и мои четверо детей. За первый год было выпущено более сотни релизов. Разработка игр — это поиск удовольствия (некоторые игровые компании, с которыми я работал, используют термин «определение удовольствия» вместо «определение готовности»), и лучший способ сделать это — заставить реальных людей играть в эту игру. — в данном случае тысячи реальных людей, которые действительно заплатили, чтобы попробовать версию с ранним доступом, и, следовательно, имели личный стимул помочь улучшить игру.
Постепенно вокруг игры сформировалась небольшая команда разработчиков (в основном 2 человека), и игра стала хитом во всем мире. Не думаю, что где-либо встречал ребенка, который бы не играл в Minecraft. А в прошлом году игра (точнее, компания, которая была создана вокруг игры) была продана Microsoft за 2,5 миллиарда долларов. Довольно удивительно.
Пример 3: Большой государственный проект
Примерно в 2010 году шведская полиция выступила с крупной инициативой, позволяющей полиции проводить больше времени в полевых условиях и меньше времени в участке - PUST (Polisens Utrednings STöd). Увлекательный проект, я участвовал в качестве тренера и написал книгу о том, что мы сделали и чему научились (Lean from the Trenches).
Идея заключалась в том, чтобы разместить в автомобилях ноутбуки и специальное программное обеспечение, чтобы дать полиции доступ к нужным им системам в режиме реального времени, например, во время допроса подозреваемого (это была эпоха до появления планшетов).
Они пытались построить подобные системы в прошлом и потерпели неудачу, в основном из-за мышления Большого Взрыва. Они сказали мне, что одна из их предыдущих попыток заняла 7 лет от начала до первого выпуска. СЕМЬ ЛЕТ! К тому времени, конечно, все изменилось, и проект полностью провалился. Так что на этот раз они хотели сделать это по-другому.
Проект с участием 60 человек (позже названный «PUST Java») оказался на удивление успешным, особенно для того, чтобы быть крупным государственным проектом (он даже занял второе место в номинации «Проект года» в номинации CIO Awards). Одним из главных факторов успеха было то, что они не пытались построить все сразу — они разделили слона на два измерения:
По регионам. Нам не нужно выпускать сразу для ВСЕЙ Швеции, мы могли бы начать с выпуска только для одного региона. По типу преступления. Нам не нужно изначально поддерживать ВСЕ типы преступлений, мы могли бы начать с поддержки только 1-2 типов преступлений.
Первой версией, 1.0, был их скейтборд.
Это была небольшая система, поддерживающая всего пару видов преступлений, и она была опробована на нескольких полицейских в Остергётланде (регион в Швеции). С остальными видами преступлений приходилось бороться по-старому – ехать на станцию и оформлять документы. Они знали, что являются морскими свинками и что продукт еще далеко не готов. Но они были рады проверить это, потому что знали альтернативу. Они видели, какие дрянные системы получаются в результате процессов, в которых отсутствует ранняя обратная связь с пользователями, и теперь у них, наконец, появилась возможность влиять на систему во время ее создания!
Их отзыв был жестким и честным. Многие из наших предположений вылетели в окно, и одна из больших дилемм заключалась в том, что делать со всеми тщательно разработанными спецификациями вариантов использования, которые становились все менее и менее актуальными по мере поступления реальных отзывов пользователей (это была организация с каскадной историей и привычка делать большой предварительный анализ).
Короче говоря, ранние отзывы были направлены на улучшение продукта, и постепенно, по мере того, как полицейским в Эстергётланде начинал нравиться продукт, мы могли добавлять больше типов преступлений и распространять его на большее количество регионов. К тому времени, когда мы добрались до большого релиза (1.4) с общенациональным развертыванием и обучением 12000 полицейских, мы уже не так сильно волновались. Мы сделали так много релизов, так много пользовательского тестирования, что мы хорошо выспались в ночь общенационального релиза.
К сожалению, победа была недолгой. Последующий проект (PUST Siebel) провалился и вернулся к водопадному мышлению, вероятно, по старой привычке. 2 года анализа и тестирования без каких-либо релизов или пользовательского тестирования, после чего последовал грандиозный выпуск «следующего поколения» продукта для всех 12 000 полицейских сразу. Это была настоящая катастрофа, и после полугода кровоизлияния они закрыли все это дело. Стоимость разработки составила около 20 миллионов евро, но, по оценкам внутренних исследований, ущерб для шведского общества (поскольку полиция была ограничена ужасной системой) составил порядка 1 миллиарда евро!
Довольно дорогой способ обучения!
Пример 4: Лего
В настоящее время я работаю в Lego, и я поражен их способностью выпускать новые хиты год за годом без каких-либо проблем. Я слышал много интересных историй о том, как они это делают, и общая тема — прототипирование и раннее пользовательское тестирование! Я часто вижу группы детей в офисе, а дизайнеры сотрудничают с местными детскими садами, школами и семьями, чтобы протестировать в полевых условиях новейшие идеи продуктов.
Вот недавний пример — Nexo Knights (выпущен в январе 2016 г.):
Когда они впервые начали изучать эту концепцию, они сделали бумажные прототипы и показали их маленьким детям. Первой реакцией детей было: «Эй, кто плохой парень? Я не вижу, кто хороший, а кто плохой!». Упс. Поэтому дизайнеры продолжали повторять и тестировать, пока не нашли дизайн, который понравился детям. Бьюсь об заклад, даже вы можете увидеть, кто хороший, а кто плохой на картинке выше…
Не уверен, где именно скейтборд в этой истории, но вы поняли — первые отзывы от реальных пользователей! Не просто проектируйте продукт, а стройте его целиком. Представьте, если бы они создали продукт на основе своих первоначальных предположений о дизайне и узнали о проблеме после того, как доставили тысячи коробок в магазины по всему миру!
У Lego также есть своя доля с трудом заработанных неудач. Одним из примеров является Lego Universe, массовый многопользовательский онлайн-мир Lego. Звучит весело, да? Проблема в том, что они стали слишком амбициозными и в конечном итоге попытались довести все до совершенства, прежде чем выпустить в мир.
Около 250 человек работали по 4-5 лет (из-за постоянного расползания масштабов из-за перфекционизма), и когда наконец вышел релиз, прием был… вялым. Готовая игра была красивой, но не такой увлекательной, как ожидалось, поэтому продукт был закрыт через 2 года.
Скейтборда не было!
Почему нет? Потому что скейтборды — это не круто (по крайней мере, если вы ожидаете автомобиль), а культура Lego заключается в том, чтобы дарить крутые впечатления! Если вы работаете в штаб-квартире Lego в Биллунде, Дания, вы каждый день проходите мимо этой огромной фрески:
Переводится примерно так «Только лучшее достаточно хорошо». Это был руководящий принцип Lego с тех пор, как компания была основана более 80 лет назад, и он помог ей стать одной из самых успешных компаний в мире. Но в данном случае принцип был применен неверно. Стремление к совершенству задержало жизненно важную обратную связь, что означало ошибочные предположения о том, что нравится и не нравится пользователям. Полная противоположность Minecraft.
Интересно, что команды разработчиков Lego Universe на самом деле использовали Scrum и много итерировали — точно так же, как ребята из Minecraft. Но релизы были только внутренние. Так что, скорее всего, был и скейтборд, и велосипед, и так далее, но до реальных пользователей эти продукты так и не дошли. Scrum предназначен не для этого.
Это был дорогостоящий провал, но Lego извлекла уроки из этого, и они постоянно совершенствуются в раннем тестировании и обратной связи с пользователями.
Улучшение «MVP»
И это (глубокий вдох…) подводит меня к теме MVP — минимально жизнеспособного продукта.
Основная идея великолепна, но сам термин вызывает много путаницы и беспокойства. Я встречал много клиентов, которые говорили: «Я ни за что не хочу доставку MVP — это последняя доставка, которую я получу!» Слишком часто команды создают так называемый минимально жизнеспособный продукт, а затем быстро переходят к следующему проекту, оставляя клиента с незаконченным продуктом и с ошибками.
Я знаю, я знаю, это связано с плохим управлением, а не с термином MVP, но все же… этот термин вызывает недопонимание. «Минимум» и «Жизнеспособность» означают разные вещи для разных людей, и это вызывает проблемы.
Итак, вот альтернатива.
Прежде всего, замените слово «Минимум» на «Ранний». Вся идея выпуска MVP заключается в том, чтобы получить раннюю обратную связь — предоставляя минимальный продукт, а не полный продукт, мы можем получить обратную связь раньше.
Немногие клиенты хотят «минимум», но большинство клиентов хотят «раньше»! Итак, это наше первое изменение:
Минимум = Самый ранний
Затем уберите слово «Жизнеспособный», так как оно слишком расплывчато. Ваше «жизнеспособное» — мое «ужасное». Некоторые люди думают, что жизнеспособный означает «что-то, что я могу протестировать и получить обратную связь», другие думают, что это означает «что-то, что клиент действительно может использовать». Итак, давайте будем более явными и разделим его на три разные вещи:
Минимально жизнеспособный = Самый ранний тестируемый/пригодный/привлекательный
Самый ранний тестируемый продукт — это скейтборд или автобусный билет — первый продукт, с которым покупатели действительно могут что-то делать. Может, это и не решит их проблему, но по крайней мере даст какую-то обратную связь. Мы очень четко заявляем, что главной целью этого релиза является обучение, и что любая реальная ценность для клиента будет бонусом.
Самый ранний пригодный продукт — возможно, это велосипед. Первый релиз, который первые последователи действительно будут использовать добровольно. Еще не все сделано, и это может быть не очень удобно. Но это ставит ваших клиентов в лучшее положение, чем раньше.
Самый ранний привлекательный продукт, пожалуй, мотоцикл. Первый релиз, который понравится покупателям, о котором они расскажут своим друзьям и за который будут готовы платить. Нам еще многое предстоит улучшить, и мы все еще можем получить кабриолет, или самолет, или что-то еще. Но мы достигли точки, когда у нас есть действительно рыночный продукт.
Я подумал о том, чтобы добавить еще более ранний шаг «Продукт с самой ранней обратной связью», который в основном представляет собой бумажный прототип или эквивалент, который вы используете, чтобы получить свой первый отзыв от клиента. Но четыре шага кажутся слишком большими. Но тем не менее, это тоже важный шаг. Кто-то назвал бы бумажный прототип самым ранним тестируемым продуктом, но я думаю, все зависит от того, как вы определяете тестируемый продукт. Ознакомьтесь с Руководством MVP Мартина, чтобы узнать больше — у него есть множество суперконкретных примеров того, как получить раннюю обратную связь с минимальными вложениями.
Конечно, люди по-прежнему могут неверно интерпретировать термин «Самый ранний тестируемый/пригодный для использования/привлекательный», но он по крайней мере на один шаг точнее, чем туманный минимально жизнеспособный продукт.
Пункты релиза
Ладно, пора закругляться. Никогда не думал, что это затянется так долго, спасибо, что задержались! Основные выводы:
- Избегайте доставки методом «большого взрыва» при разработке сложных инновационных продуктов. Делайте это итеративно и поэтапно. Вы это уже знали. Но действительно ли вы это делаете?
- Начните с идентификации вашего скейтборда — самого раннего тестируемого продукта. Стремитесь к облакам, но проглотите свою гордость и начните с доставки скейтборда.
- Избегайте термина MVP. Будьте более точны в том, о чем вы на самом деле говорите. Самое раннее тестируемое/пригодное/привлекательное — это только один пример, используйте любые термины, которые наименее запутывают ваших заинтересованных лиц.
И помните — рисунок скейтборда/автомобиля — это всего лишь метафора. Не воспринимайте это слишком буквально.
Перевод статьи от Henrik Kniberg