Техническое задание на MVP платформы обучающих курсов

Рабочее название: Платформа независимых авторов курсов по психологии и смежным темам
Версия: 0.1
Статус: концептуальное ТЗ для обсуждения, оценки и декомпозиции
Дата: 6 августа 2026 года

1. Назначение документа

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

Основной тематический фокус — психология в широком бытовом и профессиональном понимании. Архитектура и модель данных должны позволять без изменения основной логики добавлять смежные категории: lifestyle, нутрициологию, фитнес, mindfulness и другие образовательные направления.

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

2. Продуктовая концепция

Продукт представляет собой брендированный marketplace курсов с несколькими независимыми преподавателями, совмещающий:

1. публичный каталог преподавателей и курсов;
2. конструктор и хостинг учебных материалов;
3. личные кабинеты преподавателей и учеников;
4. тестирование, задания и обратную связь;
5. продажи, учёт комиссии платформы и расчётов с преподавателями;
6. административную модерацию и базовую аналитику.

В MVP используется модель управляемого marketplace:

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

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

3. Цели MVP

MVP должен подтвердить, что:

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

4. Не-цели MVP

В MVP не входят:

• автоматическое перечисление денег и split-платежи нескольким получателям;
• автоматические налоговые расчёты и проверка налогового статуса преподавателя;
• юридическая проверка профессиональной квалификации и лицензий;
• встроенная видеоконференцсвязь;
• крупномасштабный realtime-чат, личные сообщения между всеми пользователями и социальная сеть;
• нативные приложения для iOS и Android;
• подписка на общую библиотеку курсов;
• мультивалютность и несколько юридических лиц-продавцов;
• распределение выручки между соавторами одного курса;
• партнёрская программа и многоуровневая реферальная система;
• прокторинг, SCORM/xAPI и сложные адаптивные учебные траектории;
• встроенная CRM полного цикла и сложные маркетинговые автоворонки;
• генерация контента или проверка заданий с помощью ИИ;
• обещание фактически неограниченного хранилища или видеотрафика.

5. Термины

• Платформа — весь создаваемый продукт.
• Преподаватель — независимый автор или ведущий курса; может одновременно быть учеником.
• Ученик — пользователь, получивший доступ к курсу.
• Курс — продаваемая или бесплатная учебная единица, состоящая из модулей и уроков.
• Поток — группа учеников с общими датами обучения; в MVP является необязательным режимом курса.
• Модуль — логический раздел курса.
• Урок — минимальная последовательная единица обучения с материалами и, при необходимости, заданием.
• Зачисление — право конкретного пользователя на доступ к курсу.
• Финансовый реестр — внутренний неизменяемый журнал операций, используемый для расчёта доли платформы и преподавателя.
• Модерация — проверка профиля преподавателя или курса перед публикацией.
• Лимит хранения — разрешённый преподавателю объём файлов и видео.

6. Пользовательские роли

Одна учётная запись может сочетать роли ученика и преподавателя. Административные роли назначаются только администратором. Доступ преподавателя строго ограничивается его курсами, учениками, заданиями и финансовыми показателями.

7. Приоритеты требований

• P0 — обязательно для запуска MVP.
• P1 — следующий релиз после подтверждения базовой модели.
• P2 — перспективное развитие.

Все требования разделов 8–18, если прямо не указано иное, имеют приоритет P0.

8. Регистрация, вход и управление доступом

8.1. Функциональные требования

• AUTH-01. Пользователь регистрируется по адресу электронной почты и паролю либо одноразовому коду.
• AUTH-02. Адрес электронной почты должен быть подтверждён до покупки, публикации курса или отправки задания.
• AUTH-03. Должны поддерживаться вход, выход, восстановление доступа и завершение активных сессий.
• AUTH-04. Пользователь принимает пользовательское соглашение и политику обработки данных; согласие на маркетинговые сообщения оформляется отдельно.
• AUTH-05. Администратор может блокировать и разблокировать учётную запись с указанием причины.
• AUTH-06. Администратор может назначать и отзывать административные роли.
• AUTH-07. Для администраторов и финансовых сотрудников должна поддерживаться двухфакторная аутентификация.
• AUTH-08. Все проверки прав выполняются на сервере; скрытия элементов интерфейса недостаточно.
• AUTH-09. Критичные действия администратора, модератора и финансового сотрудника записываются в журнал аудита.

