От идеи к MVP: как остановить разрастание прототипа

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

Материал дополнен по итогам рабочей встречи 24 июля 2026 года с Татьяной Овчинниковой. Разговор позволил зафиксировать не только новый проект, но и универсальную последовательность, по которой в школе запускается любой ArchiToy.

Как запускается проект в DØMO ARCHITOYS

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

На старте не обязательно знать программирование или точные названия технологий. Необходимо ответить на пять предметных вопросов:

1. Для кого создаётся инструмент?
2. Какую задачу выполняет пользователь?
3. Что он вводит, загружает или выбирает?
4. Какое правило преобразует исходные данные?
5. Какой результат можно увидеть, сохранить или продолжить развивать?

После этого работа строится в восемь этапов:

1. сформулировать идею одним предложением;
2. определить пользователя и один основной сценарий;
3. описать связь «вход → действие → правило → результат»;
4. собрать нулевую браузерную версию;
5. опубликовать её и открыть по обычной ссылке;
6. самостоятельно пройти весь сценарий;
7. уточнять функции, параметры и интерфейс короткими итерациями;
8. зафиксировать авторство в разделе «О проекте».

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

В разделе «О проекте» указываются название, автор или разработчик, куратор, летняя школа DØMO LAB, программа ArchiToys и год создания. Эта информация входит в продукт с первой версии, а не добавляется после завершения работы.

Что мы называем MVP

В рамках DØMO ARCHITOYS MVP — это самая короткая версия проекта, которая позволяет проверить его главную ценность на другом человеке.

Она должна отвечать на пять вопросов:

1. Кто пользуется инструментом?
2. Какую одну проблему он решает?
3. Какие исходные данные получает?
4. Какое главное преобразование выполняет?
5. Какой проверяемый результат выдаёт?

Рабочая формула:

один пользователь → одна задача → одно главное действие → одно правило → один результат.

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

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

Демонстрация, прототип и MVP

В школе полезно различать три рабочих состояния.

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

Прототип позволяет проверить устройство интерфейса и последовательность действий. Часть функций при этом может оставаться условной.

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

Это рабочее разделение принято для занятия, а не претендует на универсальную классификацию цифровых продуктов.

Шаг 1. Сформулировать главную гипотезу

Гипотеза должна связывать пользователя, действие и ценность. Она не формулируется как перечень возможностей.

Слабая формулировка:

Сервис с искусственным интеллектом, картой, трёхмерной моделью, рекомендациями и экспортом.

Проверяемая формулировка:

Если студент перед просмотром получит формальный чек-лист комплектности планшета, он сможет самостоятельно обнаружить пропущенные материалы.

Или:

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

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

Шаг 2. Провести границу первой версии

Все функции предлагается разделить на три группы.

Статус	Вопрос	Действие
Ядро MVP	Без этой функции можно проверить главную гипотезу?	Если нельзя — оставить
Следующая версия	Улучшает ли это продукт, не определяя его основную ценность?	Вынести в план
Отдельное исследование	Требует ли функция нового сервиса, данных или технической проверки?	Пока исключить

Ограничение должно быть конкретным. Вместо «работаем только с простыми изображениями» лучше записать точный допустимый формат и размер файла. Вместо «небольшое число параметров» — перечислить выбранные параметры.

Шаг 3. Собрать вертикальный сценарий

Минимальная версия должна проходить через все слои инструмента:

1. понятная стартовая точка;
2. ввод или выбор исходных данных;
3. проверка допустимости входа;
4. одно основное действие;
5. выполнение авторского правила;
6. видимый результат;
7. сохранение изображения, параметров или записи;
8. понятное сообщение об ошибке.

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

Шаг 4. Сделать правила видимыми

Архитектурный инструмент не должен превращать исходные данные в результат необъяснимым способом. Пользователю важно видеть:

• какие данные были считаны;
• какие параметры получены;
• что именно изменилось;
• какие ограничения применились;
• что является вычисленным результатом, а что — авторской интерпретацией.

Особенно важно это для проектов, работающих с изображениями, рекомендациями и автоматически найденными сведениями.

Шаг 5. Назначить критерии готовности

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

Пример критерия:

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

Минимальный общий набор критериев:

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

Шесть проектных MVP-срезов

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

01. «Чертёж → трёхмерное пространство»

Проверяемая гипотеза: ограниченный графический язык позволяет быстро получить понятный цифровой объём из плоского рисунка.

В MVP входит:

• один поддерживаемый формат входных данных;
• опубликованный образец графических правил;
• простой замкнутый контур или подготовленный векторный рисунок;
• преобразование контура в простой объём;
• вращение и масштабирование сцены;
• сохранение изображения и параметров;
• сообщение о неподдерживаемом входе.

Пока не входит:

• понимание любого свободного эскиза;
• сложное распознавание архитектурных обозначений;
• дополненная реальность;
• автоматическое построение полноценной CAD- или BIM-модели;
• профессиональный экспорт, пока он не проверен в целевой программе.

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

02. Варвара — «Фотография → форма + палитра»

Проверяемая гипотеза: фотография может стать управляемым источником архитектурной палитры и формообразующего правила.

В MVP входит:

