Техзадание на внедрение Moodle: готовая структура для договора и закупки

Почему проекты СДО проваливаются на бумаге

Провальные внедрения, которые я разбирала как «скорая помощь», объединяет одно: ТЗ на полстраницы со словами «установить и настроить систему дистанционного обучения». Под такой формулировкой можно сдать что угодно — и принять что угодно. Потом полгода взаимных претензий. Ниже — структура ТЗ, которая защищает и заказчика, и добросовестного исполнителя.

Структура ТЗ из 8 разделов

Формулировки, которые погубят проект

• «Современный удобный интерфейс» — непроверяемо. Замените на конкретику: адаптивность под смартфоны, фирменные цвета, конкретные блоки на главной.
• «Все необходимые интеграции» — у каждой стороны свой список «необходимого». Перечисляйте поимённо, с направлением данных.
• «Перенос существующих материалов» — сколько курсов? с оценками или без? Объём переноса — самая частая зона конфликта.
• «Неограниченная поддержка» — не бывает; будет либо скрытая наценка, либо конфликт. Честнее: часы в месяц и время реакции, как в нормальном SLA.

Особенности закупок по 44-ФЗ и 223-ФЗ

Для бюджетной закупки ТЗ — часть документации, и его качество определяет, кто придёт на тендер. Слишком общее ТЗ приводит демпингующих универсалов, которые узнают слово «Moodle» на проекте. Излишне зарегулированное — отпугивает нормальных исполнителей. Рабочий баланс: жёстко фиксировать результат и критерии приёмки, не навязывая способ исполнения. И обязательно закладывайте этапность с приёмкой каждого этапа — это дисциплинирует всех. Я работаю как ИП по договору и участвую в закупках — если вы готовите закупку СДО, напишите: помогу собрать реалистичное ТЗ и смету до публикации, это бесплатно и ни к чему не обязывает.

Проверьте себя перед подписанием

1. Каждое требование можно проверить на приёмке конкретным действием.
2. Указаны объёмы: пользователи, курсы, объём переноса.
3. Интеграции перечислены поимённо, с направлением потоков данных.
4. Есть этапы, сроки и порядок приёмки каждого этапа.
5. Зафиксирована передача исходников, доступов и документации.
6. Есть гарантийный срок и понятная схема поддержки после запуска.

Дополнительно пригодится чек-лист приёмки внедрения — по нему удобно принимать работу, даже если внедряли не у меня. А о том, как выбрать самого исполнителя, — статья о 10 вопросах перед договором.

Пример: два ТЗ на один и тот же проект

Почувствуйте разницу на живом примере — колледж, 1 500 студентов, нужна СДО с нуля.

ТЗ, которое приводит к конфликту: «Исполнитель обязуется установить и настроить систему дистанционного обучения Moodle, наполнить её курсами, обучить сотрудников и обеспечить бесперебойную работу». Четыре пункта — четыре мины: «настроить» (что именно?), «наполнить» (сколько курсов и кто даёт материалы?), «обучить» (скольких и в каком формате?), «бесперебойную» (кто оплачивает сервер и что считается перебоем?).

Та же суть, но проверяемо: «Установка Moodle актуальной LTS-версии на сервер заказчика; настройка 5 ролей согласно приложению 2; создание структуры из 42 категорий по учебным планам; шаблон курса и перенос 30 пилотных курсов из материалов заказчика (Word/PDF/видео); два практикума по 4 часа для 40 преподавателей с видеозаписью; инструкции администратора, преподавателя и студента; критерии приёмки — приложение 3». Объём работы тот же — конфликтов нет, потому что обеим сторонам заранее понятно, что такое «готово».

Частая ошибка: ТЗ пишут про технику и забывают про людей

В провальных проектах техника обычно как раз работает — не работают процессы вокруг неё. Поэтому в хорошем ТЗ всегда есть три «нетехнических» блока. Первый — ответственные со стороны заказчика: кто предоставляет материалы курсов, кто отвечает на вопросы по учебным планам, кто принимает этапы (без этого исполнитель месяцами ждёт ответов, а сроки горят). Второй — обучение с измеримым результатом: не «провести обучение», а «после практикума преподаватель самостоятельно создаёт курс с тестом» — и это проверяется на приёмке. Третий — что происходит после запуска: первые недели эксплуатации всегда порождают вал вопросов, и лучше заранее договориться, входит ли месяц сопровождения в проект или начинается отдельная поддержка. Эти три блока занимают полстраницы, а спасают проекты чаще, чем все технические разделы вместе взятые.

Частые вопросы

Можно ли взять готовое ТЗ на Moodle из интернета?

Как основу структуры — да, как готовый документ — нет: чужое ТЗ описывает чужие процессы. Скопированные требования либо оплачивают ненужное, либо упускают критичное для вашей организации.

Кто должен писать ТЗ — заказчик или исполнитель?

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

Что обязательно включить в ТЗ для закупки по 44-ФЗ?

Измеримые требования и критерии приёмки: конкретные функции, интеграции, объёмы переноса данных, сроки этапов, требования к документации и обучению, гарантийный срок. Формулировки «современная удобная система» непроверяемы и опасны для обеих сторон.

Как в ТЗ учесть будущие доработки?

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

Сколько времени занимает подготовка ТЗ?

При наличии обследования — одна-две недели вместе с согласованием. Экономить на этом этапе не стоит: час работы над ТЗ экономит день споров при приёмке.