Разработка отчёта Moodle под ваш регламент

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

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

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

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