Разработка LMS для онлайн-школы: этапы, функции и стоимость

Что оценивать до заказа разработки LMS?

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

Упаковать эти сведения помогает структура технического задания. Если часть процесса пока неизвестна, вынесите её в реестр вопросов с владельцем решения и способом проверки.

Какие роли и права нужны онлайн-школе?

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

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

Как описать учебный маршрут?

Маршрут связывает бизнес-правила и интерфейсы. Запишите основной путь, альтернативы и события, которые меняют доступ: оплату, дату старта, результат теста, проверку задания, окончание подписки или решение сотрудника.

1. 01

   Зачисление

   Ученик создан, сопоставлен с заказом и назначен в поток без дубля.

2. 02

   Старт

   Понятны дата, часовой пояс, доступные модули и первое действие.

3. 03

   Прохождение

   Платформа сохраняет прогресс, попытки, ответы и возврат к занятию.

4. 04

   Проверка

   Работа попадает ответственному, а статус и обратная связь видны ученику.

5. 05

   Завершение

   Правило учитывает обязательные уроки, задания, тесты и ручные решения.

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

Что включить в MVP собственной LMS?

MVP должен провести один реальный поток по основному маршруту и сохранить результат. Первая версия не обязана закрывать все форматы обучения, способы продаж и варианты отчётности.

Граница зависит от гипотезы проекта. Принцип отбора функций подробнее раскрыт в статье что включить в MVP продукта. Ручной временный шаг допустим, если у него есть владелец, инструкция и предел нагрузки.

Как устроить архитектуру LMS?

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

Не каждый LMS-проект требует микросервисов или отдельного хранилища учебных событий. Решение принимают по нагрузке, независимости модулей, требованиям к отказоустойчивости и компетенциям команды сопровождения.

Какие интеграции влияют на объём проекта?

Для каждой связи нужны направление обмена, система-источник, ключ сопоставления, частота, повторная обработка и ручной сценарий при ошибке. Формулировка «интеграция с CRM» не показывает объём работ.

• сайт и CRM: лид, заказ, продукт, тариф, поток и ответственный;
• платёжный провайдер: подтверждение, возврат, рассрочка и повторное событие;
• видео и вебинары: право просмотра, срок доступа, запись и посещение;
• почта и мессенджеры: шаблон, согласие, статус доставки и ограничение повторов;
• поддержка: связь обращения с учеником, курсом и оплатой;
• аналитика: словарь событий, идентификаторы и правила расчёта;
• учебные инструменты: необходимость SCORM, xAPI или LTI под заданный обмен.

До сметы запросите документацию, тестовую среду, лимиты и примеры ответов каждого API. Для нестабильной или неизвестной связи заложите технический эксперимент. Состав такого контракта разобран в материале об интеграции по API, а место LMS в общем контуре школы показано в карте автоматизации онлайн-школы.

Из каких этапов состоит разработка LMS?

Проект проходит исследование, проектирование, реализацию, проверку и запуск. После каждого этапа должны оставаться артефакты, по которым можно уточнить границу следующего и пересчитать оценку.

1. Диагностика. Цель, заинтересованные стороны, текущий процесс, ограничения и исходные метрики.
2. Исследование пользователей. Интервью и наблюдение за учеником, преподавателем, куратором и администратором.
3. Проектирование. Карта маршрута, роли, прототип, модель данных, контракты интеграций и критерии MVP.
4. Технические эксперименты. Проверка неизвестных API, видео, импорта контента, нагрузки или стандарта обмена.
5. Разработка итерациями. Вертикальные части основного пути с демонстрацией на тестовых данных.
6. Тестирование и защита. Функциональные, интеграционные, нагрузочные и security-проверки в согласованном объёме.
7. Пилот. Один курс или поток, обучение команды, поддержка пользователей и журнал проблем.
8. Запуск и развитие. Контролируемое расширение, мониторинг, резервные копии и план следующих релизов.

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

Из чего складываются стоимость и срок?

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

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

Сравнивайте подрядчиков по одинаковому результату и составу работ. Подробная карта статей бюджета есть в разборе стоимости разработки веб-приложения.

Какие требования к безопасности зафиксировать?

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

• разграничение доступа проверяется на сервере для каждой операции;
• административные действия и изменения критичных данных попадают в журнал;
• многофакторная защита применяется к привилегированным ролям;
• секреты интеграций хранятся отдельно от кода и регулярно заменяются;
• резервные копии восстанавливаются на проверке, а не только создаются;
• выгрузка и удаление данных имеют отдельные права и протокол;
• зависимости, код и конфигурация проходят согласованные security-проверки;
• доступность интерфейса проверяется автоматическими и ручными сценариями.

OWASP ASVS можно использовать как основу требований и проверки технических мер для веб-приложения, а WCAG 2.2 - как проверяемую основу доступности. Применимость Федерального закона № 152-ФЗ, локализации и иных требований к конкретной модели школы следует подтвердить с профильным специалистом.

Как принять LMS и измерить пилот?

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

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

Пакет передачи включает код и права на него по договору, инструкции развёртывания, схему данных, описание API, тесты, журнал известных ограничений, доступы к инфраструктуре и план поддержки. Следующий релиз планируют по данным пилота, а не по исходному списку пожеланий.

Частые вопросы