Задача
Школа ведёт десяток процессов врозь. В учебной части это расписание, оценки, посещаемость, домашние задания, тесты и библиотека материалов, в административной — структура персонала и классов, переписка с родителями, приём и перевод учеников. По отдельности каждый несложен. Сложность в том, что они ссылаются друг на друга. Оценка привязана к уроку, урок — к теме учебной программы, тема — к материалу, материал — к курсу и классу, класс — к учебному году. Пока эти связи держатся на бумаге, ни директор, ни родитель не видят цельной картины, а учитель дважды вводит одно и то же.
Второе условие — связь. Платформа должна была работать в школах с нестабильным интернетом, а учитель не может зависеть от качества канала во время урока: оценки, посещаемость и заметки нужно сохранить сразу, а синхронизировать когда получится.
Третье — разный масштаб пользователя. Тот же продукт должен был подходить и большой частной школе, и репетитору, которому нужны курс, группа учеников и материалы к ним.
Решение
Модель школы и области доступа. В основе — учебные годы и периоды, классы, предметы, программы, преподаватели, классные руководители, ученики и связанные с ними родители. Матрица прав учитывает роль и область действия: конкретную школу, класс, предмет, курс или ребёнка. Поэтому один преподаватель ведёт несколько дисциплин в разных группах и не получает доступа к посторонним данным, классный руководитель видит полный контекст своего класса, а родитель — только связанных с ним детей.
Урок как единая точка ввода. Учитель открывает нужный урок и в одном интерфейсе отмечает присутствие с причинами отсутствия, выставляет оценки, записывает тему и содержание занятия. Там же он назначает домашнее задание со сроком, прикрепляет учебник или презентацию, публикует тест на класс, оставляет индивидуальную рекомендацию ученику и внутреннюю заметку, доступную только сотрудникам. Оценка хранится вместе с типом работы и темой программы, так что рядом со средним баллом видна карта освоения материала. Школа может использовать собственные шкалы оценивания и правила расчёта периода.
Рекомендации по пробелам. Система сопоставляет результаты тестов, домашних работ и оценок с разделами учебной программы. Если по разделу накапливаются слабые результаты, в профиле появляется рекомендация повторить тему, а рядом — связанные главы учебника, задания и дополнительные материалы. Учитель работает с этим как с подсказкой: подтверждает, меняет или дополняет. Родителю и ученику показывается понятная формулировка без внутренних педагогических заметок.
Согласования родителей. Для решений, которые школа не принимает за семью, сделан отдельный сценарий. Школа публикует поездку, срок ответа и нужные документы, родитель подтверждает или отклоняет участие ребёнка внутри кабинета. Система сохраняет автора, время и результат решения; администрация видит, кто уже ответил, кому нужно напоминание и по каким ученикам согласие ещё не получено. Тот же механизм работает для экскурсий, занятий вне школы и публикации материалов.
Профиль ученика, переносимый между школами. Родитель может зарегистрироваться сам, найти школу и отправить заявку на поступление или перевод; школа запрашивает уточнения, приглашает семью на следующий этап и фиксирует решение. При переходе между школами платформы базовый профиль ученика и согласованная часть образовательной истории переносятся в новое учреждение после подтверждения сторон и родителя. Система заранее разделяет переносимые сведения и внутренние записи, которые остаются у прежней школы. Новая школа сразу видит текущую программу, освоенные темы и то, что требует внимания.
Мобильное приложение работает без сети. Перед занятием приложение забирает актуальное расписание, списки классов и нужные данные. Во время урока изменения ложатся в локальную очередь: так журнал можно вести в спортивном зале, на площадке или в поездке. После восстановления связи накопленные операции уходят на сервер, а приложение получает чужие изменения. Протокол синхронизации учитывает повторную отправку, версии записей и конфликты: безопасные изменения объединяются автоматически, неоднозначные (например, параллельное редактирование одной оценки) откладываются на разбор ответственному сотруднику.
Две поставки, одно ядро. Прикладное ядро на ASP.NET общее для обеих версий, различается инфраструктура. Установка на сервере учреждения работает автономно и продолжает обслуживать локальную сеть без внешнего интернета; облачная версия разводит организации как независимых арендаторов с собственными ролями и данными. Клиентские приложения обращаются к одному набору операций, синхронизация передаёт только изменения, а фоновые процессы разбирают уведомления, рекомендации и отчётность.
Данные несовершеннолетних. Доступ спроектирован по принципу минимально необходимых прав, история действий записывает изменения оценок, доступов, согласий и статусов заявок. На устройстве хранится только нужный для работы объём, защищённый учётной записью, а после синхронизации устаревшие данные очищаются по политике школы.
Результат
Разрозненные журналы и переписки школы сошлись в одной системе. Директор и администрация видят структуру персонала, состав классов и загрузку преподавателей, выполнение программы, сводную успеваемость и посещаемость. Им же видны заявки на поступление и история административных решений. Преподаватели ведут занятия и дневник там же, где лежат программа и материалы. Родители получают уведомления об оценках, пропусках и изменениях расписания и подтверждают участие ребёнка внутри кабинета, а не в мессенджере. Ученик видит расписание, задания, сроки и учебники, а рядом с итоговым баллом — собственную динамику по темам.
Offline-first архитектура сняла зависимость урока от качества связи, а общее прикладное ядро позволило продавать один продукт двум разным клиентам: школе, которой нужен автономный сервер внутри здания, и репетитору, которому достаточно облачной мини-школы.
