Как создать веб‑приложение для школы: учёт и общение

Цели системы и круг пользователей

Школьное веб‑приложение почти всегда начинают «про электронный журнал», но на практике это система, которая снижает хаос в учёте и делает коммуникацию предсказуемой. Поэтому на старте важнее не перечислять функции, а договориться о целях: что именно школа хочет улучшить и по каким признакам это будет видно.

Какие задачи система должна закрыть

Обычно запрос школы укладывается в четыре блока:

• Учёт: списки классов, движение учеников, нагрузка учителей, расписание, посещаемость.
• Оценки и прогресс: выставление оценок, комментарии к работам, контроль задолженностей, сводные отчёты по предметам.
• Коммуникации: объявления, индивидуальные сообщения, согласования (например, экскурсии), напоминания.
• Отчётность: выгрузки для администрации, статистика по посещаемости и успеваемости, прозрачная история изменений.

Сразу проговорите границы: система «про школу» целиком или «про один класс/параллель»; будет ли она заменять бумажные журналы полностью или работать параллельно в переходный период.

Кто пользователи и зачем им система

Ключевые группы пользователей отличаются мотивацией и временем, которое они готовы тратить:

• Администрация хочет видеть целостную картину, быстро получать отчёты и контролировать качество данных.
• Учителя ценят скорость: поставить отметку, отметить отсутствие, отправить объявление — без лишних кликов.
• Родители ожидают понятных сигналов: что задано, что сдано, есть ли пропуски, важные новости.
• Ученики используют систему как «центр учебной рутины»: задания, оценки, расписание, уведомления.

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

Где обычно «болит» сейчас

Частые проблемы: бумажный журнал и дублирование в таблицах, разрозненные чаты по предметам, поиск «актуального» расписания, ручные отчёты в конце четверти, ошибки из‑за переноса данных и отсутствия единого источника правды.

Как определить успех

Критерии успеха лучше формулировать измеримо: сокращение времени на выставление оценок и подготовку отчётов, снижение количества исправлений и конфликтов «у меня было иначе», рост доли родителей, которые читают объявления, и более быстрый обмен информацией в нестандартных ситуациях.

Сбор требований и сценарии использования

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

Как собирать требования без «воды»

Проведите 6–10 интервью по 30–45 минут: 2–3 учителя, 1–2 классных руководителя, 2 родителя, 1 администратор/секретарь, при возможности — завуч. Спрашивайте не «что вы хотите», а «как вы делаете это сейчас».

Полезные вопросы:

• Какие действия вы выполняете каждый день/неделю?
• Где чаще всего возникают ошибки (оценки, посещаемость, объявления)?
• Что нужно сделать срочно, а что можно раз в месяц?
• Какие данные нельзя показывать всем подряд?

Сразу фиксируйте конкретные примеры: «в пятницу нужно разослать объявление всем 7А», «родитель просит объяснить, за что поставили 3», «учитель ставит оценки с телефона между уроками».

Пользовательские истории и сценарии

Затем оформите требования в пользовательские истории (user stories), чтобы команда одинаково понимала результат:

• Учитель: выставить оценку и комментарий по теме урока за 30 секунд.
• Классный руководитель: отметить посещаемость и причину отсутствия.
• Администратор: добавить ученика/перевести в другой класс, сохранив историю.
• Родитель: посмотреть успеваемость и домашние задания по предметам.
• Школа: отправить объявление выбранным классам и получить подтверждение прочтения.

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

Границы проекта и прототип до разработки

Чтобы не расползся объём, согласуйте границы: что точно входит в первую версию, а что откладывается (и почему). Это снимет споры на этапе разработки.

Перед стартом сделайте прототип ключевых экранов (черновые макеты): журнал оценок, посещаемость, лента объявлений, карточка ученика. Один цикл «прототип → 30 минут проверки с пользователем → правки» обычно экономит недели переделок.

Если нужно ускорить этот этап, можно использовать vibe‑coding подход: например, в TakProsto.AI вы описываете сценарии и экраны в чате, а платформа помогает быстро собрать рабочий черновик веб‑приложения (React на фронтенде, Go + PostgreSQL на бэкенде) и сразу показать его пользователям. Это удобно именно для проверки гипотез: что лишнее, где не хватает контекста, какие поля обязательны.

