Сайт образовательной организации: разработка от карты сценариев до приёмки

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

Задача бизнеса и границы разработки сайта образовательной организации

Сайт образовательного проекта решает прикладные задачи: показать программы, объяснить условия поступления, принять заявку, дать актуальное расписание и сведения о преподавателях. Всё остальное — следствие. Если начать с оформления, легко получить красивый сайт, в котором нельзя быстро поменять расписание или понять, куда ушла заявка.

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

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

Роли в проекте стоит назвать сразу. Заказчик принимает решения по содержанию и бюджету. Руководитель проекта ведёт сроки и согласования. Контент-менеджер отвечает за тексты, расписание и карточки преподавателей. Разработчик собирает публичную часть и настраивает обновление данных. Администратор сайта управляет доступами и резервными копиями. Если роли не распределены, обновление расписания и заявок ложится на разработчика, а это замедляет и поддержку, и правки.

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

Полезно заранее решить, на какой платформе будет проект. Если планируется 1С-Битрикс, смотрят, как устроены шаблон сайта, включаемые области, меню и компоненты: от этого зависит, насколько просто контент-менеджеру менять блоки без разработчика. Здесь уместно заранее обсудить разработка сайтов на Битрикс как вариант, если команда уже работает с этой системой.

Карта сценариев поступающего: как её собрать до старта

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

Какие сценарии обязательно описать

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

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

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

Как связать сценарий с разделом сайта

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

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

Что фиксируем в карте

Рабочие столбцы карты:

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

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

Выбор программы и подача заявки

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

Страница программы

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

Страница должна быть устроена так, чтобы контент-менеджер мог обновить набор дисциплин, стоимость и даты без правки шаблона. На 1С-Битрикс это обычно решается через инфоблоки и шаблоны компонентов: данные хранятся отдельно от вёрстки. Если такой структуры нет, каждая правка превращается в задачу для разработчика.

Форма заявки

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

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

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

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

Развилки

Развилки в образовательном проекте встречаются часто, и каждая меняет структуру:

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

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

Обновление сведений о преподавателях и расписании

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

Кто отвечает и как часто

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

Структура данных

Данные стоит разделить, а не хранить одним текстовым блоком:

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

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

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

Права доступа настраивают по ролям: редактор контента, администратор раздела, администратор сайта. Редактор не должен менять структуру и настройки, а администратор — случайно удалять разделы. На 1С-Битрикс это решается штатными средствами разграничения доступа; конкретные роли и уровни согласуют с администратором сайта. Подробнее о том, как устроены доступы и настройки, можно посмотреть в материале про Администрирование сайта на Битрикс — доступы, данные и настройки.

Тестовый контур

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

Практический пример на тестовых данных

Учебный пример. Данные условные и не описывают реальный проект.

Входные условия. Образовательный проект «Пример» проводит три программы: «Основы анализа данных», «Управление проектами», «Деловая коммуникация». Двенадцать преподавателей, часть ведёт по две программы. Занятия идут в двух форматах: очно и дистанционно. Расписание на семестр меняется примерно раз в две недели. Заявки принимает администратор, ответственный за приём.

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

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

Шаг 3. Разделяем данные. Создаём три набора: программы, преподаватели, занятия. В карточке преподавателя указываем программы, в занятии — программу и преподавателя. Так при изменении расписания не нужно править страницы программ.

Шаг 4. Настраиваем форму заявки. Поля: имя, контакт, программа, формат, комментарий. После отправки человек видит подтверждение, заявка попадает администратору. Отдельно проверяем, что при недоступности почтового канала заявка не теряется: способ контроля выбирает администратор, например журнал отправок или дублирование во внутреннюю систему.

Шаг 5. Проверяем права. Редактор может менять расписание и карточки преподавателей, но не структуру разделов. Администратор управляет доступами и резервными копиями.

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

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

Как проверить результат и принять работу

Приёмка идёт по карте сценариев и по списку требований, согласованному до старта. Проверяют не «красиво или нет», а работает ли каждый сценарий.

Что проверяют

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

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

Кто принимает

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

Типичные ошибки и ограничения

Ошибки, которые чаще всего мешают:

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

Ограничения. Разработка сайта образовательной организации не заменяет юридическую проверку состава сведений и формулировок согласий: это задача профильного специалиста. Не заменяет она и внутренние регламенты приёма заявок. Технические ограничения зависят от выбранной платформы, хостинга и интеграций; их проверяют на тестовом контуре, а не на рабочем сайте. Обещать конкретные показатели по числу заявок или позиций в поисковой выдаче нельзя: результат зависит от программы, набора студентов и работы приёмной комиссии.

Какие исходные данные подготовить для оценки

Чтобы оценить проект, нужны:

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

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

Таблица принятия решения

Чек-лист перед стартом и приёмкой

• Карта сценариев поступающего собрана и согласована с приёмной комиссией
• Для каждого сценария указаны страница, данные и ответственный
• Определены программы, форматы, площадки и языковые версии
• Описан порядок обработки заявок и назначен ответственный
• Настроены роли: редактор, администратор раздела, администратор сайта
• Расписание и карточки преподавателей хранятся отдельно от вёрстки
• Есть тестовый контур для проверки правок
• Перед изменениями делается резервная копия и есть план возврата
• Состав обязательных сведений сверен с профильным специалистом
• Проведена проверка всех сценариев на тестовом сайте
• Заказчику переданы доступы и инструкция по обновлению данных