Файл: Лекция Понятия, сущность и функции коммерческого отдела.docx

Методика направлена на то, чтобы помочь разработчикам выбирать полезные функции с точки зрения пользователей. Ее автор и практик Jeff Patton считает, что описание функций должно содержать действие, выполняемое человеком.

Мы перечислили 4 шага, которые пользователи совершают с помощью нашего продукта: формирование заказа, управление заказом, оплата еды, доставка заказа.

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

---

выбрать ресторан;

•

выбрать кухню;

•

выбрать, где он живет;

•

•

выбрать блюдо;

•

выбрать напиток;

•

прочесть описания выбранных позиций;

•

добавить заказ в корзину.

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


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

После того, как вы упорядочили функции в соответствии с их приоритетом, начертите вертикальную линию и разместите их в нужной последовательности. Самое важное и часто используемое поставьте в верх списка, остальное — разместите снизу


Шаг 7. Определите объем MVP

После того, как вы расставили функции по их приоритету, можно определить объем MVP. Первый горизонтальный ряд на карте называется ходячим скелетом (каркасом). Этот ходячий скелет — наименьшая полезная версия продукта, которой недостает «мяса», то есть функциональности. Сначала мы должны создать каркас.

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

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


Шаг 8. Выберите наиболее подходящий метод управления и разработки MVP

Определив объем работы, вы можете наконец-то приступать к разработке минимально жизнеспособного продукта. Давайте выясним, какие методы управления проектами применимы к построению MVP.

LEAN

Один из методов разработки программного обеспечения Agile, основанный на нескольких принципах: устранении ненужных расходов, быстрой доставке, усилении обучения и построении целостностности. Фактически Lean использует итеративную разработку по шаблону «создание-измерение-обучение». С Lean разработчики могут отложить большинство проектных решений, установить быстрый цикл обратной связи и убедиться, что они создают востребованный продукт.

---

SCRUM

Другой итеративный подход к разработке программного обеспечения. Он подразумевает эффективное распределение объема работ, которое помогает командам быстрее выполнять задачи. Вы можете управлять разработкой функций MVP в спринте (короткие циклы — примерно по две или четыре недели). Определите scrum-мастера, который будет отслеживать стабильность работы всех scrum-процессов. MVP реализуется сразу после первого спринта. Команда разработки может обновлять продукт во всех последующих спринтах, реагируя на отзывы пользователей. Несмотря на то, что Scrum более трудоемкий, чем Learn, он может быть менее напряженным для специалистов — подходит для постепенного и длительного развития.

Канбан

Фокусируется на модели незавершенного производства и, в отличие от Learn и Scrum, не имеет цикличной прогрессии. Вместо этого Канбан предлагает сосредоточиться на задачах по мере их появления. Это позволяет балансировать объем работы с возможностями команды. Специалисты добавляют задачи в конвейер, как только получают обратную связь от пользователей. Канбан может применяться после выпуска первой версии MVP и стать мощным методом, если обратная связь будет продолжать поступать.

Экстремальное программирование (XP)

Это набор таких практик разработки, как рефакторинг кода, небольшие релизы, упрощенный дизайн, стандарты кодирования, которые позволяют улучшить код и обновить его в кратчайшие сроки. Циклы разработки с XP не превышают одной недели, поэтому вы можете выполнять первую версию быстрее, а затем масштабировать ее. XP хорошо подходит для MVP, который в значительной степени опирается на качество кода.

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

Шаг 9. Используйте альфа- и бета-тестирование

Альфа — так называемое внутреннее тестирование, когда ограниченная группа людей (в основном друзья или члены семьи) оценивают продукт. Если продукт прошел этот тест, вы можете перейти к бета-тестированию — позволить реальным пользователям попробовать продукт в течение одной-двух недель. Проанализируйте обратную связь и определите, какие функции необходимо добавить или заменить, чтобы сделать продукт лучшим.

---

Если вы собрали достаточно отзывов, можете обновить продукт, затем снова протестировать его и получить обратную связь. Количество циклов «создания-тестирования-обучения» и их временные рамки зависят от продукта. После того, как вы завершили несколько циклов, можете вернуться к шагу 0, изменить направление или продолжить итеративное улучшение вашего продукта.

Примеры MVP в различных отраслях

MVP должен передавать суть идеи в ее простейшей форме, которая зависит от контекста. Соответственно, и минимально жизнеспособные продукты варьируются в зависимости от проекта: от одностраничного сайта до рабочего прототипа программного обеспечения.

Например, в 1999 году Ник Суинмурн задумал продавать обувь через интернет, поэтому ему потребовался полноценный сайт Shoesite.com. Он запустил бизнес без каких-либо запасов или инвентаря, покупая продукцию под каждый оформленный заказ. Это дало ему возможность с низким уровнем риска проверить свою идею, не затрачивая средства на пополнение складских запасов. Вскоре Shoesite.com превратился в компанию Zappos, которую Amazon приобрел в 2009 году.

Чуть больше усилий к реализации своей концепции приложили создатели Uber. Гаррет Кэмп и Трэвис Каланик были разочарованы высокими расценками в такси Сан-Франциско. В 2010 году они запустили UberCab, простое приложение для iPhone, которое позволяло пассажирам арендовать для поездки лимузин по цене лишь в 1,5 раза выше стоимости городского такси. Изначально проект охватывал ограниченную территорию и, очевидно, предназначался для ограниченной целевой аудитории. Однако бета-версия помогла создателям донести ценность идеи и получить год спустя первые крупные инвестиции.

Один из самых простых в реализации MVP представили в 2008 году Брайан Чески и Джо Геббиа. Они не могли платить за квартиру-лофт в Сан-Франциско и решили проверить, существует ли спрос на аренду комнат напрямую от хозяина. Предприниматели создали простой MVP, который был не чем иным, как одностраничным сайтом с фотографиями собственной квартиры. Так был основан ныне всемирно известный Airbnb.

MVP и PoC: в чем разница

MVP не следует путать с доказательством правильности концепции (PoC — proof of concept). Последнее можно интерпретировать по-разному в зависимости от отрасли.

Прежде всего, доказательство правильности концепции — не ранняя версия продукта. PoC в разработке программного обеспечения описывает процессы, направленные на выяснение того, жизнеспособна ли концепция программного обеспечения технически. Команда также может выбрать этот подход с целью определения необходимого объема работы и лучших технологий разработки, выявления возможных технических проблем и поиска их решений.

---

Drew Houston, основатель Dropbox, сделал объяснительное видео и рассказал в нем, как должен работать Dropbox. Около 75 000 человек подписались на него в первую же ночь. Подобный метод может быть реализован с помощью блога, в котором вы делитесь с аудиторией идеями о продукте, который планируете разработать. Хоть и некоторые относят доказательство правильности концепции к MVP, мы склонны классифицировать эту трактовку отдельно как PoC.

Термины MVP и PoC взаимосвязаны, но не взаимозаменяемы. Доказательство правильности концепции, реализуемое оптимальным образом, становится минимально жизнеспособным продуктом.

Финальный совет

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

---