MVP: что обязательно, а что можно позже

MVP для школьного веб‑приложения — это версия, которая закрывает ежедневные задачи без «красоты ради красоты». Если учителю неудобно выставлять оценки и отмечать посещаемость за пару минут, система не приживётся, даже если в ней есть десятки дополнительных функций.

Минимальный набор модулей

В MVP обычно достаточно шести базовых блоков:

• Пользователи: учителя, ученики, родители, администратор (хотя бы в самом простом виде).
• Классы: состав класса, классный руководитель.
• Предметы и расписание/привязки: кто какой предмет ведёт в каком классе.
• Оценки: выставление, комментарий к оценке, исправления с историей (хотя бы минимальной).
• Посещаемость: отметка «присутствовал/отсутствовал», причина — опционально.
• Сообщения: простой канал «учитель ↔ родитель/ученик» или хотя бы заметки/объявления по классу.

MVP‑правило: сначала ежедневные операции

Приоритизируйте сценарии «каждый урок» и «каждый день»: быстро открыть нужный класс, выбрать предмет, отметить отсутствующих, поставить оценки, сохранить без ошибок. Для классного руководителя — просмотр сводки по классу и возможность связаться с родителями.

Отчёты, которые нужны уже в MVP

Отчётность в MVP не должна превращаться в аналитику. Достаточно трёх понятных отчётов:

• По классу: текущая посещаемость и успеваемость за период.
• По предмету: журнал оценок и средние значения по ученикам.
• По ученику: карточка ученика с оценками и пропусками.

План итераций: от основы к расширению

Практичный путь развития выглядит так: MVP (журнал и посещаемость) → расширение коммуникаций (шаблоны уведомлений, групповые сообщения, подтверждения прочтения) → аналитика и интеграции (сложные отчёты, выгрузки, внешние сервисы).

Если вы делаете MVP быстро и итеративно, полезно заранее предусмотреть «страховку» от неудачных изменений: снимки состояния и откат. Например, в TakProsto.AI есть snapshots и rollback — это удобно, когда вы часто меняете формы, роли и логику, а пилотная школа уже пользуется системой.

Роли и права доступа

Права доступа — не «формальность», а основа доверия к электронному журналу и коммуникациям. Если система устроена правильно, каждый видит ровно то, что ему нужно для работы, и не больше.

Базовые роли

Обычно хватает пяти ролей:

• Администратор школы — управляет структурой (классы, предметы), учётными записями, назначениями ролей, доступами и настройками.
• Учитель — ведёт уроки: выставляет оценки, отмечает посещаемость, пишет комментарии по своим предметам.
• Классный руководитель — дополнительно видит сводную картину по своему классу (успеваемость, посещаемость, заметки) и может отправлять объявления.
• Ученик — просматривает свои оценки, домашние задания, расписание, сообщения.
• Родитель — видит данные только своего ребёнка (или детей), получает уведомления, может отвечать на сообщения.

Принцип «минимально необходимого доступа»

Правило простое: доступ выдаётся по задаче. Учителю не нужен просмотр данных чужих классов, родителю — чужих детей, а ученику — правка оценок. Это снижает риски ошибок и конфликтов, а также упрощает соответствие требованиям по персональным данным.

Сложные случаи, которые стоит предусмотреть

• Несколько родителей: у одного ребёнка может быть 2–3 законных представителя с разными правами (например, один получает уведомления, другой — только просмотр).
• Учитель в нескольких школах: один аккаунт, но раздельные контуры данных и разные администраторы.
• Группы и подгруппы: факультативы, профильные группы, индивидуальные занятия — доступ учителя должен ограничиваться именно его группами.

Журналы действий (аудит)

Обязательная функция для спорных ситуаций: фиксируйте, кто и когда изменил оценку или посещаемость, что было «до» и что стало «после». Эти журналы должны быть доступны администраторам и, при необходимости, руководству школы, но не всем пользователям.

Модель данных: ученики, классы, предметы и оценки

