Сезон 2026/27Проектирование веб-приложений
Уровень 1 из 21Ур. 1/21
до события6 дн 15 ч


MUP

Босс 5 · Maximum Usable Product, финальная защита

MUP

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

Защищается очно всей командой; XP (баллы) за этап считаются от одной оценки 0–10 с учётом коэффициента попытки.

Награда
16 XP (баллов)
Формат
Очная защита: 5 минут рассказ + 5 минут демонстрация + 5 минут на вопросы
Старт
уровень 16, 23 января
Босс-файт
уровень 21, 13 марта, с 13:00
Загрузка до
13 марта, 11:00

Чекпоинты

  • ЧекпоинтКТ1 — уровень 18, 6 февраля
  • ЧекпоинтКТ2 — уровень 20, 27 февраля

Чекпоинт (контрольная точка) — промежуточная сверка до защиты: дату задаёт преподаватель, состав артефактов команда выбирает сама. Оценка на чекпоинте не ставится — там собирают замечания.

Как оценивается

Одна оценка от 0 до 10. Учитывается: презентация, функциональность, запуск и работа, документация, обратная связь (с 5).

XP = оценка / 10 × 16 XP × коэффициент попытки

Что стоит за каждой оценкой — в разделе «Шкала 0–10» ниже.

Пересдачи

  • 1.0 — защита в срок, 13 марта
  • 0.6 — дату объявляет преподаватель

К защите допускаются команды, загрузившие материалы до дедлайна. Выступает вся команда: отсутствующий получает 0. У финального босса пересдача одна, с коэффициентом 0.6, и на неё есть неделя — позже работа не принимается.

Что за босс

Финальный босс-файт (заключительная защита проектного этапа). MUP — максимально пригодный к использованию продукт: он не просто запускается, а внедрён и используется. Альтернативный итог этапа — опубликованная статья по результатам исследования.

Что загружаем

  • Презентация (PDF): описание и цели проекта, User Story Map, основные use cases, User Journey Map, демонстрация работы MUP на скриншотах, шаги, которые привели к этой стадии.
  • Ссылка на открытый git-репозиторий: исходный код и инструкция по запуску.
  • Демонстрация стабильной работы продукта в заявленном объёме.

Правила боя

  • К защите допускаются только команды, загрузившие материалы до дедлайна.
  • Выступает вся команда. Отсутствующие получают 0.
  • У финального босса пересдача одна: на досдачу есть одна неделя, коэффициент — 0.6. Второй пересдачи (0.4), в отличие от остальных боссов, здесь нет — позже работа не принимается.

Шкала 0–10

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

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

1 — продукт в зачаточном состоянии: код или макеты есть, но базовые функции не работают или продукт остался на уровне раннего MVP. Презентация не раскрывает цели и сценарии, в архитектуре серьёзные пробелы, запуск требует разработчика, документации нет или она недостаточна, обратная связь не собиралась либо собрана формально (один-два отзыва без анализа).

2 — частичная реализация: продукт работает с критическими ограничениями (только в среде разработки, дистрибутива нет). Презентация поверхностная, без связи с целями и User Story Map; архитектура неполна (нет C4 уровней 1 и 2 или развёртывания); запуск возможен, но с неочевидными шагами; README неполный, линтеры и CI не настроены; документация минимальна; обратная связь собрана, но на продукт не повлияла.

3 — минимальный уровень: заявленные функции выполняются, но с заметными недостатками — не все функции MUP реализованы. В презентации есть описание и цели, но нет полноценной демонстрации; в диаграммах недочёты (неполнота, ошибки нотации); запуск без разработчика возможен, но инструкции неполны; структура репозитория не продумана, CI нестабилен; в документации пропущены шаги; анализ обратной связи поверхностный.

4 — граница удовлетворительного: всё есть, но каждый аспект с ограничениями. Презентация показывает продукт, но не обосновывает переход от MVP к MUP; C4 уровней 1 и 2 представлены с мелкими ошибками, развёртывание упрощённое; продукт запускается, но возможны нестабильности; README позволяет запустить продукт, структура репозитория описана кратко; линтеры настроены, CI нестабилен; в документации нет удобной навигации; обратная связь собрана и выводы сделаны, но изменения в продукт не внесены.