9. Подключение и модерация преподавателей

9.1. Анкета преподавателя

Пользователь подаёт заявку и указывает:

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

9.2. Статусы заявки

Черновик → На проверке → Требуются изменения → Одобрена / Отклонена → Приостановлена.

9.3. Требования

• TEA-01. Пользователь сохраняет анкету как черновик и отправляет её на проверку.
• TEA-02. Модератор видит очередь заявок, содержимое анкеты и историю решений.
• TEA-03. Модератор одобряет заявку, отклоняет её или возвращает с комментарием и перечнем необходимых изменений.
• TEA-04. Решение и комментарий отправляются пользователю по электронной почте и отображаются в кабинете.
• TEA-05. Только одобренный преподаватель может отправлять курс на модерацию.
• TEA-06. Администратор может временно приостановить права преподавателя. Уже купленные курсы при этом не должны автоматически исчезать у учеников; дальнейшее решение принимает администратор.
• TEA-07. Изменение имени, специализации или иных отмеченных как существенные публичных данных может требовать повторной модерации.
• TEA-08. Документы и платёжные реквизиты доступны только уполномоченным ролям и не выводятся в публичном профиле.

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

10. Конструктор и жизненный цикл курса

10.1. Структура курса

Курс → Модули → Уроки → Контентные блоки и/или контрольное задание.

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

10.2. Карточка курса

Обязательные поля:

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

10.3. Поддерживаемый контент

• форматированный текст;
• изображения;
• аудиофайлы;
• видео;
• PDF и разрешённые документы;
• скачиваемые вложения;
• внешняя ссылка;
• встраиваемый контент от разрешённых провайдеров;
• тест;
• открытое задание.

Форматы, максимальный размер одного файла и список запрещённых расширений настраиваются администратором. Исполняемые файлы в MVP запрещены.

10.4. Жизненный цикл

Черновик → На модерации → Требуются изменения → Одобрен → Опубликован → Скрыт / Архивирован.

10.5. Требования

• CRS-01. Преподаватель создаёт, копирует и редактирует только свои курсы.
• CRS-02. Курс может содержать произвольное число модулей и уроков в пределах эксплуатационных лимитов.
• CRS-03. Должны поддерживаться предварительный просмотр курса и просмотр от имени ученика до отправки на модерацию.
• CRS-04. Отдельные уроки можно отметить как бесплатные ознакомительные.
• CRS-05. Для уроков поддерживается обязательная последовательность: следующий урок закрыт, пока не выполнено заданное условие предыдущего.
• CRS-06. Условием завершения урока может быть просмотр/отметка ученика, прохождение теста либо принятие задания преподавателем.
• CRS-07. Преподаватель отправляет готовый курс на модерацию. Модератор возвращает его на исправление, одобряет или отклоняет с комментарием.
• CRS-08. Публикация курса выполняется только после одобрения и заполнения обязательных коммерческих полей.
• CRS-09. Существенные изменения опубликованного курса — цена, обещаемый результат, категория, преподаватель и значительная замена программы — должны формировать новую версию для повторной модерации. Несущественные исправления могут публиковаться сразу согласно настройке администратора.
• CRS-10. Снятие курса с продажи прекращает новые покупки, но сохраняет доступ уже зачисленным ученикам, если администратор явно не принял иное решение.
• CRS-11. Удаление опубликованного или купленного курса физически не допускается; используется архивирование.
• CRS-12. Категории и теги управляются администратором и позволяют добавлять смежные тематики без изменения программного кода.
• CRS-13. Для курса с потоком задаются даты начала и окончания, предельное число участников и расписание событий. Автоматический набор нескольких повторяющихся потоков относится к P1.
• CRS-14. Прогресс ученика сохраняется по урокам и заданиям и отображается в процентах.

11. Тесты, задания и проверка прохождения

11.1. Автоматические тесты

В MVP поддерживаются:

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

11.2. Задания с ручной проверкой

Ученик может:

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

Статусы: Не отправлено → На проверке → Принято / Требует доработки / Не принято.

11.3. Требования