Хорошая модель данных — это «скелет» школьного веб‑приложения: от неё зависит, насколько просто будет вести электронный журнал, строить отчёты и добавлять новые функции без переделок. Начните с ключевых сущностей и их связей, а затем аккуратно оформите справочники и правила изменения схемы.

Базовые сущности

Минимальный набор, который покрывает учёт и журнал:

• Школа (если система поддерживает несколько школ — обязательна).
• Учебный год и, при необходимости, периоды (четверть/триместр/полугодие).
• Класс (например, 7А) + привязка к учебному году.
• Ученик (персональные данные отдельно от учебных).
• Учитель.
• Предмет.
• Урок (конкретное занятие: дата, тема, класс, предмет, учитель).
• Оценка (за что поставлена, тип работы, дата, значение).
• Посещаемость (присутствовал/отсутствовал, причина).

Важно: урок лучше хранить как отдельную сущность, а не как строку в расписании — тогда оценки и посещаемость естественно «цепляются» к конкретному занятию.

Связи, без которых быстро начнутся проблемы

• Ученик ↔ класс: обычно «многие к одному» (много учеников в одном классе), но с учётом переводов полезна история: таблица привязок с датами.
• Учитель ↔ предмет ↔ класс: это не просто «учитель ведёт предмет», а назначение на конкретный класс (например, учитель математики ведёт 7А и 7Б, но не 8А).
• Расписание ↔ урок: расписание задаёт план (день недели/пара), а урок — факт (конкретная дата). Это помогает корректно обрабатывать замены и переносы.

Нормализация и справочники

Чтобы данные не расползались, вынесите повторяющиеся значения в справочники:

• Шкала оценок (5‑балльная, зачёт/незачёт, «н/а») — как справочник с правилами валидации.
• Причины отсутствия (болезнь, уважительная, без причины) — отдельно, чтобы не было «болел/болела/больничный».

Так проще строить отчёты и не ломать фильтры из‑за разных написаний.

Миграции и версионирование схемы

Структура данных будет меняться: добавятся типы работ, новые периоды, несколько школ или классы «по профилям». Делайте изменения только через миграции:

• добавляйте поля/таблицы с безопасными значениями по умолчанию;
• сначала разворачивайте схему, затем код, и лишь потом включайте использование новых полей;
• храните версию схемы в репозитории, чтобы можно было откатиться и воспроизвести окружение.

Это снижает риск «потерять журнал» при обновлении и упрощает поддержку продукта.

Интерфейсы: учитель, родитель, ученик и администратор

Хороший интерфейс школьного веб‑приложения — это не «красиво», а «быстро и без ошибок». У разных пользователей разные задачи, поэтому лучше сразу проектировать четыре отдельных кабинета, а не один универсальный экран.

Панель учителя

Учителю важно успевать на перемене, поэтому главная страница должна отвечать на вопрос «что делать прямо сейчас»: уроки на сегодня, ближайший звонок, нужный класс.

Ключевые элементы:

• список уроков на день с быстрым переходом в журнал;
• быстрый ввод посещаемости (одним касанием на ученика) и оценок (минимум кликов);
• подсказки статусов: «не сохранено», «сохранено», «проверить».

Отдельно продумайте массовые действия: отметить «все присутствуют», поставить типовую домашнюю работу сразу всему классу, быстро добавить комментарий.

Кабинет родителя и ученика

Родителю важны прозрачность и уверенность, что он ничего не пропустил. Ученику — понятный план и текущие результаты.

В кабинете должны быть:

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

Чтобы снизить конфликтность, добавляйте контекст: тему урока, критерии оценивания (если есть), комментарий учителя. Формулировки — нейтральные и однозначные.

Админ‑панель

Администратор — это «оператор данных»: создаёт классы, назначает учителей, ведёт учебный план, решает проблемы доступа.

Важно предусмотреть:

• управление пользователями и привязками (ученик → класс, учитель → предметы/классы);
• импорт/экспорт (например, списки учеников), историю изменений и журнал действий;
• быстрый поиск и фильтры по школе/параллели/классу.

