Техническое задание на дашборд: что описать до 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 проверены отдельно.
• Права доступа протестированы обычным пользователем.
• Владелец подтвердил методологию и следующий процесс.

Восемнадцать равных плиток не складываются в ответ: у экрана три уровня чтения

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

Наверху стоит один результат и база сравнения. Выручка месяца 12,4 млн рублей против плана 14,0 млн, отклонение −11%. Одно число, один период, одна подпись о том, с чем сравниваем. Если на верхнем уровне оказались три равноправных показателя, встреча начинается не с разбора, а с выбора, какой из них сегодня обсуждать, и выбирают обычно тот, где цифра приятнее.

Второй уровень обязан объяснять первый арифметически, а не тематически. Выручка здесь разбирается на 96 сделок со средним чеком 129 000 рублей, план складывался из 105 сделок по 133 000. Отсюда и вклад каждой половины: недостающие 9 сделок по плановому чеку — это −1,2 млн, просадка чека на 4 000 рублей на 96 сделках — ещё −0,4 млн. Вместе 1,6 млн, ровно разница с планом. Показатель попадает на второй уровень, если он стоит в этой цепочке или управляет её множителем: лиды (780), конверсия в сделку (12,3%), средний чек, время первого ответа. «Активность менеджеров» в цепочке не стоит и уезжает вниз.

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

Все три уровня читают один период и одну базу сравнения. Фильтр периода из третьего пункта должен двигать их одновременно: декомпозиция за месяц рядом с драйвером за неделю не складывается в объяснение, даже если оба блока технически верны. В ТЗ это фиксируется так же, как остальные требования к фильтрам, — одной строкой про то, какие блоки обязаны пересчитываться вместе.

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

• Для каждого блока в ТЗ укажите уровень: результат, драйвер, ограничитель или детализация.
• К результату припиши базу сравнения — план, прошлый период или baseline, а не просто «динамика».
• К драйверу припиши, в каком множителе он стоит, иначе он не драйвер.
• К ограничителю припиши порог и того, кто обязан реагировать при его пересечении.
• Перечислите блоки, которые обязаны пересчитываться одним фильтром периода.
• Для каждого показателя вне трёх уровней укажите, в какую детализацию он переезжает.

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

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