• ASM-01. Преподаватель добавляет тест или открытое задание к уроку.
• ASM-02. Для каждого автоматически проверяемого вопроса задаётся правильный ответ.
• ASM-03. Система рассчитывает результат теста и применяет установленный проходной порог.
• ASM-04. Преподаватель видит очередь работ только по своим курсам и фильтрует её по курсу, потоку, статусу и сроку.
• ASM-05. Решение преподавателя и комментарий сохраняются в истории задания и отправляются ученику.
• ASM-06. Если задание является обязательным, следующий модуль или урок не открывается до положительного результата.
• ASM-07. Все попытки теста и версии отправленной работы сохраняются; преподаватель и ученик видят относящуюся к ним историю.
• ASM-08. Администратор может просматривать спорное задание и историю проверки для поддержки и модерации.
• ASM-09. Массовый импорт вопросов, банк вопросов, случайная выборка и сложные типы вопросов относятся к P1.

12. Каталог, поиск и публичные страницы

• CAT-01. Публичный каталог показывает опубликованные курсы.
• CAT-02. Доступны поиск по названию и описанию, фильтры по категории, формату, цене и преподавателю, а также сортировка по новизне и популярности.
• CAT-03. Карточка курса показывает описание, программу, преподавателя, формат, даты, стоимость, требования, объём материалов, наличие заданий и обратной связи, рейтинг и отзывы при их наличии.
• CAT-04. Публичный профиль преподавателя показывает одобренные публичные данные и опубликованные курсы.
• CAT-05. Администратор может закреплять и вручную ранжировать избранные курсы на главной странице.
• CAT-06. Страница курса содержит уникальную ссылку и стандартные метаданные для поисковых систем и социальных сетей.
• CAT-07. Кнопка «Поделиться» копирует ссылку и, при наличии поддержки устройства, открывает системное меню публикации.
• CAT-08. Нельзя показывать в каталоге черновики, неодобренные, скрытые и архивные курсы.

13. Покупка, зачисление и прохождение курса

13.1. Требования к покупке

• ORD-01. Ученик выбирает курс, авторизуется, принимает условия покупки и переходит к оплате.
• ORD-02. В MVP используется один платёжный провайдер, одна валюта и одно юридическое лицо-получатель.
• ORD-03. Бесплатный курс создаёт зачисление без платёжной операции.
• ORD-04. Платный доступ создаётся только после достоверного подтверждения успешной оплаты от платёжного провайдера.
• ORD-05. Повторное уведомление провайдера не должно создавать дублирующий заказ или двойное зачисление.
• ORD-06. Статусы заказа: Создан → Ожидает оплаты → Оплачен → Возвращён частично / Возвращён полностью / Оспорен / Отменён.
• ORD-07. Ученик видит историю покупок и состояние доступа.
• ORD-08. Администратор может выдать или отозвать зачисление вручную с обязательной причиной и записью в аудите.
• ORD-09. Возврат инициируется уполномоченным сотрудником через провайдера или его кабинет и фиксируется в платформе. Доступ изменяется согласно принятой политике возвратов.

13.2. Кабинет ученика

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

13.3. Учебный интерфейс

• LRN-01. Ученик видит только доступные ему курсы и уроки.
• LRN-02. Плеер курса показывает структуру, текущий урок и прогресс.
• LRN-03. Система запоминает последнее место и позволяет продолжить обучение.
• LRN-04. Закрытый обязательной последовательностью урок нельзя открыть прямой ссылкой.
• LRN-05. Истечение срока доступа блокирует новые просмотры, но не удаляет историю обучения и операций.
• LRN-06. Преподаватель видит список зачисленных учеников и их агрегированный прогресс, но не видит покупки и персональные данные пользователей вне своих курсов.

14. Коммуникации, объявления и вебинары

14.1. Коммуникации в MVP

MVP не реализует универсальный мессенджер. Он включает три контролируемых канала:

1. обсуждение или комментарии внутри урока для зачисленных учеников;
2. закрытый диалог ученика и преподавателя в контексте отправленного задания;
3. объявления преподавателя всем ученикам конкретного курса или потока.

14.2. Требования

