Задание на SQL-отчёт должно описывать ожидаемые строки и показатели, а не только список таблиц. Разработчику нужны смысл периода, ключи связей, правила исключений и контрольные примеры с ручным результатом. Тогда приёмка проверяет бизнес-ответ, а не факт успешного выполнения запроса.
Сформулируйте вопрос отчёта
Начните с одного предложения: например, показать оплаченные обращения по источнику привлечения за месяц. Далее уточните, что считается обращением, оплатой и источником. Если эти слова допускают несколько толкований, SQL лишь закрепит случайный выбор исполнителя.
Укажите пользователя и действие после просмотра. Руководителю может требоваться агрегат по каналам, аналитику — расшифровка до операции, менеджеру — список карточек для исправления. Эти представления могут использовать общую модель, но имеют разные уровни детализации и права доступа.
Задайте зерно результата
Опишите, что означает одна строка: сделка, платёж, клиент или сочетание периода и источника. Перечислите уникальный ключ ожидаемой строки. Затем для каждой исходной таблицы укажите её собственное зерно и кратность соединения.
Если у сделки несколько платежей и задач, прямое соединение может умножить строки. В задании следует явно определить, какие дочерние данные агрегируются заранее. Не просите просто «убрать дубли»: это не объясняет, какие повторения ошибочны, а какие представляют реальные события.
Согласуйте время и выборку
Для каждого фильтра укажите поле даты, часовой пояс и границы периода. Дата создания сделки не равна дате оплаты, а дата загрузки не равна дате события. Открытые интервалы и текущий незавершённый месяц требуют отдельного обозначения.
Опишите обработку тестов, спама, возвратов и отсутствующих связей. Неизвестный источник обычно стоит показывать отдельной группой, а не удалять всю продажу. Пустая сумма и нулевая сумма должны различаться, если первая означает неполную загрузку.
Условное задание на оплаты
Предположим, нужны поступления по рекламному источнику за сентябрь. Одна строка результата — источник и валюта; детализация — платёж. Включаются подтверждённые операции сентября, независимо от месяца создания сделки. Возвраты показываются по отдельно согласованному правилу.
Контрольный набор содержит одну сделку с двумя оплатами, одну без оплаты и одну с неизвестным источником. Ручной итог фиксируют до написания запроса. Разработчик должен объяснить, почему в агрегате появились именно эти суммы и куда попала запись без рекламной маркировки.
Добавьте требования к эксплуатации
Укажите расписание, допустимую задержку, ожидаемый объём и место отображения ошибок. Если источник не загрузился, отчёт должен сообщать об этом, а не публиковать нулевой результат. Для повторного запуска согласуйте обработку поздних изменений и исправлений прошлых периодов.
Потребуйте описание зависимостей и владельца запроса. Комментарии должны объяснять нетривиальные бизнес-правила, а не пересказывать каждую строку SQL. Общую структуру договорённостей можно связать с техническим заданием на CRM, дополнив его конкретными аналитическими тестами.
Примите результат по доказательствам
Сверьте общий итог, число уникальных объектов и несколько крайних случаев. Проверьте, что добавление задачи не меняет оплату, одинаковые суммы разных платежей сохраняются, а отсутствие источника не уменьшает общий финансовый результат.
В передаваемые материалы включите запрос, описание входов, контрольную выборку и ожидаемые значения. Результат готов, когда другой специалист может повторить расчёт и объяснить расхождение на уровне строки. Такое задание снижает зависимость от устных пояснений и упрощает безопасное развитие отчёта при изменении CRM.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.