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