• COM-01. Преподаватель может включить или отключить обсуждения для курса или урока.
• COM-02. Ученик и преподаватель могут добавлять комментарии; автор может исправить свой комментарий в течение заданного периода, при этом модерационная история сохраняется.
• COM-03. Ученик может сообщить о нарушении. Модератор может скрыть сообщение и зафиксировать причину.
• COM-04. Преподаватель создаёт объявление для учеников своего курса; оно отображается в кабинете и отправляется по электронной почте с учётом допустимых настроек коммуникаций.
• COM-05. Для живого события преподаватель указывает название, дату, время, часовой пояс, описание и ссылку внешнего сервиса.
• COM-06. Платформа показывает ближайшие события и отправляет напоминания по настраиваемому расписанию.
• COM-07. Доступ к ссылке события получают только зачисленные ученики соответствующего курса или потока.
• COM-08. Запись вебинара после проведения может быть добавлена в урок как видео или разрешённая внешняя ссылка.

На старте достаточно ссылочной интеграции с одним или несколькими сервисами, например Zoom или Яндекс Телемост. Создание встреч через API, синхронизация участников и посещаемость относятся к P1. Одностороннее или групповое видео и чат обеспечиваются выбранным внешним сервисом.

15. Медиа, файлы и лимиты хранения

15.1. Принципы

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

15.2. Требования

• MED-01. Администратор задаёт базовый лимит хранения и при необходимости индивидуальный лимит преподавателя.
• MED-02. Преподаватель видит использованный и доступный объём.
• MED-03. При достижении 80% лимита система показывает предупреждение и отправляет уведомление.
• MED-04. При достижении 100% новые загрузки блокируются, но ранее опубликованные и купленные материалы остаются доступны.
• MED-05. Администратор может временно увеличить лимит, зафиксировав основание и срок.
• MED-06. Удаление файла из черновика освобождает объём после безопасного периода. Файл, используемый опубликованным и купленным курсом, нельзя физически удалить без процедуры замены или архивирования.
• MED-07. Загрузка поддерживает прогресс, повтор после разрыва соединения и проверку разрешённого типа и размера.
• MED-08. Загружаемые документы проверяются на вредоносное содержимое доступным антивирусным механизмом.
• MED-09. Приватные материалы выдаются по ограниченным во времени подписанным ссылкам или эквивалентному механизму.
• MED-10. Автоматическая продажа дополнительного хранилища, тарификация трафика и пакеты хранения относятся к P1. В MVP увеличение лимита оформляется вручную.

16. Рейтинги, отзывы и распространение

• REV-01. Отзыв может оставить только зачисленный ученик после достижения установленного порога прогресса или завершения курса.
• REV-02. Отзыв включает оценку по пятибалльной шкале и необязательный текст.
• REV-03. Один ученик оставляет один актуальный отзыв на курс; редактирование сохраняет историю.
• REV-04. Преподаватель не может удалить отзыв, но может отправить жалобу и публично ответить, если ответы включены администратором.
• REV-05. Модератор скрывает отзыв только по правилам платформы с обязательной причиной.
• REV-06. Рейтинг курса рассчитывается по опубликованным отзывам подтверждённых учеников.
• REV-07. Отдельный агрегированный рейтинг преподавателя, сложное взвешивание оценок и антифрод-модель относятся к P1.

17. Финансовый учёт и выплаты преподавателям

17.1. Принцип MVP

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

17.2. Настройки

• базовая комиссия платформы;
• индивидуальная комиссия преподавателя или курса;
• период удержания начисления до доступности выплаты;
• минимальная сумма заявки на выплату;
• правила учёта комиссии платёжного провайдера и возвратов.

17.3. Расчётные компоненты

Для каждой продажи отдельно фиксируются:

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

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

17.4. Требования

• FIN-01. Каждая подтверждённая продажа формирует неизменяемые записи финансового реестра.
• FIN-02. Ставка комиссии и версия формулы сохраняются в снимке операции.
• FIN-03. Возврат формирует обратные или корректирующие записи, но не удаляет исходную продажу.
• FIN-04. Реестр поддерживает отрицательный баланс преподавателя после возвратов или споров; порядок его погашения определяется правилами платформы.
• FIN-05. Преподаватель видит только свои продажи, начислено, в резерве, доступно, выплачено и корректировки.
• FIN-06. Преподаватель подаёт заявку на выплату при выполнении заданных условий.
• FIN-07. Статусы заявки: Создана → На проверке → Одобрена → Выплачена / Отклонена / Отменена.
• FIN-08. Финансовый сотрудник фиксирует дату, сумму, способ и внешний идентификатор выполненной выплаты; редактирование после подтверждения заменяется корректирующей операцией.
• FIN-09. Администратор выгружает продажи, возвраты, начисления и выплаты в CSV.
• FIN-10. Система сверяет итоговые суммы заказа, реестра и выплаты и показывает несоответствия.
• FIN-11. Источник продажи — собственная ссылка преподавателя, каталог платформы или административная продажа — должен сохраняться как аналитический атрибут. Разные комиссии по источнику относятся к P1.
• FIN-12. Автоматические выплаты, split-платежи, соавторы, налоги и несколько валют относятся к P1/P2 после отдельного проектирования.

