Как выбрать разработчика для Moodle: 10 вопросов перед договором

Почему выбор подрядчика — критичное решение

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

10 вопросов перед заключением договора

1. Сколько лет работаете с Moodle? Ответ «год» или «только PHP» — тревожный сигнал.
2. Есть ли опыт с российскими интеграциями? (1С, ЕСИА, СМЭВ)
3. Покажите примеры плагинов в официальном репозитории Moodle.org?
4. Соблюдаете Moodle Coding Style? Это гарантия поддерживаемости кода.
5. Как оформляются права на разработанный код? Должно быть прописано в договоре.
6. Есть ли опыт с вашим типом учреждения? (школа, СПО, вуз — разная специфика)
7. Работаете по договору с закрывающими документами?
8. Есть ли гарантийный период после сдачи?
9. Как выглядит техническое задание? Детальное ТЗ = меньше споров.
10. Кто ваш технический контакт в случае критической проблемы?

Красные флаги

• Нет договора или договор на 1 страницу
• Цена в 3 раза ниже рынка без объяснений
• Нет примеров реального кода или кейсов
• Обещает сделать «за неделю» сложную интеграцию

Работаю официально по ИП, предоставляю ТЗ, договор и закрывающие документы. Обсудим ваш проект.

Сравниваем форматы: интегратор, фрилансер, специалист

Проверка за 15 минут: что спросить и что должно насторожить

• «Покажите работающие внедрения» — не скриншоты, а адреса живых систем. У серьёзного исполнителя они есть и открываются.
• «Кто будет писать код?» — если отвечает менеджер и уходит уточнять, вы будете играть в испорченный телефон весь проект.
• «Что будет при обновлении Moodle с вашими доработками?» — правильный ответ содержит слова «стандарты API», «отдельный плагин, не правки ядра». Правки ядра — мина замедленного действия: система становится необновляемой.
• «У кого останутся доступы?» — все пароли (сервер, база, админка) должны быть у организации с первого дня.
• «Как вы тестируете?» — должен существовать тестовый контур, а не «правим сразу на проде».

Что зафиксировать в договоре

1. Техническое задание приложением — с перечнем функций, интеграций и критериями приёмки. «Внедрение Moodle» без расшифровки — не предмет договора, а поле для споров.
2. Этапы и сроки с приёмкой по каждому этапу.
3. Гарантийный срок на исправление дефектов (нормально — 30–90 дней после приёмки).
4. Передача исходников кастомных плагинов и документации.
5. Порядок расторжения и передачи дел — на случай, если что-то пойдёт не так.

Частые вопросы о выборе исполнителя

Обязателен ли подрядчик из нашего города?

Нет. Вся работа по Moodle делается удалённо: сервер, настройка, интеграции, обучение по видеосвязи. География исполнителя не влияет ни на что, кроме, возможно, часового пояса.

Как проверить компетентность, если у нас нет своих ИТ-специалистов?

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

Что делать, если предыдущий подрядчик пропал с доступами?

Ситуация решаемая: доступ восстанавливается через хостинг-провайдера (вы же владелец договора на сервер), дальше — смена всех паролей и аудит, что успели наделать. Прихожу в такие проекты регулярно.

Нормально ли, что исполнитель отказывается называть точную цену сразу?

Да, это признак опыта: честная точная цена возможна только после ТЗ или аудита. Насторожить должна как раз мгновенная «точная» цена без единого вопроса о ваших задачах.

Один специалист — не рискованно ли для большой организации?

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