РАБОЧИЙ ПЛАН ЗАПУСКА MVP
факультетской ИИ-системы автоматизации проверки работ и внесения баллов в БРС

Документ подготовлен как следующий слой после концепции, проектного предложения и сводного ТЗ.
Его задача - перевести уже согласованные идеи в управляемый план запуска реальной рабочей модели.

1. Текущее состояние проекта

По имеющимся материалам можно считать, что у проекта уже сформировано сильное концептуальное ядро.
На текущий момент у вас уже есть:

1. Концепция проекта и стратегическая логика:
   - human-in-the-loop
   - rules-first
   - teacher approval
   - поэтапное внедрение
   - ориентация на локальный факультетский контур в перспективе

2. Проектное предложение для руководства:
   - понятная управленческая формулировка пользы
   - ограниченный пилотный контур
   - ожидаемые эффекты и риски

3. Сводное ТЗ на MVP:
   - UI/UX блока "Рекомендация ИИ"
   - логика Rule Pack
   - статусная модель
   - роли
   - требования к БРС-интеграции
   - KPI пилота
   - функциональная рамка MVP

Вывод:
проект находится не на стадии "идеи", а на стадии перехода к предпроектному проектированию и запуску прикладной разработки.

2. Главная цель ближайшего этапа

Ближайшая цель - не построить сразу "идеальный факультетский ИИ", а запустить управляемый MVP-контур, который:

- принимает работу студента;
- применяет Rule Pack;
- формирует "Рекомендацию ИИ";
- показывает ее преподавателю в привычном интерфейсе;
- сохраняет итоговое преподавательское решение;
- подготавливает результат к переносу в БРС;
- при технической готовности безопасно синхронизирует утвержденный результат с БРС.

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

3. Что уже готово достаточно хорошо

С точки зрения запуска проекта наиболее зрелыми у вас уже выглядят следующие блоки:

- управленческая аргументация для руководства;
- принципиальная модель human-in-the-loop;
- понимание места teacher approval;
- логика Rule Pack как ядра прикладной системы;
- статусная модель жизненного цикла работы;
- осторожная позиция по отношению к слабоформализуемым работам;
- идея пилота на ограниченном контуре;
- понимание того, что БРС-интеграция должна быть идемпотентной и безопасной.

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

4. Что необходимо закрыть до старта реальной разработки

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

4.1. Карта текущих систем
- как устроен сайт факультета;
- где и как загружается работа;
- как выглядит окно "Рецензировать";
- какие поля уже существуют;
- как устроена БРС;
- есть ли API, web-форма, личный кабинет или только веб-интерфейс;
- как выглядит процесс подписи преподавателя.

4.2. Карта данных
- какие данные приходят от сайта факультета;
- какие идентификаторы есть у студента, работы, дисциплины, компетенции;
- как связать запись в портфолио с записью в БРС;
- какие поля обязательны для синхронизации;
- где нужны версии решения и версии работы.

4.3. Структура Rule Pack
- единый формат Rule Pack;
- минимальный набор полей;
- схема уровней;
- диагностические комментарии;
- ограничения применимости;
- формат осторожных статусов;
- версия и ответственный.

4.4. Пилотный набор сценариев
- одна дисциплина;
- один-два формализуемых типа работ;
- ограниченный перечень компетенций;
- ограниченный круг преподавателей;
- ограниченный период пилота.

4.5. UI-спецификация
- где именно в интерфейсе будет колонка "Рекомендация ИИ";
- как открывается расшифровка;
- как выглядит состояние "недостаточно данных";
- как преподаватель видит разницу между рекомендацией и своим итоговым решением;
- как визуально показывается готовность к переносу в БРС.

4.6. Интеграционный контур
- будет ли на MVP реальная синхронизация с БРС или только подготовка результата;
- каков минимальный протокол обмена;
- как будет фиксироваться успешная запись;
- как будет фиксироваться ошибка;
- как будет выглядеть повторная отправка.

4.7. Инфраструктурное решение
- где размещается backend;
- где хранится файл работы;
- где хранится результат анализа;
- какой ИИ-контур используется на пилоте;
- какой контур предполагается как стратегический локальный.