18. Административная панель

Административная панель должна включать:

18.1. Главная панель

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

18.2. Пользователи и роли

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

18.3. Модерация

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

18.4. Контент и справочники

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

18.5. Коммуникации

• отправка сервисных сообщений выбранным группам;
• объявления всей платформы;
• шаблоны транзакционных писем;
• журнал отправок и ошибок доставки.

Полноценный визуальный редактор маркетинговых цепочек и сложная CRM относятся к P1/P2.

19. Уведомления

В MVP обязательны электронная почта и центр уведомлений в личном кабинете.

События:

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

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

20. Аналитика MVP

20.1. Для преподавателя

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

20.2. Для администратора

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

20.3. События

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

Продвинутая BI-система, когортный анализ, рекомендации и атрибуция маркетинга относятся к P1.

21. Информационная архитектура и основные экраны

21.1. Публичная часть

1. Главная страница.
2. Каталог и результаты поиска.
3. Страница категории.
4. Карточка курса.
5. Профиль преподавателя.
6. Вход, регистрация и восстановление доступа.
7. Оформление и результат оплаты.
8. Статические страницы правил, поддержки и обработки данных.

21.2. Кабинет ученика

1. Мои курсы.
2. Учебный плеер.
3. Тест или отправка задания.
4. События и объявления.
5. Уведомления.
6. Покупки.
7. Профиль и настройки.

21.3. Кабинет преподавателя

1. Сводка.
2. Анкета и публичный профиль.
3. Мои курсы.
4. Конструктор курса.
5. Предварительный просмотр.
6. Ученики и прогресс.
7. Очередь заданий.
8. Объявления и события.
9. Продажи, начисления и выплаты.
10. Хранилище и лимиты.
11. Настройки.

21.4. Административная часть

1. Сводка.
2. Пользователи и роли.
3. Заявки преподавателей.
4. Модерация курсов.
5. Каталог, категории и теги.
6. Заказы и возвраты.
7. Начисления и выплаты.
8. Жалобы, комментарии и отзывы.
9. Хранилище и лимиты.
10. Рассылки и шаблоны.
11. Отчёты и экспорт.
12. Настройки и аудит.

22. Основные сквозные сценарии и критерии приёмки

Сценарий A. Подключение преподавателя

1. Пользователь регистрируется и подтверждает почту.
2. Заполняет анкету преподавателя и отправляет её.
3. Модератор возвращает заявку с замечанием.
4. Пользователь исправляет анкету и отправляет повторно.
5. Модератор одобряет заявку.

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

Сценарий B. Создание и публикация курса

1. Одобренный преподаватель создаёт курс из двух модулей.
2. Добавляет текст, PDF, видео, автоматический тест и задание с файлом.
3. Настраивает обязательную последовательность и бесплатный ознакомительный урок.
4. Просматривает курс от имени ученика и отправляет на модерацию.
5. Модератор одобряет курс, после чего он публикуется в каталоге.

Приёмка: порядок материалов сохранён; черновик недоступен постороннему пользователю; бесплатный урок открывается посетителю; остальные уроки доступны только зачисленному ученику; курс нельзя опубликовать без одобрения.

Сценарий C. Покупка и доступ

1. Ученик выбирает платный курс и оплачивает его.
2. Платёжный провайдер отправляет подтверждение дважды.
3. Система создаёт один заказ и одно зачисление.
4. Ученик видит курс в кабинете и начинает обучение.

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

Сценарий D. Тест и ручная проверка