• загрузка одной фотографии;
• извлечение ограниченной палитры;
• одна заранее выбранная типология или базовая форма;
• два-три объяснённых свойства изображения;
• видимая таблица соответствий «свойство фотографии → параметр формы»;
• сравнение исходного изображения, палитры и результата;
• сохранение итоговой композиции.

Пока не входит:

• множество типов зданий;
• автоматическая оценка художественного качества фотографии;
• неограниченная генерация случайных вариантов;
• обещание готового архитектурного проекта;
• профессиональная модель для строительства.

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

03. Дмитрий — онлайн-конфигуратор здания

Проверяемая гипотеза: несколько взаимосвязанных параметров помогают быстро сравнить варианты одного типа здания.

В MVP входит:

• одна выбранная типология;
• четыре–шесть основных параметров;
• допустимые диапазоны и ограничения;
• одновременное обновление плана и трёхмерной модели;
• вращение и приближение;
• сброс к исходному варианту;
• сохранение изображения и конфигурации.

Пока не входит:

• универсальный каталог разных зданий;
• полный нормативный расчёт;
• автоматическая оптимизация;
• детальная конструктивная модель;
• BIM-экспорт без отдельной проверки.

Критерий теста: каждый параметр предсказуемо изменяет и план, и объём; недопустимые сочетания блокируются или объясняются; сохранённая конфигурация восстанавливается.

04. Андрей — персональный городской музей

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

В MVP входит:

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

Пока не входит:

• гарантированное автоматическое распознавание здания;
• большая энциклопедическая база;
• социальная сеть;
• автоматически составленные экскурсии;
• публикация непроверенных сведений как фактов.

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

05. Роза — Archi Helper

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

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

В MVP входит:

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

Пока не входит:

• универсальная оценка архитектурного качества;
• окончательный балл;
• подмена преподавательского просмотра;
• сравнение с большим корпусом работ без подтверждённой методики;
• автоматическая трёхмерная модель и профессиональный экспорт как обязательные функции MVP.

Критерий теста: при отсутствии обязательного материала система отмечает его в чек-листе; после разметки результат воспроизводим; формальные замечания визуально отделены от интерпретации проекта.

06. Татьяна Овчинникова — «ОПК Lab»

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

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

Проверяемая гипотеза: ограниченный набор тел и композиционных принципов помогает студенту быстро получить, рассмотреть и самостоятельно доработать основу будущей объёмно-пространственной композиции.

В MVP входит:

• трёхмерное рабочее поле с вращением и приближением;
• куб, параллелепипед, цилиндр и пирамида;
• добавление и удаление элементов;
• перемещение, вращение, масштабирование и дублирование;
• три принципа: метр, ритм и динамика;
• автоматическое создание начального варианта;
• ручная корректировка композиции;
• изменение цвета отдельных объёмов;
• фигура человека для понимания масштаба;
• сохранение изображения PNG;
• раздел «О проекте» с авторством.

Пока не входит:

• вычитание одного объёма из другого и построение сложных пустот;
• универсальная программа для всех пяти курсов;
• автоматическое превращение композиции в жилой комплекс или общественное здание;
• генерация по музыке, звуку или изображению;
• оценка архитектурного качества;
• профессиональный CAD- или BIM-экспорт.

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

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

Практическое задание пятого дня

Каждый участник должен подготовить:

1. одно предложение с главной гипотезой;
2. имя основного пользователя;
3. схему «вход → действие → правило → результат»;
4. список функций ядра MVP;
5. отдельный список отложенных возможностей;
6. публичную рабочую ссылку;
7. один подготовленный тестовый пример;
8. форму для фиксации замечаний;
9. короткое описание известных ограничений.

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

Взаимное тестирование

Автор передаёт ссылку другому участнику и не объясняет порядок действий до завершения первой попытки.

Наблюдатель фиксирует:

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

После теста автор задаёт три вопроса:

1. Какую задачу, по вашему мнению, решает этот инструмент?
2. В какой момент возникла неопределённость?
3. Какой один результат оказался полезным?

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

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

Что не считается завершённым MVP

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

Паспорт MVP

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

1. Пользователь: кто проходит основной сценарий.
2. Проблема: что именно мешает ему сейчас.
3. Гипотеза: какое изменение должно помочь.
4. Вход: какие данные принимает инструмент.
5. Главное действие: что делает пользователь.
6. Правило: как система преобразует вход.
7. Результат: что появляется на выходе.
8. Критерий успеха: какое наблюдение подтвердит работоспособность.
9. Не сейчас: какие функции сознательно исключены.

Результат дня

К завершению практикума у каждого проекта должна появиться не максимально богатая, а максимально ясная версия.

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

Главный переход пятого дня:

не от малого количества функций к большому, а от широкой идеи — к первой доказуемой ценности.

Методическая рамка и источники

• Яндекс Практикум — «MVP: что такое минимально жизнеспособный продукт»: назначение MVP, проверка гипотез и получение обратной связи.
• Яндекс Практикум — «UX-исследования: когда нужны, их виды и методы»: роль пользовательских исследований при разработке MVP и проверке понятности интерфейса.
• ProductStar — «Что такое MVP?»: различие между идеей, прототипом и рабочей версией, которую можно передать пользователю для первой проверки.