4.8. Организационный регламент
- кто отвечает за Rule Pack;
- кто отвечает за технический контур;
- кто подтверждает запуск пилота;
- как рассматриваются спорные кейсы;
- как обрабатывается повторная проверка.

5. Рабочая структура проекта

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

Поток 1. Product и методическая рамка
- формализация сценариев;
- описание поддерживаемых типов работ;
- разработка Rule Pack;
- согласование терминов и шкал.

Поток 2. Аналитика текущих систем
- исследование сайта факультета;
- исследование БРС;
- фиксация пользовательских маршрутов;
- карта данных и точек интеграции.

Поток 3. UI/UX и teacher workflow
- проектирование колонки "Рекомендация ИИ";
- проектирование расшифровки;
- проектирование окна преподавательского подтверждения;
- проектирование статусов и ошибок.

Поток 4. Backend и статусная модель
- прием работы;
- очередь анализа;
- хранение статусов;
- версия результата;
- журналирование;
- подготовка данных к БРС.

Поток 5. AI / Rule Engine
- разбор документа;
- извлечение признаков;
- применение Rule Pack;
- формирование уровня, статуса внимания и уверенности;
- генерация объяснимой рекомендации.

Поток 6. BRS Adapter
- сопоставление с целевой записью БРС;
- валидация допустимости передачи;
- идемпотентность;
- журнал операций;
- обработка ошибок синхронизации.

Поток 7. Пилот, эксплуатация и обратная связь
- подготовка ограниченного контура;
- сбор KPI;
- фиксация расхождений;
- доработка Rule Pack;
- решение о масштабировании.

6. Рекомендуемая фазовая модель запуска

Фаза 0. Discovery и уточнение контура
Смысл:
зафиксировать реальные процессы факультета и БРС "как есть".

Результат:
- карта пользовательских сценариев;
- карта данных;
- перечень экранов;
- перечень ролей;
- перечень ограничений интеграции;
- выбор пилотной дисциплины и типов работ.

Критерий завершения:
понятно, как работа движется по системе сейчас и где встраивается MVP.

Фаза 1. Проектирование MVP
Смысл:
перевести идеи и ТЗ в набор проектных артефактов, пригодных для разработки.

Результат:
- модель данных;
- схема Rule Pack;
- API-контракты;
- экранные сценарии;
- статусная модель;
- структура журналов;
- критерии приемки по каждому модулю.

Критерий завершения:
команда разработки понимает, что именно нужно делать, а не интерпретирует концепцию по-своему.

Фаза 2. Разработка ядра MVP
Смысл:
собрать минимальный рабочий контур без избыточной сложности.

Результат:
- прием и регистрация работы;
- очередь анализа;
- модуль Rule Pack;
- модуль "Рекомендация ИИ";
- базовый интерфейс преподавателя;
- журналирование;
- подготовка результата к БРС.

Критерий завершения:
маршрут "загрузка -> анализ -> рекомендация -> решение преподавателя -> готовность к переносу" работает стабильно.

Фаза 3. Интеграция и внутреннее тестирование
Смысл:
проверить работу сквозного маршрута и надежность системы.

Результат:
- тестовые сценарии;
- обработка ошибок;
- защита от повторной записи;
- фиксация историй версий;
- пилотный контур с ограниченным набором пользователей.

Критерий завершения:
система проходит сквозной тест без потери решения преподавателя.

Фаза 4. Пилотная эксплуатация
Смысл:
запустить систему на реальных работах в ограниченном режиме.

Результат:
- фактические KPI;
- обратная связь преподавателей;
- карта UX-проблем;
- карта ошибок рекомендаций;
- перечень доработок перед масштабированием.

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

Фаза 5. Решение о масштабировании
Смысл:
принять не эмоциональное, а фактическое решение по расширению проекта.

Результат:
- решение о расширении на новые типы работ;
- решение о реальной БРС-интеграции;
- решение о переходе к локальному факультетскому ИИ-контуру;
- решение о закупке инфраструктуры или использовании переходной внешней платформы.

7. Ближайший исполнимый план на 8-12 недель