1. Ученик не проходит обязательный тест — следующий урок остаётся закрытым.
2. Ученик проходит повторную попытку успешно.
3. Отправляет открытое задание файлом.
4. Преподаватель возвращает его на доработку с комментарием.
5. Ученик отправляет новую версию, преподаватель принимает её.

Приёмка: все попытки и версии сохранены; стороны получают уведомления; доступ к следующему материалу открывается только после выполнения заданных условий.

Сценарий E. Вебинар

1. Преподаватель создаёт событие со ссылкой внешнего сервиса.
2. Зачисленные ученики видят событие и получают напоминание.
3. Незачисленный пользователь не получает ссылку через интерфейс платформы.
4. После события преподаватель добавляет запись в урок.

Приёмка: время корректно отображается с указанием часового пояса; уведомления не дублируются; права на событие соответствуют зачислению.

Сценарий F. Возврат и расчёт с преподавателем

1. После продажи система фиксирует валовую сумму, комиссию и долю преподавателя в резерве.
2. По истечении периода удержания сумма становится доступной к выплате.
3. По одной продаже оформляется возврат.
4. Преподаватель создаёт заявку на оставшуюся доступную сумму.
5. Финансовый сотрудник выполняет платёж вне системы и отмечает заявку как выплаченную.

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

Сценарий G. Лимит хранилища

1. Использование преподавателя превышает 80% — появляется предупреждение.
2. При достижении 100% новая загрузка блокируется.
3. Уже опубликованные материалы продолжают воспроизводиться.
4. Администратор увеличивает лимит, после чего загрузка снова доступна.

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

Сценарий H. Изоляция данных

1. Преподаватель A пытается открыть прямую ссылку на курс, учеников, задания или отчёт преподавателя B.
2. Ученик пытается открыть неоплаченный закрытый урок.

Приёмка: сервер возвращает отказ без раскрытия защищённых данных; попытка доступа к критичному объекту регистрируется согласно политике безопасности.

23. Основные сущности данных

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

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

24. Интеграции

Для MVP выбирается по одному основному провайдеру каждого типа:

1. платёжный провайдер — оплата, подтверждение и возвраты;
2. объектное хранилище и CDN;
3. видеохостинг или сервис обработки и защищённой доставки видео;
4. сервис транзакционной электронной почты;
5. внешний сервис вебинаров на уровне защищённых ссылок;
6. система мониторинга ошибок и доступности;
7. продуктовая аналитика, если она не реализуется внутренними событиями.

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

25. Архитектурные требования

25.1. Рекомендуемый подход

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

Логические модули:

• идентификация и права;
• преподаватели и модерация;
• каталог;
• конструктор и учебный процесс;
• тесты и задания;
• коммуникации;
• заказы и платежи;
• финансовый реестр;
• медиа и лимиты;
• уведомления;
• аналитика;
• администрирование и аудит.

25.2. Требования к изменяемости

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

25.3. Варианты технологической реализации

Выбор реализации не меняет бизнес-требования этого документа, но влияет на объём допустимых компромиссов MVP.

26. Нефункциональные требования

26.1. Производительность и масштабирование

• основные HTML-страницы должны становиться интерактивными не более чем за 2,5 секунды на типовом мобильном соединении при нормальной нагрузке, без учёта загрузки большого медиа;
• серверные операции интерфейса без длительных фоновых задач должны отвечать не более чем за 1 секунду на 95-м процентиле при расчётной нагрузке;
• видео и крупные файлы обслуживаются через CDN/специализированного провайдера;
• для нагрузочного теста MVP принимается начальный профиль: 100 одобренных преподавателей, 10 000 зарегистрированных пользователей и 500 одновременных сессий без учёта внешнего вебинара. Профиль уточняется перед оценкой инфраструктуры;
• система должна масштабировать веб-приложение и фоновые обработчики без изменения функциональной логики.

26.2. Доступность и восстановление

• целевая доступность MVP — 99,5% в месяц, исключая согласованные работы и внешние сервисы;
• резервное копирование базы — не реже одного раза в сутки;
• рекомендуемые цели: RPO не более 24 часов, RTO не более 8 часов;
• восстановление из резервной копии проверяется до пилотного запуска и затем по регламенту;
• критические внешние уведомления обрабатываются идемпотентно и могут быть повторены.

26.3. Безопасность

