Минимально жизнеспособный продукт: инструкция28.09.2016 12:03

28.09.2016 | Автор: Крис Бэнк  

Над переводом работали: Nancy Pong и Ринат Шайхутдинов. При поддержке iSpring.

Глава 1: Небольшое послание от автора

Мы часто неправильно понимаем и, как следствие, неправильно используем минимально жизнеспособные продукты. Ресурсы большинства бизнесов ограничены, поэтому существует распространенная ошибка: концентрироваться на той «минимальной» части проекта, которая позволит по-быстрому выпустить что-то готовое.

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

В этой книге вам предложен широкий выбор мнений экспертов, теорий, практик, случаев из жизни, касающихся взлетов и падений минимально жизнеспособных продуктов. Говоря конкретнее, мы включили в книгу советы таких предпринимателей, как Стив Бланк, Эрик Рис, Гай Кавасаки, Эш Маурья, Синди Альварес, Рэнд Фишкин, Дэвид Эйкен, Джоэл Гаскон, Джош Пукетт, Брендон Шоэр, Крис Бейдер, Нил Патель, Ник Свинмерн и многие другие. Мы будем обсуждать базовые концепции: например, различные типы MVP и способны тестирования гипотез MVP.

Более опытным читателям мы предлагаем узнать, как применить MVP-мышление в рамках Lean (бережливой разработки) и Agile (гибкой разработки), как сбалансировать UX и Lean разработку и даже рассмотрим внутренний процесс проектирования в Spotify. Мы надеемся, что поможем вам лучше понять, как при разработке вашего следующего MVP добиться идеального баланса между минимальным количеством ресурсов, жизнеспособностью бизнеса и качеством продукта.

Если подумать, тестирование MVP — это, пожалуй, самый важный шаг на пути к успеху компании. Мы рассмотрим, как супер-успешные компании вроде Twitter, Zynga, Foursquare, Dropbox, Zappos, Groupon, Oculus VR, Airbnb, Buffer, Pebble и другие правильно построили минимально жизнеспособный продукт, что помогло им переработать бизнес-идею и создать шумиху вокруг своих продуктов. Мы также включили сюда и свою собственную историю и рассказали, как UXPin может помочь вам в создании прототипа своего собственного MVP.

Хотелось бы услышать ваше мнение о написанном. И пусть другие тоже присоединяются к обсуждению — делитесь этой электронной книгой с друзьями.

С любовью к минимально жизнеспособным продуктам,
Крис Бэнк (соавторы: Джерри Као и Валид Зубери).

Глава 2. MVP: Определения экспертов

Сегодня «бережливые стартаперы» (lean startups) и другие мастера технологий все чаще используют минимально жизнеспособный продукт как стартовую площадку для запуска успешного программного продукта.

Концентрируясь на базовой функциональности и наборе ключевых возможностей, необходимых для разработки продукта, фирмы способны сформировать некое ядро, которое ляжет в основу продукта в дальнейшем. И если фирма не способна правильно сформировать ядро, то она рискует в итоге создать отстойный продукт — предложение, предполагающее «дер*мовый пользовательский опыт».

Источник: Lean Heroes

Что такое минимально жизнеспособный продукт (MVP)?

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

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

В Википедии MVP определяется так: «Минимально жизнеспособный продукт (MVP) — это стратегия, используемая для быстрого и количественного исследования рынка для конкретного продукта или функции продукта. Термин был придуман Фрэнком Робинсоном и популяризирован в области веб-приложений Эриком Рисом.» Это определение достаточно узкое: согласно мнениям многих экспертов оно слишком сфокусировано на продукте и количественных характеристиках. Однако, некоторые из названных целей MVP (они приведены ниже) дают почву для более существенного обсуждения:

• иметь возможность протестировать продукт-гипотезу, используя минимальные ресурсы

• ускорить обучение

• сократить время работы инженеров, потраченное впустую

• как можно скорее предоставить продукт ранним покупателям

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

Источники: Eric, Ash, Nick, Steve, Rand, Cindy and Marcin

Эрик Рис, сооснователь и технический директор IMVU, а также ярый сторонник концепции минимально жизнеспособного продукта, определяет MVP как версию нового продукта, которая дает возможность максимально изучить пользователя с минимальными усилиями. То есть MVP позволяет протестировать реальные сценарии использования продукта потребителем. Таким образом, мы избегаем расходов на дорогостоящее исследование рынка и последующую разработку продукта. Вместо этого мы запускаем по-быстрому разработанный продукт с минимальным набором функций и тестируем свои предположения о том, что нужно пользователю.

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