Доступность и мобильная адаптация

Школьные интерфейсы часто используют с телефона. Делайте крупные кликабельные элементы, понятные статусы, читаемые шрифты, контрастные кнопки. Ошибки ввода должны предотвращаться: подтверждение массовых действий, автосохранение черновиков, заметное сообщение о несохранённых изменениях.

Коммуникации и уведомления

Коммуникации — «нервная система» школьного веб‑приложения: через неё проходят срочные объявления, вопросы по урокам, уточнения по домашнему заданию и организационные сообщения. Если этот блок сделан продуманно, он снижает нагрузку на учителей и администратора и уменьшает количество пропущенной важной информации.

Типы общения

Обычно полезно разделить коммуникации на несколько форматов, чтобы не смешивать «официальное» и «личное»:

• Объявления: школе целиком, параллели, конкретному классу или группе (например, кружку). Такие сообщения лучше фиксировать как официальные, с видимой датой и автором.
• Личные сообщения: точечные вопросы родителя учителю, обращение ученика к классному руководителю, запрос администратору.
• Диалоги по предмету: обсуждения, привязанные к предмету/уроку/домашнему заданию, чтобы контекст не терялся.

Модерация и ограничения

Важно заранее определить правила «кто кому может писать», иначе чат превратится в хаос. На практике хорошо работают:

• ограничения адресатов (например, ученик пишет только учителям своего класса/предметов);
• часы тишины (уведомления не доставляются ночью, но сообщения сохраняются);
• шаблоны сообщений для типовых ситуаций (перенос урока, сбор согласий, просьба принести документы) — это ускоряет рассылки и делает тон единообразным.

Уведомления: по событию и по расписанию

Каналы доставки обычно комбинируют: e‑mail, push (если есть мобильное приложение или PWA) и SMS через провайдера для критически важных событий.

Отдельно продумайте два режима:

• по событию (новая оценка, замечание по посещаемости, новое объявление, ответ в диалоге);
• по расписанию (ежедневная/еженедельная сводка, напоминание о завтрашнем уроке/контрольной).

История и поиск

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

Безопасность и персональные данные

Школьное веб‑приложение почти всегда работает с персональными данными детей и родителей, а значит, безопасность — не «дополнительная опция», а базовое требование. Ошибка здесь бьёт по доверию и может привести к юридическим последствиям.

Обязательные меры на старте

Начните с критичного минимума:

• HTTPS везде: никаких исключений для «внутренних» страниц или поддоменов. Сертификаты и авто‑продление — часть эксплуатации.
• Пароли только в виде хэшей: используйте современное хэширование с солью (например, bcrypt/Argon2) и никогда не храните пароли в открытом виде.
• Защита от подбора: лимиты попыток входа, задержки, капча при подозрительной активности, уведомления о множественных неудачных входах.
• Снижение риска утечек: логируйте аккуратно (без паролей, токенов и полных данных ребёнка), закрывайте админ‑панель, регулярно обновляйте зависимости.

Персональные данные: минимизация и доступ

Собирайте только то, без чего нельзя выполнить сценарии (электронный журнал, посещаемость, уведомления). Любое поле «на будущее» — лишний риск.

Заранее определите:

• Сроки хранения: что удаляется по окончании учебного года, что архивируется и на сколько.
• Разграничение доступа: учитель видит только свои классы/предметы, родитель — только своего ребёнка, администратор — ровно то, что нужно для поддержки.
• Экспорт и отчёты: выгрузки (Excel/PDF) часто становятся источником утечек — ограничьте права, добавьте журнал действий, при необходимости используйте водяные знаки.

Резервные копии и восстановление

Бэкапы нужны не «когда будет время», а сразу:

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

Сессии и вход в систему

Продумайте безопасность сессий: короткоживущие токены, таймаут бездействия, выход со всех устройств, привязка к устройству/браузеру при необходимости. 2FA можно включать выборочно: для администраторов и сотрудников с расширенными правами — почти всегда оправдано.

И главное: безопасность — это процесс. Запланируйте регулярные проверки, обновления и обучение сотрудников базовой гигиене (фишинг, пароли, работа с выгрузками).

