Привет! Меня зовут Михаил. Я IT-евангелист с 15-летним опытом работы в IT-индустрии: начинал как разработчик на C#, а сейчас опытный руководитель проектов и продакт-менеджер. Я пишу книгу об управлении IT-проектами, но без обратной связи это делать довольно сложно. Поэтому я решил публиковать здесь некоторые главы из книги, над которой работаю, чтобы получать обратную связь и конструктивную критику. Спасибо, что меня читаете — ваше внимание и интерес дают мне силы продолжать.

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

Исторические корни

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

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

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

Психологические противоречия

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

Классические определения

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

Основные характеристики Прототипа:

1. Неполный функционал: Прототип может не содержать всех функций и не быть полностью работоспособным; его основная цель — демонстрация концепции.

2. Фокус на дизайне и интерфейсе: Прототип часто используется для визуализации внешнего вида продукта и проверки удобства его использования.

3. Тестирование концепции: Прототипы позволяют проверить идеи на практике, выявить проблемы и получить раннюю обратную связь.

4. Быстрое создание: Прототипы создаются быстро и с минимальными затратами, что позволяет оперативно проверять различные подходы и идеи.

5. Предварительная версия: Прототип представляет собой черновую версию продукта, которая может значительно отличаться от окончательной версии после итераций и доработок.

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

Основные характеристики MVP:

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

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

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

4. Сбор обратной связи: Основная цель MVP — получить отзывы от реальных пользователей, чтобы определить, в каком направлении развивать продукт дальше.

5. Минимальные затраты: MVP создается с минимальными затратами времени и ресурсов, чтобы снизить риски и избежать ненужных расходов.

Различие MVP и прототипа

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

Допустим, мы строим коттедж. Тогда дом со стенами и крышей, подведенной инфраструктурой, самой дешевой плитой, туалетом, душем и лежащим на полу матрасом — это MVP. Схема будущего коттеджа на сайте или просто дом со стенами — это прототип.

Проблемы прототипов и MVP

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

Первая проблема, которую я все чаще наблюдаю в проектах ИТ-разработки, заключается в определении границ MVP или прототипа по факту завершения работ. Концепции MVP и прототипа предполагают планирование и определение границ версии продукта заранее. Заранее должны быть составлены требования к функциональности, и все (!) эти требования должны быть реализованы. Однако на этапе планирования командой или руководством может быть запланирована определенная версия продукта, но в процессе разработки возникают проблемы (технологические, временные, ресурсные), функционал начинает обрезаться, сужается профиль целевой аудитории, уменьшается количество поддерживаемых версий операционных систем и так далее. Получившийся результат называют MVP и декларируют таковым в различных отчетах и презентациях. Как говорит один мой коллега из крупной компании, входящей в ТОП-10 компаний России, «У нас любая получившаяся хрень MVP зовется». Я призываю придерживаться первоначальной концепции и не использовать эти термины в качестве оправдания недовыполнения ранее запланированных работ. Отхождение от концепции влечет значительные риски в проведении количественного анализа потенциальных выгод от разрабатываемого продукта (например, для A/B-тестирования), потери основной ценности разрабатываемого решения и недопонимание между различными участниками проекта. Грамотность, опыт и мудрость руководителя в таких случаях должны позволить ему зафиксировать потери, связанные с недовыполнением ранее запланированных работ, и инициировать либо пересмотр плана работ (добавить временные или денежные ресурсы на проект), либо официальную остановку работ с последующим пересмотром полного состава задач, так как в процессе работы изменились видение и концепция самого продукта.

Вторую проблему я могу сформулировать как высокий уровень базовых требований к продукту. ИТ-отрасль развивается все активнее, появляются новые продукты и решения. Их качество постоянно растет. Если 10 лет назад можно было позволить себе выпустить MVP приложения для знакомств с простым интерфейсом, только веб-версией и фильтрами подбора по трем атрибутам, то сейчас запуск такого MVP будет просто бессмысленным. Конечный пользователь уже привык к высокому качеству аналогичных приложений, к эргономичным и насыщенным функционалом решениям. Любая попытка предложить такому пользователю «урезанную» версию продукта не вызовет у него интереса, снизит заинтересованность в разработке и негативно скажется на дальнейшем маркетинге — продукт заранее будет воспринят рынком как уступающий конкурентам. Разумеется, если вы создаете решение в ситуации «Голубого океана», то этих проблем удастся избежать. Но, будем честными, таких ИТ-проектов не так много в общей массе. Также не стоит забывать, что с развитием ИТ-отрасли растет количество нормативных и законодательных актов, обязательных к исполнению в полном объеме. Таким образом, при разработке публичного прототипа решения или MVP вы обязаны сразу реализовать полноценный функционал авторизации (если, конечно, авторизация предусмотрена), соблюдая требования ФЗ-152. Вы не имеете права реализовать эти требования частично. Таким образом, сложность, состав и наполнение MVP с каждым годом увеличиваются (что вполне естественно). По моим предположениям, в будущем это может привести к отказу от концепции MVP в пользу прототипов, запускаемых на базе лабораторий или в рамках ограниченных закрытых бета-тестов.

Заключение

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