Недели 1-2
- описать текущий процесс сайта факультета;
- описать текущий процесс БРС;
- собрать реальные скриншоты и поля интерфейсов;
- выбрать пилотную дисциплину;
- выбрать 1-2 типа работ;
- утвердить минимальный состав участников пилота.

Недели 2-4
- оформить формальный шаблон Rule Pack;
- выбрать стартовые компетенции;
- описать статусы и переходы;
- определить набор сущностей и полей данных;
- зафиксировать критерии приемки MVP.

Недели 4-6
- спроектировать UI блока "Рекомендация ИИ";
- спроектировать teacher approval flow;
- спроектировать интеграционный слой для БРС;
- определить, будет ли на пилоте реальная синхронизация или только подготовка результата.

Недели 6-9
- реализовать backend-маршрут;
- реализовать модуль анализа;
- реализовать журналирование;
- реализовать экран преподавателя;
- реализовать черновую версию BRS Adapter.

Недели 9-12
- провести внутреннее тестирование;
- провести ограниченный пилот;
- зафиксировать KPI;
- собрать замечания;
- подготовить решение о следующей итерации.

8. Минимальный состав команды

Для реального старта проекта нужен не "абстрактный ИИ-энтузиазм", а понятный набор ролей.

Минимально:
- академический владелец проекта;
- методический владелец Rule Pack;
- аналитик / системный архитектор;
- backend-разработчик;
- frontend-разработчик;
- инженер интеграции с БРС;
- AI/ML-инженер или инженер прикладного ИИ;
- системный администратор или DevOps;
- преподаватель-участник пилота.

На раннем этапе часть ролей может совмещаться, но все функции должны быть покрыты.

9. Что рекомендую не делать

1. Не начинать сразу с идеи "создать собственную большую модель с нуля".
2. Не начинать сразу со всех дисциплин и всех типов работ.
3. Не запускать прямую синхронизацию с БРС без журнала и идемпотентности.
4. Не строить систему вокруг чата как единственного интерфейса.
5. Не смешивать статус работы, академический уровень и диагностический комментарий.
6. Не обещать руководству мгновенную "полную автоматизацию", если не отработан пилотный маршрут.

10. Что рекомендую делать как основной вектор

1. Строить систему вокруг Rule Pack, teacher approval и аудита.
2. Начать с максимально формализуемых типов работ.
3. Сначала добиться стабильной рекомендации и удобства для преподавателя.
4. Затем вводить безопасную подготовку и передачу в БРС.
5. После успешного пилота принимать решение о масштабировании и локальном факультетском ИИ-контуре.

11. Definition of Ready для старта проектирования и разработки

Разработка может считаться готовой к старту, когда есть:

- согласованная пилотная дисциплина;
- выбранные типы работ;
- минимум один рабочий Rule Pack;
- описание текущих экранов сайта факультета;
- описание текущих экранов БРС;
- модель ролей;
- перечень обязательных полей данных;
- решение о формате MVP-интеграции с БРС;
- ответственный академический куратор;
- ответственный технический куратор.

12. Definition of Done для MVP-пилота

MVP можно считать состоявшимся, если:

- работа студента загружается и регистрируется;
- по поддерживаемому типу работы формируется "Рекомендация ИИ";
- преподаватель видит краткую рекомендацию и расшифровку;
- итоговое решение всегда принимается преподавателем;
- история действий и версий сохраняется;
- результат готовится к БРС или синхронизируется по правилам пилота;
- ошибки маршрута не приводят к потере данных;
- пилот показывает измеримую пользу по времени, прозрачности или качеству процесса.

13. Ключевой вывод

У проекта уже есть достаточно сильная содержательная база, чтобы переходить от концептуального обсуждения к реальному запуску проектирования.
Главная задача следующего этапа - не придумывать систему заново, а собрать правильную рабочую структуру: карта текущих систем, модель данных, Rule Pack, teacher approval flow, BRS adapter, пилотный контур и KPI.

Если двигаться именно так, то проект становится исполнимым, управляемым и масштабируемым.
Именно эта логика позволяет в дальнейшем перейти от MVP-помощника к полноценной факультетской ИИ-системе, встроенной в сайт факультета и БРС.