Архитектура и ключевые компоненты

Хорошая архитектура для школьного веб‑приложения — это не «космос», а набор понятных решений, которые помогают быстро выпустить MVP и не утонуть в доработках через полгода. Важно заранее договориться о границах модулей: где живут данные, как общаются интерфейсы, что выполняется «в фоне», и как вы будете находить ошибки.

Монолит или модульный подход для старта

Для MVP чаще выигрывает монолит с модульной структурой: одно приложение и одна точка деплоя, но внутри — чёткие области (пользователи и роли, журнал/оценки, посещаемость, сообщения, справочники). Это проще в поддержке, тестировании и отладке: меньше сетевых вызовов, меньше DevOps‑нагрузки, быстрее изменения.

Микросервисы обычно оправданы позже — когда появились отдельные команды, реальная нагрузка, разные темпы релизов или сложные интеграции. Риск раннего «дробления» — усложнить разработку, не получив заметной пользы.

API: REST/GraphQL, версионирование и ошибки

Даже если вы начинаете с серверного рендеринга, API всё равно понадобится: мобильное приложение, интеграции, админка, отчёты.

• REST проще для команды и документации, хорошо ложится на сущности вроде учеников, классов, оценок.
• GraphQL удобен для сложных экранов (например, «страница ученика» с оценками, посещаемостью и комментариями), но требует дисциплины в безопасности и ограничении запросов.

Сразу заложите:

• версионирование (например, /api/v1/...), чтобы не ломать клиентов при изменениях;
• единый формат ошибок: код, понятное сообщение, детали для разработчиков (например, поля валидации).

Фоновые задачи

Часть действий не должна блокировать пользователя и не обязана выполняться мгновенно:

• отправка уведомлений (оценки, пропуски, объявления);
• генерация отчётов и выгрузок;
• импорт данных (списки учеников/классов из файлов);
• периодические задачи (сверка статусов, очистка временных данных).

Технически это отдельный обработчик очереди задач или планировщик, который работает рядом с основным приложением.

Логи и мониторинг: что отслеживать

Чтобы быстро находить проблемы, полезно с первого релиза собирать минимум наблюдаемости:

• логирование действий (входы, изменения оценок/посещаемости, кто и что исправил);
• ошибки API (частота, конкретные эндпоинты, типы исключений);
• производительность (время ответов, медленные запросы к базе);
• доставка уведомлений (сколько отправлено, сколько не доставлено, почему).

Дополнительно помогает корреляция запросов (request id), чтобы связать жалобу пользователя с конкретной цепочкой событий в логах.

Интеграции и дополнительные функции

Даже самый аккуратный электронный журнал быстро упирается во «внешний мир»: нужно раздавать доступ, обмениваться файлами, отправлять сообщения и учитывать правила конкретной школы. Интеграции и дополнительные функции стоит планировать заранее, но подключать поэтапно — чтобы не раздувать сроки.

Авторизация и управление доступом

Помимо схемы «логин/пароль», в школах часто удобнее приглашения: администратор (или классный руководитель) отправляет ссылку родителю или ученику, и аккаунт создаётся без ручного ввода данных.

Предусмотрите восстановление доступа: через e‑mail или SMS, с ограничением по времени и защитой от частых попыток. Это снижает нагрузку на администратора и ускоряет запуск в реальных условиях.

Импорт/экспорт: CSV, PDF и «жизнь после таблиц»

Почти всегда стартовые списки учеников и классов уже существуют в Excel или другой системе. Поэтому импорт CSV — одна из самых окупаемых функций: он экономит часы ручного ввода и снижает количество ошибок.

Экспорт нужен не только «для отчётности», но и для ежедневной работы: выгрузка успеваемости и посещаемости в CSV, печатные отчёты в PDF для педсоветов, справок и внутреннего контроля.

Интеграции: почта, SMS и школьные системы

Для уведомлений достаточно начать с почты, а затем подключить SMS‑провайдера для срочных сообщений (например, отмена уроков). Желательно, чтобы каналы можно было включать/выключать по типам событий.

