Техническое задание на дашборд: что описать до BI

Коротко

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

• Один дашборд — один основной сценарий или одна роль.
• Каждая метрика имеет формулу, owner и источник.
• Фильтры должны менять смысл результата предсказуемо.
• В ТЗ фиксируется, что считается готовым.
• Ссылки на raw data и методологию обязательнее декоративного mockup.

1. Цель и пользователь

Начни ТЗ с короткого ответа: кто открывает дашборд, в какой момент и какое решение принимает. “Для руководителя” слишком широко. Лучше: “Руководитель продаж каждое утро видит отклонение от плана, находит команду с провалом и назначает разбор причин”. Такая формулировка сразу подсказывает уровень агрегации, периодичность и нужный drill-down.

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

2. Метрики и их контракт

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

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

3. Фильтры, периоды и зерно

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

Зерно результата должно быть видно уже в ТЗ. Таблица “одна строка = день” и таблица “одна строка = заказ” не могут без подготовки показывать один и тот же KPI. Опиши drill-down: из месячного значения пользователь переходит в день, канал, менеджера или список конкретных объектов.

4. Источники и обновление

В ТЗ нужен список источников с конкретными таблицами или API, а не только название системы. Укажи ключи связей, ожидаемое количество строк, задержку, историческую глубину и владельца. Для каждого блока запиши, что произойдёт при неполном обновлении: показать предупреждение, скрыть KPI, использовать последний полный день или остановить публикацию.

Покажи на дашборде дату и время последнего успешного обновления. Если данные обновляются раз в сутки, не называй экран real-time. Честная подпись о свежести повышает доверие сильнее, чем маленький значок “live”.

• Источник и версия схемы.
• Время загрузки и ожидаемая задержка.
• Проверка полноты периода.
• Правило поведения при ошибке обновления.
• Контакт владельца источника.

5. Макет и поведение

Сначала опиши порядок вопросов на экране, потом выбирай вид графика. Верхний слой отвечает “что изменилось”, средний — “где именно”, нижний — “с какими объектами нужно работать”. Для каждого блока укажи подпись, единицы, формат числа, baseline и действие по клику.

Не обязательно прикладывать идеальный дизайн. Полезнее простой wireframe с приоритетом блоков и состояниями: загрузка, пустой результат, ошибка, недостаточно данных, доступ запрещён. Если в ТЗ нет этих состояний, они появятся случайно уже на проде.

6. Критерии приёмки

Приёмка должна проверять не только внешний вид. Сформулируй несколько сценариев с ожидаемым результатом: выбрать период, сравнить два канала, открыть drill-down, сверить KPI с контрольной таблицей, увидеть пустой день и проверить права доступа. Если значение допускает округление, зафиксируй допустимую погрешность.

Добавь контрольный срез с известным результатом. Приёмка становится объективной, когда у команды есть конкретные строки, период и ожидаемые числа. “Работает правильно” не является критерием, пока не написано, что именно должно совпасть.

• Все KPI совпадают с контрольным запросом на согласованном срезе.
• Фильтры не меняют несвязанные блоки неожиданно.
• Дата и часовой пояс отображаются корректно.
• Empty, error и stale states проверены отдельно.
• Права доступа протестированы обычным пользователем.
• Владелец подтвердил методологию и следующий процесс.

Готовая структура ТЗ

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