RAT-PoC

Что за босс

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

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

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

Продукт и User Story Map

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

Риски

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

Решение (RAT)

• для каждого рискового элемента — решение на конкретном методе или технологии, а не на предположении;
• аргументация выбора метода или технологии.

Сборка (proof of concept)

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

Правила боя

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

Шкала 0–10

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

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

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

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

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

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

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

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

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

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

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

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