От первого прототипа до детского продукта: что мы меняем после первых тестов

Первый работающий прототип часто создаёт опасную иллюзию:

**механизм заработал — значит, продукт почти готов.**

В детских инженерных проектах это далеко не всегда так.

В Р≡Лис мы видим, что после первого физического прототипа начинается отдельный этап продуктовой разработки: нужно проверить не только конструкцию, но и то, как человек будет её собирать.

А затем дать проект детям.

Что меняется после первого прототипа

Самая частая корректировка — последовательность сборки.

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

На практике сборка иногда показывает обратное.

Два узла удобнее поменять местами.

Деталь нужно установить раньше.

Другой элемент — наоборот, позже.

Иногда исправление занимает несколько минут.

Иногда оно заставляет пересмотреть часть конструкции.

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

Разработка — это серия циклов

Практически ни один проект у нас не проходит путь:

**нарисовали → изготовили → запустили.**

Реальный процесс ближе к другому:

**прототип → сборка → проблема → изменение → новый прототип → новая проверка.**

Количество таких итераций заранее предсказать сложно.

Иногда результат находится относительно быстро.

Иногда одна корректировка вызывает следующую.

Поэтому сроки разработки одного набора у нас могут различаться в разы.

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

При этом речь не о непрерывной ежедневной работе.

Если смотреть на фактические трудозатраты, простой проект может потребовать порядка 30–40 человеко-часов, а более сложный — приблизиться к 100 часам или превысить их.

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

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

Есть принципиальная проблема product testing.

Человек, который разработал проект, уже знает, как он должен работать.

Он знает:

какая деталь куда идёт;

почему она ориентирована именно так;

что должно произойти на следующем этапе.

Поэтому часть решений кажется ему очевидной.

Для ребёнка никакого этого контекста нет.

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

Здесь начинается другой тип проверки.

Дети проверяют не механизм, а пользовательский сценарий

Механизм к этому моменту может работать.

Но ребёнок способен обнаружить другие проблемы.

Он может иначе прочитать последовательность.

Не понять очевидное для разработчика действие.

Начать сборку не с того элемента.

Застрять там, где внутри команды никто не ожидал сложностей.

Именно такие ситуации дают материал для следующей итерации.

Мы корректируем последовательность, отдельные элементы и другие детали проекта.

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

Детский продукт нельзя оценивать только глазами взрослого

Отдельный вывод мы сделали из реакции на сами идеи.

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

За годы работы с детьми мы научились достаточно хорошо понимать их интересы ещё до запуска.

А вот обратная история происходила.

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

После запуска дети реагируют на неё значительно сильнее, чем ожидалось.

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

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

Когда прототип становится продуктом

Для нас технически работающий механизм — только один из критериев.

Финальный проект должен одновременно:

— работать так, как задумано;

— иметь логичную последовательность сборки;

— быть понятным ребёнку;

— проходить реальные тесты вне головы разработчика.

Поэтому прототипирование Р≡Лис — это не поиск одной идеальной версии с первой попытки.

Это управляемый цикл исправлений.

**Спроектировали → изготовили → собрали → протестировали → изменили → проверили снова.**

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

Р≡Лис создаёт домашние инженерные проекты для детей 8–12 лет. Каждый набор проходит тестирование на детях до выхода в домашнюю линейку; сам проект вырос из школы технического творчества в Краснодаре.

Подробнее о Р≡Лис: https://relis.app/