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