ТЗ на дашборд: показатели, источники, фильтры и критерии приёмки

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

Ниже — структура такого задания. Она помогает заказчику заранее определить результат первой версии, а при сдаче сравнить не только внешний вид, но и состав записей, сумму, права и состояния данных.

Закрепите пользователей, решение и границы этапа

Начните с уже выбранного управленческого вопроса, а не с нового списка KPI. Запишите один или несколько рабочих сценариев по схеме:

1. кто открывает экран;
2. что видит сначала;
3. к какой детализации переходит;
4. какое решение или действие выполняет.

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

Затем ограничьте первый этап. В паспорте проекта перечислите:

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

Первый этап может работать с одной согласованной выгрузкой CRM. Это не означает постоянного подключения к любой CRM. У Switch On AI такой состав обсуждается в рамках услуги разработки дашбордов и отчётности: источники, методика, обновление, интерфейс и проверки определяются для конкретного проекта.

Результат раздела: краткий паспорт проекта, сценарии пользователей, границы первой версии и перечень открытых вопросов с ответственными.

Свяжите показатели с методикой и источником

У каждого числа на экране должен быть проверяемый смысл. Для показателя укажите ID, название, версию утверждённого правила, источник и владельца методики. Полный паспорт расчёта можно вести отдельно; в ТЗ на экран достаточно связать его с виджетом и контрольными строками.

Минимальный реестр выглядит так:

Для источника зафиксируйте способ получения, владельца, обязательные поля, идентификатор записи, единицы, валюту, дату отбора, часовой пояс, полноту и доступный обезличенный образец. Одинаковое название поля в двух системах не доказывает одинаковый смысл: например, «дата» может означать создание, оплату или закрытие.

Если подразделения считают показатель по-разному, есть два честных варианта: согласовать одно определение либо создать разные, явно названные показатели. Нельзя скрывать расхождение одной суммой.

В учебном примере ниже показатель M1 связан с набором CONTROL-v1. Правило такое: сложить amount только у записей со status=won, если closed находится в интервале от 1 сентября 2026 года включительно до 1 октября исключительно. Единица — рубль, даты трактуются как согласованные календарные даты Europe/Moscow, ID должен быть уникальным, а сумма у включаемой записи обязательна.

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

Опишите макет, фильтры и переход к деталям

Макет должен описывать поведение, а не только расположение блоков. Для каждого виджета укажите название, единицу, период, активные фильтры, дату или версию среза и способ показа неизвестного значения. Для перехода к деталям перечислите сохраняемый контекст и доступные поля — например, ID, подразделение, дату закрытия, статус и сумму.

Для каждого селектора подготовьте строку матрицы:

В документации DataLens дашборд описан как страница или набор страниц с виджетами, а селектор — как фильтр связанных виджетов с настраиваемой областью действия. Здесь DataLens служит документированным примером устройства связей. Он не заявлен выбранной или протестированной платформой проекта.

Проверяйте фильтр по ожидаемым строкам и итогу. В EX-D02 фильтр «Север» для роли с полным доступом оставляет A1 и A2: две строки на 30 000 рублей. Фильтр «Юг» оставляет B1: одну строку на 30 000 рублей. Сброс для руководителя компании возвращает A1, A2 и B1 на 60 000 рублей.

Похожая диаграмма не подтверждает правильный фильтр. Две неверные выборки могут случайно дать одинаковую сумму.

Результат раздела: макет и матрица «фильтр → виджеты и контекст → ожидаемые записи → итог».

Задайте разрешённые данные и действия ролей

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

Составьте матрицу с нужными действиями:

По принципам OWASP требования к авторизации стоит строить вокруг минимально необходимых прав, отказа по умолчанию и проверки разрешения для запросов и конкретных объектов. Эти принципы помогают сформулировать испытания, но одна матрица не подтверждает полную безопасность и не является сертификатом.

Для руководителя Севера серверная область до пользовательской фильтрации уже ограничена A1 и A2. Поэтому сброс оставляет те же две записи и 30 000 рублей. Попытка открыть B1 или B2 по прямой ссылке, получить их через селектор либо выгрузить должна завершиться без выдачи данных. Это требование будущей проверки, а не заявление о проведённом тесте.

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

Результат раздела: матрица «роль → область → действия → запреты → сценарий проверки».

Согласуйте обновление и состояния при неполных данных

Укажите способ обновления: ручной файл, подключение, расписание или событие. Рядом запишите допустимое опоздание и владельца реакции. Универсальной частоты и SLA нет: значения определяет конкретный проект.

Экран должен различать состояния:

