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


RAT-PoC

Босс 2 · Доказательство концепции

RAT-PoC

Второй босс. Команда показывает, что проект вообще осуществим: риски названы, самое рискованное допущение проверено сборкой.

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

Награда
8 XP (баллов)
Формат
Очная защита, 15 минут: презентацию загружаете заранее и не рассказываете, всё время — разговор и вопросы по ней
Старт
уровень 3, 19 сентября
Босс-файт
уровень 7, 17 октября, с 11:10
Загрузка до
16 октября, 23:59

Сдача этапа

Материалы команды

Загрузить до 16 октября, 23:59

Загрузка ссылок доступна вошедшим в аккаунт участникам команды.

Ссылку сохраняет любой участник команды; её видят все. Пустое поле убирает ссылку.

Что за босс

Второй босс-файт (защита проектного этапа). Здесь команда доказывает практическую осуществимость проекта: не «мы придумали», а «мы проверили самое опасное место». RAT — Riskiest Assumption Test, тест самого рискованного допущения: берём то, из-за чего проект может развалиться, и проверяем это первым — методом, технологией или минимальной сборкой.

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

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

Продукт и User Story Map

  • vision и mission продукта;
  • user stories по шаблону As a [user type], I want [functionality] so that [benefit], соответствующие продукту;
  • построенная User Story Map.

Риски

  • три–пять главных рисков в форме «если [условие], то [последствие]», сгруппированные: технические (производительность, надёжность, безопасность, масштабируемость), архитектурные и бизнес-риски;
  • матрица «вероятность × ущерб» и способ обращения с каждым риском: избегаем, снижаем, передаём или принимаем;
  • прикидка нагрузки главного сценария на пик: откуда взято каждое число и какой ресурс упрётся первым;
  • критический путь по своей C4: шаги главного сценария, ресурс и бюджет задержки на каждом шаге;
  • объяснённый выбор архитектуры: стиль и требование, которое его оправдывает, ADR на два–три ключевых решения.

Решение (RAT)

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

Сборка (proof of concept)

  • макеты приложения;
  • полные диаграммы C4 уровней 1 (Context) и 2 (Container) по нотации;
  • макеты и диаграммы наглядно показывают работу продукта по основному его назначению;
  • макеты не заменяют проверку допущения: красивый интерфейс без проверки самого рискованного места — это прототип, а не PoC.

Правила боя

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

Чекпоинты

  • ЧекпоинтКТ1 — уровень 5, 3 октября

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

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

Одна оценка от 0 до 10. Учитывается: продукт и USM, риски, решение (RAT), сборка.

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

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

Шкала 0–10

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

  1. 00 XP

    показанное не решает основных задач; риски не продуманы или риском названо то, что им не является; как справляться с ними — неизвестно, предположения ни на чём не основаны.

  2. 10.8 XP

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

  3. 21.6 XP

    vision и mission есть, но могут быть некорректными; user stories слабые или не по правилам. Риски только ближайших этапов и описаны неполно, решения — для части рисков. Макеты слабые, C4-диаграммы не по нотации или неверно отражают систему.

  4. 32.4 XP

    user stories по правилам, но User Story Map фрагментарна. Риски перечислены, но не сгруппированы, самое рискованное допущение названо, но не проверено, критический путь не определён, выбор архитектуры не объяснён. Макеты и C4 есть, но с существенными недочётами.

  5. 43.2 XP

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

  6. 54 XP

    всё из «Что загружаем» выполненоvision и mission чёткие, user stories по правилам, USM построена; главные риски записаны в форме «если — то», сгруппированы (технические, архитектурные, бизнес), стоят на матрице «вероятность × ущерб», и у каждого есть аргументированное решение на методе или технологии; самое рискованное допущение названо, критерий успеха записан до проверки, показано, как его проверяли и что получилось; нагрузка главного сценария прикинута на пик с источником каждого числа; выбор архитектуры объяснён требованиями и записан в ADR; критический путь проведён по C4 с ресурсом и бюджетом задержки на каждом шаге; макеты и полные C4 уровней 1 и 2 показывают продукт по основному назначению.

  7. 64.8 XP

    всё на уровне 5, плюс базовый план деградации под нагрузкой (что временно отключаем или упрощаем), бизнес-риски разобраны наравне с техническими, решение по архитектурному риску записано в ADR вместе с отвергнутой альтернативой, USM покрывает основные сценарии и типы пользователей.

  8. 75.6 XP

    всё на уровне 6, плюс приоритизация MoSCoW и типы пользователей в USM, риски приоритизированы и связаны с планом работ: что проверяем первым и к какому сроку.

  9. 86.4 XP

    USM качественнаяINVEST, MoSCoW, временные промежутки и контрольные точки, типы пользователей, зависимости. Показан план развития архитектуры на следующие этапы, план деградации конкретный: триггеры, что выключаем, кто отвечает, как возвращаем. Каждый риск связан с требованием с числом и с проверкой. В сборке, кроме макетов и C4, — первые работающие фрагменты ключевых механизмов.

  10. 97.2 XP

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

  11. 108 XP

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

Пересдачи

  • 1.0 — защита в срок, 17 октября
  • 0.6 — на ближайшем занятии после защиты: уровень 8, 7 ноября (дату подтверждает преподаватель)
  • 0.4 — на ближайшем занятии после защиты: уровень 9, 14 ноября (дату подтверждает преподаватель)

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