Источник: Build Measure Learn

Эш Маурья, директор P2P-файлообменника Cloudfire и автор курса «Применение lean-подхода (бережливое производство) — помощь предпринимателям в достижении успеха» подробно излагает свои выводы в статье «Как я создал свой MVP». Выделив целевую группу пользователей, он перешел к определению трех основных проблем, которые у них возникают при использовании решений, представленных на рынке. После этого он смог разработать продукт, в некоторой степени решающий эти проблемы, и привлечь «ранних последователей» через лэндинг продукта.

К счастью для Маурьи, процесс упрощался тем, что основная функциональность была взята из предыдущего продукта. Это позволило ему существенно сэкономить время и усилия, которые ушли у него на проверку своих предположений относительно базы потенциальных пользователей продукта. Основываясь на собственном опыте, Эш подчеркивает, что MVP обязательно должен представлять ценность для потребителя. Очень важно правильно сформировать продукт, чтобы удостовериться, что у вас есть проблема, которую стоит решать. При помощи приведенного ниже каркаса «lean canvas», Маурья выделяет 4 важных шага по преобразованию существующего продукта в MVP.

• во-первых, убедитесь, что существует проблема достойная решения

• определите, с самым элементарным решением этой проблемы (MVP)

• создайте и утвердите MVP в небольшом масштабе (демонстрация MVP)

• проверьте MVP в крупном масштабе

Чтобы получить представление о возможных рыночных и потребительских рисках вашего MVP, прочитайте пост «Запуск продукта через умножение на 10».

Источник: The 10x Product Launch

У Марсин Тредер, директора и со-основателя UXPin, был очень похожий опыт. В начале основным его продуктом был бумажный блокнот для прототипирования, в то время как нынешний продукт — интернет-приложение для создания прототипов и wireframe-ов. «Естественно бумажные продукты было гораздо дешевле создавать на начальном этапе», — говорит Марсин, — «Мы и вправду не представляли, что следующая версия продукта будет электронной. Мы были просто группкой дизайнеров, пытающихся помочь коллегам стать лучше».

«MVP означает создание максимальной ценности при минимальных затратах на разработку».

Но Марсин быстро осознал, насколько разрозненными были представленные на рынке инструменты и сколько людей были ими недовольны. Согласно мнению Тредера, «MVP — это не самый быстрый и не самый безупречный продукт. Скорее это продукт, обладающий максимальной ценностью при минимальных затратах на разработку.» Он признает, что его первый продукт не представлял максимальной ценности в сравнении со всеми существующими ныне альтернативами. Но UXPin на сегодняшний день является одним из ведущих приложений для прототипирования и wireframe-ов на рынке. Так что он явно шагнул вперед.

Источник: Practical Product Management for New Product Managers

Чтобы извлечь максимум ценности из процесса разработки, можно воспользоваться представленной выше матрицей для расстановки приоритетов. Конечно же, не все lean-стартапы располагают такой роскошью: иметь готовый продукт, из которого можно слепить MVP. Однако во множестве случаев это и не нужно.

Ник Свинмерн, со-основатель Zappos, убедился в этом на собственном опыте. Вот очень известный пример гибкости и бережливости MVP: ныне гигант электронной торговли (e-commerce), Свинмерн начинал с того, что фотографировал обувь в местном магазинчике. Затем он размещал фотографии онлайн, и всякий раз, когда кто-то делал заказ онлайн, он шел в магазин и покупал нужную пару. В этом смысле основной задачей MVP было максимально снизить неопределенность бизнес-идеи. У Свинмерна не было продукта, и на начальном этапе он действовал как один из своих клиентов.

Источник: The 10x Product Launch

И, кстати, это очень распространенный подход (особенно в мире стартапов) — продавать так называемый «призрачный софт» (продукт, который даже не существует или находится на начальном этапе разработки).

Синди Альварес, UX-дизайнер в Yammer и бывший product-менеджер в Kissmetrics, добавляет, что это распространенная ошибка — считать, что MVP должен быть продуктом. Согласно Синди, цель MVP — максимизировать обучение и минимизировать объем инвестиций и уровень риска. И продукт не должен быть единственным средством достижения цели. Рассматривая MVP в таком узком смысле, многие люди начинают думать о «финальном» продукте и урезать функциональность вместо того, чтобы сделать нечто экспериментальное. Чтобы не попасть в эту ловушку, Синди использует практический прием под названием Модель Кекса, который позволяет думать о чем-то одном — цельном и законченном.

Источник: 7 Ways to Test MVPs

