РАБОЧИЙ ПЛАН ЗАПУСКА 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-помощника к полноценной факультетской ИИ-системе, встроенной в сайт факультета и БРС.