• только HTTPS;
• безопасное хеширование паролей;
• защита от распространённых веб-уязвимостей по актуальной методологии OWASP;
• проверка прав на каждый защищённый объект;
• ограничение частоты входов, платежных уведомлений, комментариев и загрузок;
• двухфакторная аутентификация привилегированных ролей;
• шифрование чувствительных реквизитов при хранении либо хранение у специализированного провайдера;
• секреты не хранятся в исходном коде;
• подписанные ссылки для приватных материалов;
• антивирусная проверка документов;
• журналирование входов и критичных административных/финансовых действий;
• регулярное обновление зависимостей и проверка резервных сценариев;
• отдельная проверка безопасности до запуска реальных платежей.

26.4. Персональные данные

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

26.5. Совместимость и удобство

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

26.6. Наблюдаемость

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

27. Рекомендуемая очередность реализации

Этап 0. Предпроектные решения

• юрисдикция, валюта, продавец и отношения с преподавателем;
• провайдер платежей и возвратов;
• формула комиссии и период удержания;
• политика контента, модерации и возвратов;
• провайдер видео/хранилища;
• решение: операционный SaaS-пилот, Tutor LMS или собственная разработка;
• прототип ключевых экранов и проверка с 5–10 потенциальными преподавателями.

Этап 1. Основа и marketplace

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

Этап 2. Обучение

• учебный плеер и прогресс;
• тесты и задания;
• комментарии, объявления и внешние вебинары;
• медиа и лимиты.

Этап 3. Коммерция

• заказы, платежи и зачисления;
• возвраты;
• финансовый реестр;
• заявки на выплату и ручная фиксация;
• базовые отчёты.

Этап 4. Пилот и стабилизация

• сквозное и нагрузочное тестирование;
• проверка безопасности и восстановления;
• обучение администраторов;
• закрытый пилот;
• исправления и решение о публичном запуске.

28. Ориентировочная оценка сроков

Это предварительная оценка порядка величины для одной полноценной продуктовой команды после принятия решений этапа 0:

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

29. Рекомендуемые критерии успешности закрытого пилота

Целевые значения необходимо утвердить с владельцем продукта. Для первого пилота рекомендуется измерить:

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

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

30. Условия готовности MVP

MVP готов к закрытому пилоту, если:

1. реализованы все требования P0 либо для каждого исключения письменно согласован безопасный ручной процесс;
2. пройдены сквозные сценарии раздела 22;
3. права доступа протестированы для всех ролей;
4. платёжные уведомления, повторы, возвраты и финансовый реестр проверены на тестовых и контрольных операциях;
5. выполнены резервное копирование и пробное восстановление;
6. устранены критические и высокорисковые дефекты безопасности;
7. утверждены правила преподавателя, контента, возвратов, приватности и поддержки;
8. настроены мониторинг и ответственные за инциденты;
9. администратор, модератор и финансовый сотрудник прошли контрольные сценарии;
10. подготовлен список пилотных преподавателей и курсов, а также канал поддержки пользователей.

31. Функции следующего этапа

P1

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

P2

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

32. Решения, которые заказчик должен утвердить до детальной оценки

1. Страна работы, валюта и юридическое лицо, принимающее оплату.
2. Юридическая модель отношений с преподавателем и порядок выплат.
3. Платёжный провайдер, онлайн-чеки и процедура возврата.
4. Формула комиссии: от цены, от фактически полученной суммы или после комиссии провайдера.
5. Период удержания начислений и минимальная сумма выплаты.
6. Срок доступа к купленному курсу.
7. Допустимые направления и запрещённые темы/обещания в сфере психологии и здоровья.
8. Проверяется ли образование преподавателя и что означает отметка «проверено».
9. Кто и за какой срок модерирует профиль, курс, жалобу и отзыв.
10. Разрешены ли ученикам публичные комментарии или только диалог по заданиям.
11. Нужны ли курсы с датами и потоками уже в первом пилоте.
12. Какой видео- и вебинарный провайдер допустим по цене, защите и географии.
13. Базовый лимит преподавателя, максимальный файл и политика превышения.
14. Нужна ли самостоятельная регистрация преподавателей в открытом доступе или только по приглашениям на пилоте.
15. Выбранный путь реализации: SaaS-пилот, Tutor LMS или собственная разработка.

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