Также она предлагает несколько практических советов по разработке MVP в рамках команды. Она заявляет, что существует две основные проблемы, которые необходимо сразу решить внутри команды:

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

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

Стив Бланк, предприниматель со стажем и автор докладов и статей на тему MVP, утверждает, что методика развития клиентов (customer development) и методика бережливого стартапа (lean startup) недооценивают важность продажи вашего видения тем, кто его разделяет (а не всем подряд), при этом предоставляя минимальный набор функций.

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

Источник: Silicon Africa, 5 Characteristics of Earlyvangelists

Рэнд Фишкин, со-основатель Moz, выглядит главным шоуменом во всей этой компании. С его точки зрения, первое впечатление значит очень много. Именно поэтому он призывает остальных выводить MVP на новый уровень, превращая его в EVP (an Exceptional, Viable Product — исключительный, жизнеспособный продукт). По словам Рэнда, он много раз видел, как запускается MVP, едва ли представляющий какую-то выдающуюся ценность. И это проблема, ведь нельзя запускать и перезапускать MVP по несколько раз.

На практике, Рэнд предлагает выращивать MVP внутри фирмы и «прикармливать» его опытом взаимодействия с несколькими клиентами. Постепенно, когда первые отзывы будут собраны и учтены в продукте, наступит момент истины, который должны почувствовать первые пользователи (внутренние и внешние).

Тогда то и стоит выпустить на волю сформировавшийся EVP. Этот процесс может занять дополнительные 30–90 дней, но, по мнению Рэнда, это того стоит.

Источник: Moz,»7 unlikely recommendations for startups & entrepreneurs»

MVP — это важное средство достижения цели.

Существует множество подходов к созданию MVP. И, хотя в подходе каждого эксперта к MVP есть своя изюминка, все же они все следуют нескольким золотым правилам, чтобы не погрязнуть в мелочах. Суть этих правил в одном: MVP — это средство достижения конечного продукта или улучшения этого продукта, а не сам продукт. Убедитесь, что не упускаете это из виду.

Глава 3. Буква M в MVP: Взгляд экспертов на минимализм в продукте

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

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

Источник: Stop Overthinking… Just Stop

Так как же создать урезанную версию продукта, которая будет доступной и привлекательной?

Начните с понимания разницы между двумя следующими вопросами:

Вопрос А: Как создать продукт, максимально простой с точки зрения технического исполнения?

Вопрос Б: Как создать продукт, который максимально прост, но при этом отвечает требованиям ранних последователей?

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

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

Используйте ваше нечестное преимущество как можно быстрее

Когда мы создавали MVP UXPin для американского рынка, мы опрашивали авторитетных пользователей, чтобы выяснить, каких функций им не хватало в существующих UX инструментах. Мы обсуждали идеи по стратегии развития продукта и даже зарисовывали wireframe-ы на салфетках. Мы просили их совета, чтобы лучше понять образ мысли ранних последователей и чтобы избежать выпуска «минимального продукта», который не отражал бы нашего видения.

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

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

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

• Направляю ли я ресурсы на упрощение MVP?

• Строю ли предположения на основании лишь ключевой ценности?

• Максимально ли моя временная шкала соответствует принципам lean?

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

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

Понять минимализм в абстрактном плане может быть сложно, поэтому давайте рассмотрим примеры из реальной жизни:

Источник: Sell It Before You Build It

Работая в Fliggo (сайт, который сейчас объединен с Vidly), Крис Бейдер (ныне со-основатель и chief product officer в Secret), хотел проверить предположение, что пользователям нужна возможность иметь свой собственный сайт с видео.

В то время не было возможности просто осуществить это, создав сайт на WordPress и вставив видео с YouTube. В итоге они, применив минимализм в нужной пропорции, создали MVP, который позволил Fliggo не просто проверить желание ранних последователей зарегистрироваться, но и их готовность платить.

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

Хотя это простой и дешевый способ, лэндинг не является универсальным инструментом любого MVP. Специалист по стартапам и основатель Extreme Lean TV, Рамли Джон не советует использовать такой унифицированный подход для любого MVP. Опасно полностью полагаться только на лендинг, потому что вы рискуете не получить никакой обратной связи от ранних последователей, зарегистрировавшихся на лэндинге (какие у них проблемы? за что они готовы платить? ), а недостаток регистраций может объясняться не самим продуктом, а плохими текстами или отвлекающим дизайном.

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

