ТЗ на EdTech-платформу: чек-лист обязательных разделов и пунктов

Техническое задание — основа любого проекта. ТЗ на EdTech-платформу фиксирует требования бизнеса и пользователей, конкретные критерии успеха и позволяет оценить сроки и бюджет. А также защищает стороны от споров и «додумываний на ходу». Как грамотно составить техническое задание на разработку образовательной платформы? Рассказывает Илья Горбаров, CEO диджитал-агентства «Атвинта».

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

Что даёт грамотное ТЗ на EdTech-платформу

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

Стиль оформления ТЗ на EdTech-платформу

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

• Структурированность

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

• Единый стиль формулировок

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

• Разделение обязательных и рекомендованных требований

В ТЗ всегда выделяют, что является обязательным для запуска MVP, а что будет дополнительными возможностями, которые можно реализовать позже.

Стандарты оформления

• ГОСТы

Их используют для крупных и государственных EdTech-проектов, где нужна формализация и полное соответствие нормативам.

• ISO/IEC

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

• Agile-методологии

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

• Открытые EdTech-спецификации (xAPI, SCORM)

Обязательны, если проект предполагает интеграцию с внешними системами или экспорт образовательного контента.

Для корпоративных платформ и онлайн-школ используют смешанный подход.

В качестве основы берут ГОСТ или ISO, адаптируют требования под реальные задачи, добавляют примеры сценариев и ссылки на макеты интерфейсов. Это позволяет оперативно подключать новых участников в проект и минимизировать риски ошибок на этапе запуска.

Общие сведения о проекте

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

• Название платформы

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

• Стороны и контакты

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

• Основания для запуска

Ссылки на договоры, приложения и внутренние решения, которые стали формальным стартом работ.

• Этапы и сроки

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

• Целевая аудитория

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

Цели и задачи платформы

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

• Бизнес-цели, которые будет решать платформа

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

• Основные задачи платформы

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

• Пользовательская ценность

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

• Привязка к образовательным задачам

Например, развитие компетенций, повышение квалификации или внедрение новых методик.

Глоссарий проекта

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

• Фиксация терминов

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

• Лаконичные определения

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

• Уточнения для специфики платформы

При необходимости добавляют пояснения того, как термин трактуется именно для вашей платформы.

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

Технические требования

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

• Стек технологий для создания продукта

Frontend (Vue.js, Angular), backend (PHP, Laravel), базы данных (PostgreSQL, MySQL) и другие ключевые компоненты. Также иногда фиксируют, какие языки программирования нельзя использовать по внутренним стандартам заказчика.

• Требования к инфраструктуре

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

• Безопасность и хранение информации

Меры защиты персональных данных, шифрование паролей, резервное копирование и соответствие законодательству тех стран, в которых будет запущена платформа.

• Требования к адаптивности кроссбраузерности

Описывают, для каких устройств и разрешений должен быть оптимизирован интерфейс: десктоп, планшет и мобильные телефоны. А также в каких браузерах поддерживается работа системы: Google Chrome, Safari, Яндекс Браузер, Firefox и другие.

Интеграции с внешними сервисами

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

• Перечень обязательных интеграций

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

• Описание форматов и протоколов для передачи данных по API
• Приоритеты подключения

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

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

Раздел помогает зафиксировать все роли пользователей и их доступы в системе.

• Список ролей

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

• Описание полномочий

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

Требования к интерфейсу

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

• Ссылки на прототипы и макеты

В ТЗ на EdTech-платформу добавляют ссылки на макеты в Figma или других сервисах. Это позволяет согласовать структуру будущего продукта до этапа разработки. Даже если финальный дизайн будет отличаться, на прототипах есть основные элементы навигации и размещение ключевых блоков.

• Ролевые сценарии интерфейса

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

• Доступность

Платформа должна соответствовать стандарту WCAG, чтобы быть удобной для людей с ограниченными возможностями.

Критерии приёмки и сдачи работ

Зафиксированные критерии принятия проекта минимизируют риски споров, задержек по срокам и размытых требований на финише. 

• Список обязательных функций и требований

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

• Работоспособность и тестирование

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

• Документация и обучающие материалы

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

• Требования к поддержке

Указывают формат работы с техподдержкой (e-mail, телефон, мессенджер, тикеты в системе), а также регламенты реагирования на инциденты и сроки устранения багов.

• Гарантийные условия

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

• Порядок передачи прав и доступов

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

Ошибки при составлении ТЗ на создание EdTech-платформ

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

Игнорирование отраслевых стандартов и лучших практик

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

Перед началом работ нужно проанализировать конкурентов и собрать примеры функционала EdTech-платформ, чтобы структурировать ТЗ под реальную задачу бизнеса.

Не все специалисты знают о существовании ГОСТов и международных стандартов ISO/IEC. В итоге требования выглядят размытыми и затрудняют работу команды. Необходимо изучить отраслевые и корпоративные стандарты оформления, чтобы понимать базовую структуру и избежать разночтений.

Механическое копирование требований и сценариев из чужих проектов

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

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

Недооценка масштабируемости и гибкости платформы

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

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

Недостаточное вовлечение ключевых пользователей и бизнес-заказчика

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

Организуйте интервью с представителями всех ролей ещё до начала написания ТЗ на EdTech-платформу и составьте CJM и Use Cases со всеми маршрутами и сценариями пользователей. Проработайте требования и пожелания всех заинтересованных сторон и добавьте ключевые инсайты в техническое задание.

Пренебрежение продуманной системой аналитики и мониторинга

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

Уже на этапе ТЗ важно прописать сценарии аналитики для всех ролей, предусматривать подключение BI-инструментов или создание встроенного функционала.

Отсутствие механизма сбора и обработки обратной связи

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

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

Чек-лист для самопроверки ТЗ на разработку образовательной платформы

1. Описаны ли цели платформы и их связь с бизнес-задачами?
2. Зафиксирован ли глоссарий терминов для команды?
3. Прописаны требования к интерфейсу для всех ролей?
4. Согласованы ли ключевые роли и пользовательские сценарии, включая нетиповые?
5. Учтены ли обязательные и будущие интеграции? Описаны ли API и форматы данных внешних интеграций?
6. Указаны ли параметры отказоустойчивости и производительности платформы?
7. Заложены ли требования к масштабируемости и развитию платформы?
8. Указаны ли форматы и состав передаваемой документации?
9. Описаны ли критерии приёмки и порядок сдачи работ?
10. Продуманы ли сценарии поддержки и обучения пользователей?
11. Зафиксирован ли механизм сбора обратной связи для улучшения продукта?
12. Соблюдён ли стандарт оформления ТЗ? Все требования структурированы, имеют однозначные формулировки и логическую последовательность?

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