Например, отсутствие amount у A2 нарушает контракт набора. Повтор A1 нарушает уникальность ID. В обоих случаях новый набор нельзя без оговорки принять за полный. Если после сбоя доступен CONTROL-v1 с итогом 60 000 рублей, интерфейс может сохранить его как последний успешный срез — но только с исходной датой, версией и явной пометкой, что новое обновление не состоялось.

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

Результат раздела: таблица «условие → видимое состояние → действие ответственного → способ проверки».

Подготовьте контрольные данные и сценарии приёмки

До разработки согласуйте синтетический или обезличенный набор, версию методики и независимо рассчитанные ожидания. Скриншот и сообщение «обновление прошло без ошибок» не доказывают правильность состава данных.

Программа должна покрывать риски конкретного проекта. Для EX-D02 предусмотрены обычная выборка, фильтр и сброс, границы периода, пустая выборка, пропуск обязательного значения, дубль, сбой обновления и ограничение роли.

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

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

Результат раздела: воспроизводимая программа «требование → вход → ожидаемые строки, итог или статус → фактическое наблюдение».

Зафиксируйте решение, передачу и последующие изменения

Протокол приёмки должен отвечать не только на вопрос «принято ли», но и показывать, что именно проверили. Включите в него:

• версию решения, среду и время проверки;
• выполненные сценарии;
• фактические наблюдения и свидетельства;
• замечания и ответственных;
• решение по каждому открытому пункту и по выпуску в целом.

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

Перед передачей сверьте комплект:

Изменение формулы, источника или права — контролируемое изменение задания. Его нельзя незаметно включить в обычную правку экрана.

Техническая приёмка подтверждает согласованное поведение панели. Она сама по себе не доказывает рост продаж или качество управленческих решений. У Switch On AI опубликован MVP дашборда из файла CRM, где отдельный модуль рассчитывает показатели, а браузерный интерфейс показывает сводку. Это ограниченный проект для определённого формата выгрузки, а не универсальная система аналитики и не обещание совместимости с произвольным файлом.

Результат раздела: протокол решения и перечень переданных материалов с владельцами дальнейшей работы.

Учебный фрагмент ТЗ и проверка одной панели

EX-D02 — учебное ТЗ и синтетический контрольный набор. Реальные CRM, DataLens, учётные записи и приложение не тестировались. Рассчитаны только ожидаемые значения.

Вход. Будущая панель должна показывать операционную сумму успешных закрытий M1 за сентябрь 2026 года по фиксированному набору CONTROL-v1.

Правило. M1 — сумма amount только для строк со status=won, где 2026-09-01 ≤ closed < 2026-10-01. Единица — рубль. Даты — согласованные календарные даты Europe/Moscow. ID уникален; у включаемой записи amount обязателен.

В сентябрьскую выборку входят A1, A2 и B1. B2 исключается из-за lost, а C1 — потому что верхняя граница 1 октября не включается. Ожидание: 3 строки и 60 000 рублей.

Требования, связанные с проверками

Пользовательский фильтр полного доступа и область роли работают по-разному. Руководитель компании может выбрать Север, Юг или сбросить фильтр к A1/A2/B1. Разрешённый набор руководителя Севера изначально равен A1/A2. Поэтому его сброс возвращает A1/A2 и 30 000 рублей, а не весь CONTROL-v1.

Состояния тоже нельзя объединять. Корректная пустая выборка означает: источник полный, подходящих строк нет, итог известен и равен нулю. Пропуск amount, повтор ID или отказ обновления означает, что новый полный результат не получен. В последнем случае прежние 60 000 рублей можно показать только как архивный CONTROL-v1 с настоящими датой и версией.

Дальнейшие действия по EX-D02:

1. согласовать методику, источник, роли и версию набора;
2. выполнить программу в названной разрешённой среде;
3. записать факт отдельно от ожидания;
4. исправить расхождения и повторить затронутые проверки на новой версии;
5. принять решение и передать материалы в договорном объёме.

Результат примера: готов шаблон требований и ожидаемых результатов. Арифметика контрольных строк проверена. Фактическая приёмка интерфейса, прав и обновления не проводилась.

Совпадение одной суммы не подтверждает правильную выборку. Селектор не расширяет права. Ошибка источника не равна нулю. Если подразделения спорят о формуле, сначала утверждают методику и её версию, а затем пересчитывают ожидания.

Если вам нужен дашборд по собственным данным, подготовьте выбранный управленческий вопрос, обезличенный образец, определение показателя и пример ожидаемого результата. Добавьте пользователей, фильтры и допустимые действия. Со Switch On AI можно обсудить задание и критерии приёмки дашборда. Не передавайте через открытую форму рабочие базы, секреты и персональные данные.