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


Представление

Босс 1 · Представление проекта

Представление

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

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

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

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

Одна оценка от 0 до 10. Учитывается: продукт, польза, пользователь, технология, планирование.

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

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

Пересдачи

  • 1.0 — защита в срок, 19 сентября
  • 0.6 — на ближайшем занятии после защиты: уровень 4, 26 сентября (дату подтверждает преподаватель)
  • 0.4 — на ближайшем занятии после защиты: уровень 5, 3 октября (дату подтверждает преподаватель)

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

Что за босс

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

Главный вопрос босса — «Зачем нужен ваш продукт и как он будет работать?». Если после защиты на него не может ответить человек из зала, босс не побеждён.

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

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

  • Презентация в PPTX или PDF, 9–12 слайдов.
  • Внутри — схемы, диаграммы, наброски интерфейсов, а не только текст.
  • Загрузка в SmartLMS до дедлайна включительно; запись на защиту — в ведомости.

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

Минимум по пяти аспектам:

  • Продукт — цель разработки и хотя бы один сценарий использования готового продукта.
  • Польза — названа проблема и то, как её решают сейчас без вас.
  • Пользователь — портрет основного пользователя внутри МИЭМ и ВШЭ.
  • Технология — назван стек и инструменты, показано понимание, как они применяются в проекте.
  • Планирование — план с этапами «Прототип» и «MVP».

Правила боя

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

Шкала 0–10

Смотрим сразу на все пять аспектов вместе.

0 — презентации нет или она не про проект: непонятно, что и зачем делает команда.

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

2 — продукт назван, но непонятно, как он будет работать. Раскрыты один-два аспекта из пяти, презентация не тянет на формальные требования (объём, схемы).

3 — ясно, какие проблемы решает продукт, но аналоги не разобраны; пользователь — только внутри вуза; технологии базовые, без понимания их роли; план без конкретных этапов. Рассказ = чтение слайдов.

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

5 — всё из «Что загружаем» выполнено: 9–12 слайдов со схемами и полной структурой, цель чёткая и показан сценарий использования, названы проблема и то, как её решают сейчас, есть портрет пользователя в вузе, стек с пониманием применения, план с этапами «Прототип» и «MVP». Выступает вся команда, рассказ связный.

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

7 — всё на уровне 6, плюс окружение продукта и все его характеристики, назван способ оценки успешности (метрики), план доведён до этапа «MUP», команда уверенно отвечает на вопросы без опоры на текст слайдов.

8 — описаны окружение и ограничения продукта, включая non-goals: что продукт сознательно не делает и почему. Полный обзор аналогов с метриками и способом оценки успешности; аудитория за пределами вуза с оценкой размера; выбор технологий детально обоснован; чёткий план «Прототип → MVP → MUP»; выступление и оформление на высоком уровне.

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

10 — всё на уровне 9, и обязательно: количественная оценка опирается на источники данных или собственные замеры (опрос, интервью с потенциальными пользователями) с результатами в презентации. Выбор технологий сравнивается с альтернативами, план согласован с контрольными точками курса, а рассказ тянет на публичный питч.

Типовые грабли

  • Слайды читают вслух вместо рассказа. Готовьте выступление отдельно от слайдов и репетируйте заранее.
  • «Аналогов нет» — почти всегда означает, что аналоги не искали. Люди уже как-то решают эту проблему; расскажите как.
  • Целевая аудитория «все студенты» непроверяема. Назовите конкретного пользователя и оцените, сколько их.
  • Стек, выбранный «потому что мы его знаем», — это ответ, но его нужно проговорить честно и показать, что он выдержит задачу.