Как приготовить дашборд и порадовать босса? ПП-рецепт для начинающих и матёрых волков

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

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

Признайтесь, что у вас есть специфичный опыт, о котором хотелось бы забыть? Мы об опыте параллельной работы с зоопарком учётных систем и источников данных компании.

Например, когда нужно свести звонки менеджеров по продажам с лидами из Mango Office в 1С, а потом ещё сверить поступление денежных средств и дебиторку. Классическая необъятная задача, которая со временем начинает поглощать и вытягивать энергию. И что с этим делать, как навести порядок?

1. Самый простой совет — бейте задачу (не ногами) на маленькие задачи. Декомпозируйте и составьте план действий. Только тогда вы сможете оценить, что за каким этапом идёт, и заметить узкие места по ресурсам, компетенциям или вовсе усомниться в корректности поставленного ТЗ.
2. Разделите хранилище с метриками на 2 части — сырые и витринные данные. Добейтесь того, чтобы минимизировать количество схем и расчётов в BI. Ведь если в бизнесе изменится парадигма расчётов, то вам придётся только лишь поменять расчёты в БД, а не во всех программах сразу. Да, это душный совет, он усложняет работу на первоначальном этапе дашбордостроения, но в разы облегчит управление всей BI-системой.
3. У каждого этапа обработки данных должно быть ответственное лицо. Иначе тут не досмотрели, там накосяпорили, и почему-то выручка не сошлась. Упс. Учётные системы —> БД —> BI — вот идеальный конвейер данных. И у каждого процесса должен быть верховный жрец.

Подход к организации хранения данных из всех учетных систем в одной БД («все яйца в одной корзине») поможет ускорить сбор отчётности тем пользователям, которые всё ещё верят в Excel, но отрицают существование BI-инструментов.

Когда водоворот из источников данных превратился в тихую гладь, нужно перейти к процессу макетирования. И тут сразу делимся предостережением — даже не пытайтесь «рисовать» дашборд с заказчиком, общаясь с ним где-то письменно в Telegram или при помощи голубя. Вы по-любому потеряете что-то важное, или сам руководитель где-то и что-то случайно недоскажет.

Чтобы не тыкать потом друг в друга пальцем, обвиняя в искреннем желании испортить жизнь, попросите заказчика встретиться с вами, проведите его за ручку по всему пути работы дашборда, покажите UX/UI.

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

Почему так, а не иначе?

1. Заказчик сразу видит результат, а не абстрактные обещания, как будет круто в перспективе.
2. Заказчик понимает, что он получит в конце работ — уберётся разрыв между ожиданиями и реальностью.
3. Заказчик осознает, как это будет работать и как с этим работать.

Знаем, нет предела совершенству, хочется иногда быть дезигнером-просветителем. Но будем с вами честны — дашборд обязан быть удобным и давать быстро ответы на вопросы пользователя. Это всё, что от него требуется. Постарайтесь поймать баланс между «глаза слепнут от красоты» до «глаза кровью вытекают». То есть коричнево-фиолетовые барчарты или жёлтый текст метрик на белом фоне — это для клуба БДСМ, тут мы БИАЙ делаем.

Небольшой список правил по оформлению:

Цвета. Их не должно быть супер-много. Три-четыре цвета на всём дашборде достаточно (не включая белый и чёрный). Один из них — акцентный для кнопочек/плашечек. Остальные — для графиков. Стремитесь к минимализму и гармонии.

Сетка. В прошлой статье мы описали основные правила юзабилити дашбордов, можете посмотреть на пример понятной навигации. Или вдохновиться шаблонами на revealthedata. Здесь мы отразим суть.

Фильтры. Вот тут критически важно обсудить, что на что будет влиять, какие фильтры нужны для детализации дашборда. И помните, что в большинстве современных BI-ках есть кроссфильтрация на графиках. Поэтому обучите пользователя этой магии, ну и на этапе прототипирования уточните у заказчика, нужна ли она вам вообще.

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

Режим свежести. Когда и как будут обновляться датасеты для отчёта? Этот вопрос поможет вам синхронизировать обновление БД и вашего дашборда.

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

Именно так вы сформируете общее понимание работы системы и сразу увидите недостающие данные. Да-да, такое прям бывает и часто. Например, заказчик хочет видеть статистику по скорости закрытия вакансии, но записей о вакансиях и откликах не ведёт.

На этом этапе, пока не поздно, вы сможете придумать, откуда брать данные. А не задаваться вопросом после внедрения BI в работу, где взять текучесть кадров без списочной численности и увольнений.

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

Этот этап похож на приёмку, но с элементами онбординга заказчика. Вы доносите ему ценность дашборда, объясняете, насколько точно BI-ка считает данные. То есть прямо намекаете, что дашборд считает за секунды точнее, если бы тоже самое делал сам заказчик.

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

Ну что, погнали делать аналитику вкусной и доступной вместе с FastBoard?