Онлайн-школа начинается не с найма десятка специалистов и не с записи всех уроков. Сначала предприниматель проверяет, для кого создаётся продукт, какую задачу ученика он помогает решить, как будет выглядеть первый учебный опыт и как команда получит обратную связь. Затем появляются роли. Если сначала собрать штат, а потом искать продукт, люди могут заняться разными полезными активностями без общего результата.
Статья описывает управленческие функции, а не обязательную кадровую схему. Она не устанавливает количество сотрудников, зарплаты, формат занятости, образовательную лицензию, условия договоров, авторские права, налоги, требования к рекламе или обещание продаж и завершения обучения. Для этих решений нужны факты конкретного проекта и профильные специалисты.
Соберите карту пути ученика
Начните с одного сценария: как человек узнаёт о программе, понимает, подходит ли она ему, принимает решение, получает доступ, проходит первый модуль, задаёт вопрос, выполняет практику и получает следующий шаг. Карта не должна быть идеальной. Её задача — увидеть, какие функции уже закрыты, а где ученик может потерять контекст, поддержку или результат.
| Этап пути ученика | Функция команды | Вопрос владельца |
|---|---|---|
| Выбор программы | Продукт, экспертность, маркетинг | Ясно ли, какую задачу и для кого решает продукт? |
| Первый опыт | Методический дизайн, контент, поддержка | Понимает ли ученик, что делать в первые дни и куда обратиться? |
| Практика и обратная связь | Эксперт, наставник или куратор, операционная роль | Есть ли понятный результат задания и маршрут вопроса? |
| Продолжение или завершение | Продукт, поддержка, данные | Какие факты помогут улучшить следующий поток? |
Шесть функций, которые нужно закрыть
1. Владелец продукта. Он отвечает за гипотезу: для кого программа, какой результат обещает, какие ограничения есть и по каким фактам решение о следующем запуске будет пересматриваться. Это не обязательно отдельная должность; на старте функцию часто берёт основатель или продюсер.
2. Экспертность и содержание. Эксперт помогает сформулировать предмет, примеры, практические задания и границы того, чему продукт не учит. Эксперт не обязан одновременно быть методистом, ведущим, монтажёром и продавцом — но команда должна понимать, какие из этих функций временно совмещены.
3. Методический дизайн. Эта функция превращает тему в путь обучения: исходную точку ученика, последовательность, задания, критерии понятного результата, формат обратной связи и способ проверить, где материал не работает. На старте она может быть минимальной, но без неё набор видео не становится программой.
4. Создание и доставка контента. Кто-то готовит материалы, редактирует, собирает уроки в среде, проверяет доступ и обновляет версию. Не обязательно строить студию: для первого потока достаточно выбрать формат, который команда способна стабильно поддерживать.
5. Привлечение, продажа и коммуникация. Функция помогает человеку понять ценность, задать вопрос и принять решение без ложных обещаний. Она передаёт в продукт обратную связь: какие ожидания возникают у потенциальных учеников, где оффер непонятен, почему люди не доходят до первого действия.
6. Поддержка и операционный контур. Это ответы на типовые вопросы, расписание, доступы, правила обращения, сбор обратной связи, учёт повторяющихся проблем и передача их владельцу продукта. Без этой функции эксперт и методист могут узнавать о проблемах ученика слишком поздно.
Минимальная команда для первого запуска
В маленьком запуске один человек может закрывать продукт, экспертность и часть маркетинга; второй — методический дизайн и операции; третий подключаться к контенту или поддержке по необходимости. Важен не титул, а прозрачность: кто принимает решение о программе, кто проверяет первый опыт ученика, кто отвечает за доступ, кто собирает вопросы и кто может изменить оффер.
Не ищите «идеального универсального сотрудника». Сначала выпишите функции, которые нельзя оставить без владельца в ближайшем потоке. Затем оцените, что уже есть внутри команды, что можно закрыть ограниченным подрядом, чему нужно научиться на простом формате и что не стоит обещать до появления компетенции.
Как понять, какую роль подключать следующей
- Посмотрите на карту пути ученика и выберите место с повторяющимся препятствием.
- Опишите проблему как факт: «ученики не понимают первое задание», «доступ выдаётся с задержкой», «вопросы о продукте повторяются».
- Определите функцию, а не должность: методический разбор, настройка доставки, поддержка, контент, коммуникация.
- Сформулируйте ожидаемый результат работы этой функции и границу полномочий.
- Выберите способ закрыть её: совмещение, временный подряд, новый участник или изменение процесса.
- После потока проведите review: препятствие исчезло, изменилось или оказалось описано неверно?
Роли, которые часто путают
Эксперт отвечает за предмет и профессиональную достоверность, но не обязательно за логику обучения. Методист помогает выстроить путь и практику, но не обязан продавать программу. Продюсер или владелец продукта связывает рынок, формат, ресурсы и решение о запуске, но не должен единолично знать ответы на каждый вопрос ученика. Куратор или поддержка держит контакт с потоком, но не заменяет эксперта в сложном предметном вопросе.
Развести роли можно даже в команде из двух человек. Например, один человек утверждает содержание и результат модуля, второй отвечает за то, как задание увидит ученик, где он задаст вопрос и как повторяющаяся проблема вернётся в улучшение программы. Такая ясность снижает количество личных договорённостей «на ходу».
Как собрать команду без преждевременного масштаба
Начните с одного продукта, одной аудитории и одного формата. Не записывайте весь годовой каталог до первых данных. Проведите ограниченный запуск, соберите наблюдения: где люди задают вопросы, на каком шаге задерживаются, как понимают обещание, какие части содержания нужно доработать, какие операции съедают больше времени. Затем расширяйте только ту функцию, которая стала ограничением.
Например, если эксперт не успевает отвечать на повторяющиеся вопросы, сначала можно создать базу ответов и маршрут эскалации, а не сразу нанимать большой отдел. Если ученики не завершают практику, нужно проверить постановку задания и поддержку, а не автоматически увеличивать рекламный бюджет. Команда растёт вокруг проверенных ограничений, а не вокруг образа «взрослой школы».
Как проводить review после потока
На review не спрашивайте только «понравился ли курс». Пройдите путь ученика по этапам: где ожидание не совпало с опытом; какие вопросы повторялись; что было понятно без помощи; где команда вручную закрывала пробел; какие решения затронут следующий запуск. Отделите факт от версии: если люди не дошли до задания, это может быть проблема доступа, времени, ожиданий, сложности, коммуникации или самого формата.
В конце оставьте короткий список: что сохранить, что изменить, что проверить до следующего набора, кто владелец каждого пункта и когда review. Так команда онлайн-школы становится не набором специалистов, а системой, которая учится на реальном пути ученика.
Границы статьи
Эта страница помогает распределить функции при запуске образовательного продукта. Она не определяет, нужна ли лицензия, как оформлять отношения с экспертами и учениками, какие права передаются на материалы, как хранить персональные данные, как обещать результат обучения или какую схему оплаты использовать. Перед значимым запуском проверьте эти вопросы по актуальным правилам и с компетентными специалистами.
Что отдать команде на первую неделю работы
Вместо абстрактного «запустим курс» соберите одну рабочую папку или страницу: описание аудитории и задачи ученика; обещание первой версии продукта; программа первого модуля; путь от заявки до доступа; список открытых вопросов; владельцы функций; дата первого review. Это не регламент на сотни страниц, а общий контекст, без которого дизайнер, эксперт, методист и маркетолог начнут создавать разные продукты.
На первой встрече не обязательно распределять весь год. Достаточно выбрать один результат ближайшего запуска: проверить спрос, провести пробный урок, собрать первый набор, подготовить доступ или разобрать первые вопросы учеников. У каждого результата должен быть владелец, критерий готовности и связь с путём ученика. Тогда команда может увидеть, где реальная работа упирается в функцию, а где — в неясное решение владельца продукта.
Признаки, что функцию пора отделять
Совмещение нормально, пока оно не создаёт повторяющийся риск. Отделять функцию стоит, когда эксперт перестаёт отвечать на содержательные вопросы из-за рутины доступа, поддержка не знает правил эскалации, материалы выходят без проверки пути ученика, маркетинг обещает то, чего программа не даёт, или владелец продукта не успевает проводить review. Это не автоматический повод нанимать в штат: сначала определите объём и результат роли, затем выберите подходящий способ закрытия.



