---
type: plan
title: Техническое задание на MVP платформы обучающих курсов
description: Требования к управляемому marketplace независимых авторов курсов по психологии и смежным темам.
status: draft
canonical: true
last_verified: 2026-08-06
tags: [mvp, marketplace, lms, courses, psychology]
---

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

**Рабочее название:** Платформа независимых авторов курсов по психологии и смежным темам<br>
**Версия:** 0.1<br>
**Статус:** концептуальное ТЗ для обсуждения, оценки и декомпозиции<br>
**Дата:** 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. Пользовательские роли

| Роль | Основные права в MVP |
|---|---|
| Посетитель | Просмотр каталога, карточек курсов и публичных профилей преподавателей |
| Ученик | Покупка и прохождение курсов, выполнение заданий, комментарии, получение уведомлений, публикация отзыва |
| Преподаватель | Управление своим профилем и своими курсами, просмотр своих учеников, проверка заданий, объявления, просмотр начислений и использования хранилища |
| Модератор | Проверка профилей и курсов, запрос исправлений, скрытие нарушающего контента |
| Финансовый сотрудник | Просмотр заказов, возвратов, начислений и заявок на выплату; фиксация выполненных выплат |
| Администратор | Полный доступ к пользователям, ролям, контенту, настройкам, справочникам, лимитам, отчётам и журналу действий |

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

## 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. Варианты технологической реализации

| Вариант | Когда использовать | Компромисс |
|---|---|---|
| GetCourse/CoreApp как операционный пилот | Нужно быстро проверить спрос с высокой долей ручных операций | Ограниченная автономность преподавателей и marketplace-финансы; это проверка модели, а не целевая архитектура |
| Tutor LMS Pro с доработками | Нужен собственный брендированный marketplace при умеренном бюджете | Потребуются российские платежи, отдельный финансовый реестр, безопасность, тестирование обновлений и собственная эксплуатация |
| Собственная модульная платформа | Подтверждена экономика и важны контроль, масштабирование и уникальные процессы | Самый долгий и дорогой путь; не рекомендуется начинать с полного объёма без пилота |

Выбор реализации не меняет бизнес-требования этого документа, но влияет на объём допустимых компромиссов 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:

| Реализация | Ориентир до закрытого пилота |
|---|---:|
| Настройка существующей SaaS-LMS с ручными обходными процессами | 6–10 недель |
| Tutor LMS Pro/WordPress с необходимыми доработками | 10–16 недель |
| Собственная модульная платформа | 20–32 недели |

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

## 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 или собственная разработка.

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