5 — удовлетворительный MUP: продукт выполняет заявленные функции этапа, презентация отражает цели, сценарии и демонстрацию работы; C4 уровней 1 и 2 и диаграмма развёртывания на месте; запуск без разработчика по README; линтеры и CI настроены и проходят; документации хватает для запуска и использования. Обязательно: обратная связь собрана, проведён базовый анализ, выделены основные проблемы.

6 — хороший MUP: функционал соответствует планам на MUP, все функции MVP доведены до уровня MUP. Презентация связно показывает путь от MVP к MUP и то, как продукт решает проблему; архитектура соответствует проекту; обоснованы выбор стека, типа БД и архитектурных подходов; интерфейс отвечает базовым принципам UX (понятная навигация, консистентность, обратная связь при действиях); продукт стабильно работает; репозиторий, README, линтеры и CI на месте; есть документация пользователя с пошаговыми инструкциями и документация разработчика с описанием компонентов. Обязательно: обратная связь от нескольких групп, включая целевую аудиторию, с анализом проблем и направлений доработки.

7 — всё на уровне 6, плюс: реализованы все запланированные сценарии и функции MUP; развёрнутое обоснование технических решений (стек, тип БД, паттерны проектирования — GRASP и другие); диаграммы C4 и развёртывания полные, нотация соблюдена; интерфейс адаптивен (или обоснованно не адаптивен), UX продуман для целевой аудитории; продукт запускается через Docker (docker-compose) или имеет готовый дистрибутив; код по стандартам, технический долг минимален, CI стабильно зелёный; документация пользователя охватывает все типы пользователей, документация разработчика — API и структуру кода; продукт развёрнут у заказчика или в целевом окружении. Обязательно: по итогам обратной связи внесены конкретные изменения в продукт.

8 — сильный MUP: функционал полностью соответствует планам, продукт готов к полноценному внедрению; презентация и демонстрация на высоком уровне; диаграммы готовы к использованию в разработке; представлен анализ, насколько продукт решает проблему пользователей и чем он лучше существующих решений; установка проведена пользователем без сбоев; интерфейс адаптивен, UX соответствует принципам курса; проработаны нефункциональные требования (аутентификация, авторизация, валидация, обработка ошибок, устойчивость к некорректным действиям); README с типовыми сценариями и возможными ошибками; код покрыт unit-тестами; документация полная. Обязательно: обратная связь от целевой аудитории с визуализацией (графики, диаграммы) и описанными изменениями.

9 — всё на уровне 8, и обязательно функционал сверх планов на MUP: продукт делает больше, чем планировалось. Запуск полностью автономен и максимально прост (Docker или дистрибутив); показано глубокое понимание архитектурных паттернов (GRASP, Saga, Outbox/Inbox) и их применения; анализ решения проблемы подтверждён данными и метриками; проработаны безопасность, производительность и информативные сообщения об ошибках; настроены мониторинг и логирование (метрики, отслеживание ошибок, health checks) или описан детальный план их внедрения; код без технического долга, покрыт unit- и интеграционными тестами; документация в удобном формате с API, развёртыванием, отладкой и поддержкой. Обязательно: обратная связь от широкой аудитории структурированными методами (анкеты, NPS, CSAT, интервью), детальный анализ с визуализацией и конкретные улучшения.

10 — всё на уровне 9, и обязательно функционал существенно сверх планов: версия для другого типа устройства или значительное расширение продукта. Продукт внедрён и активно используется целевой аудиторией; обоснование технических решений учитывает масштабируемость; преимущества перед аналогами подтверждены данными и конкретными сравнениями; нефункциональные требования проработаны полностью; мониторинг и логирование настроены вплоть до алертинга; код оптимизирован для поддержки и развития; документация пользователя и разработчика исчерпывающая. Обязательно: обратная связь от широкой аудитории комплексными методами (анкеты, NPS, CSAT, интервью, анализ поведения — метрики, тепловые карты, A/B-тестирование), глубокий анализ с визуализацией и описанные изменения продукта по её итогам.