Так они проверяли свою бизнес-гипотезу и, в то же время, предоставляли ранним последователям достаточно приятный опыт взаимодействия. Упростив весь процесс до одного этого нечестного преимущества, в AngelList создали правильный MVP.

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

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

Source: The Wrong Stuff vs. Stuff With Errors

Так как же понять, что на разработку MVP потрачено слишком много времени? Рик Скрента, создатель поисковика Blekko, утверждает, что все зависит от продукта. Некоторым веб-приложениям (вроде Fliggo) достаточно лэндинга. Если ваше предложение подразумевает более высокий уровень ожиданий или требует большей огласки и внимания, разработка MVP может занять больше времени. Иначе из-за череcчур простого дизайна или некачественного исполнения продукта может произойти его отторжение. В качестве подтверждения этой мысли Рик приводит в пример свой поисковик, на создание MVP которого ушло 3 года.

В противоположность категории «как долго разрабатывать?» можно назвать более уместную категорию «что разрабатывать?». В общем-то, ответ на первый вопрос неизменно отвечает и на второй. На рисунке ниже, взятом с сайта Signal vs. Noise, Райан Сингер (product-менеджер из Basecamp) предполагает, что минимализм в сфере MVP достигается через баланс между базовым качеством исполнения и соответствующим количеством функций.

Источник: What Happens to User Experience in a Minimum Viable Product

Основатель KISSMetrics Нил Патель приводит несколько интересных примеров примечательно робких запусков MVP: разных по масштабу, но стабильных в плане исполнения:

• Dropbox: все началось с трехминутного видео с MVP, а в результате количество регистраций выросло с 5,000 до 75,000 человек за ночь. И это все при отсутствии реального продукта!

• Foursquare: все началось со сбора фидбэка от пользователей при помощи Google Docs;

• Virgin Air: всего 1 самолет и 1 маршрут в начале для проверки гипотезы. Самолеты и маршруты добавлялись по мере того, как совершенствовался бизнес.

• Groupon: в начале был блог WordPress с виджетом, который посылал PDF-купоны по email;

MVP Virgin был самым ресурсоемким, а вот MVP Foursquare — самым «легким». Однако каждый MVP сложен ровно настолько, насколько сложны предположения, которые он должен проверять.

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

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

Марсин Тредер, CEO и со-основатель UXPin, уверен, что лучший способ определить правильный масштаб MVP — это понять, чем MVP не является. «К сожалению, самое распространенное заблуждение состоит в том, что MVP — это минимальный продукт», — говорит Тредер. «На самом деле, MVP не является самым быстрым или самим идеальным продуктом. Это, скорее, продукт, представляющий максимальную ценность, на разработку которого потрачены минимальные усилия».

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

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

В UXPin нам важно убедиться, что нам удалось передать ключевую ценность продукта на всех этапах при помощи целостного, созданного общими усилиями дизайна. Философия нашего продукта в том, что мы используем MVP-подход для разработки каждой новой функции, чтобы наши спринт-циклы максимально соответствовали процессу бережливой разработки (lean).
 

Источник: Stop Overthinking… Just Stop

На картинке выше отражено «ДНК» машины: относительная эффективность перемещения из пункта А в пункт Б. В каждой итерации масштаб продукта увеличивается на несколько функций, но вот уникальная ценность (быстрая транспортировка) остается неизменной.

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

Гаган Бияни, со-основатель Udemy и Sprig, уверен, что первая версия MVP должна тестировать ваш ключевую ценность, в то время как в дальнейших итерациях должны проверяться новые гипотезы. «MVP не должен быть просто продуктом. Он должен быть направлен на минимально жизнеспособное тестирование гипотезы X»,? —? говорит Гаган. «Серия последовательных MVP, проверяющих различные предположения, позволит вам осуществлять запуск продукта быстрее и лучше».

«MVP не должен быть просто продуктом. Он должен быть направлен на минимально жизнеспособное тестирование гипотезы X»

К примеру, одним из ранних MVP Udemy был онлайн курс за 20$, снятый со-основателями компании. Он позволил протестировать гипотезу, что люди готовы платить за высококачественный видео-курс. А в Sprig был такой MVP: члены команды на одну ночь стали доставщиками еды, чтобы проверить гипотезу о том, что еду можно достовлять за менее чем 20 минут. Как и в случае со скейтбордом, первый MVP подтвердил предположение, лежащее в основе бизнеса, что позволило тестировать более сложные гипотезы в последующих итерациях.

Пусть все будет просто и экспериментально

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

Глава 4. Буква V в MVP: Взгляд экспертов на жизнеспособность продукта

Полный текст статьи читайте на CMS Magazine