Если в школе уже есть СУБД или учётная система (например, кадровая или расписание), заранее определите формат обмена: файл по расписанию, API или двусторонняя синхронизация. Часто «односторонний импорт раз в сутки» закрывает 80% потребностей без сложной интеграции.

Мультиязычность и настройки школы

Даже в одном городе школы отличаются: часовой пояс (особенно для дистанционных групп), форматы дат, шкалы оценивания и правила округления. Эти параметры лучше вынести в настройки школы, чтобы не «зашивать» логику в код.

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

Тестирование и контроль качества

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

Автоматические тесты: от логики до сценариев

Модульные тесты закрывают критичную бизнес‑логику: правила округления и пересчёта средних, закрытие периода, весовые коэффициенты, обработку пропусков, перенос ученика между классами. Это быстрые проверки, которые запускаются на каждом изменении.

Интеграционные тесты проверяют API и взаимодействие компонентов: создание урока → выставление оценки → отображение в журнале → попадание в отчёт. Здесь важно тестировать ошибки и пограничные случаи (например, дублирование записей, параллельные изменения).

E2E‑тесты (сквозные) имитируют действия учителя/родителя/ученика в интерфейсе: вход, просмотр расписания, выставление оценки, подтверждение пропуска, поиск по ученикам. Их должно быть немного, но они должны покрывать самые частые сценарии.

Проверка прав доступа

Качество системы напрямую зависит от безопасности:

• тесты на доступ к оценкам только своего класса/ребёнка;
• проверки, что ученик не видит чужие данные;
• попытки изменить оценки без прав (должны корректно блокироваться и логироваться).

Нагрузочные проверки

Отдельно прогоните нагрузки, характерные для школы: массовый вход утром, рассылка уведомлений по параллели, «конец четверти» (пик правок и отчётов). Снимайте метрики времени ответа и долю ошибок.

Приёмка с пилотной школой

Перед запуском проведите пилот с чек‑листом: корректность оценок/посещаемости, понятность ролей, скорость работы на школьной сети, качество уведомлений. Обратную связь собирайте структурно (форма + короткие интервью) и фиксируйте решения в задачах на следующий релиз.

Запуск, поддержка и развитие продукта

Запуск школьного веб‑приложения — не «финал», а переход в режим регулярной эксплуатации. Важно заранее договориться, где будет жить система, как обновляться и кто отвечает за стабильность, чтобы учителя и родители не сталкивались с сюрпризами в середине четверти.

Развёртывание: облако или сервер школы

Чаще выбирают облако: проще масштабировать, удобнее мониторинг и резервирование. Сервер школы возможен, если есть ИТ‑специалист и понятные требования по доступу к интернету.

Минимальный чек‑лист:

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

Если для вас принципиально, чтобы инфраструктура и данные оставались в России, это стоит зафиксировать как требование ещё до выбора стека и хостинга. В этом контексте TakProsto.AI может быть удобной основой: платформа работает на серверах в России, использует локализованные/opensource LLM‑модели и не отправляет данные за пределы страны; при этом поддерживает деплой и хостинг, подключение кастомных доменов и экспорт исходного кода.

CI/CD и безопасные релизы

Чтобы обновления не ломали электронный журнал и «родительский кабинет», внедрите автоматическую сборку и доставку.

Практика, которая быстро окупается:

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

Поддержка, регламент и коммуникация

Определите регламент: время реакции на инциденты, сроки исправления, кто принимает заявки (почта, тикет‑система, форма внутри приложения). Запланируйте «окно обслуживания» — например, поздний вечер или выходные — и заранее предупреждайте пользователей через уведомления в системе.

Документация и обучение

Не нужны толстые инструкции. Работают короткие сценарии на 1–2 страницы:

• «Как выставить оценку/посещаемость» для учителя;
• «Как подтвердить данные ребёнка и настроить уведомления» для родителя;
• «Как завести класс и предметы» для администратора.

Дополните это мини‑обучением на 30–40 минут и разделом помощи внутри приложения. Дальше развитие продукта логично вести от запросов пользователей: собирать обратную связь, оценивать эффект и выпускать улучшения небольшими, предсказуемыми итерациями.