Как создавать дашборды, которыми будут пользоваться

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

Меня зовут Иван Успенский, я работаю с UI/UX и аналитическими решениями в КОРУС Консалтинг – и мы с вами поговорим о том, как обычно создаются дашборды и почему это не всегда происходит успешно; а еще сформулируем рекомендации для всех, кто хочет создавать полезные и востребованные информационно-аналитические системы.

Зачем нужен дашборд?

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

На тактическом уровне причины создания дашбордов могут быть разными:

1. Оцифровка бумажных отчетных форм. Например, в компании для руководства регулярно готовилась презентация со вполне определенной информацией. Эту презентацию перевели в цифровой вид, автоматизировали сбор и обработку данных — и получили экранную форму в системе.
2. Осознанная необходимость мониторинга в ходе развития. Компания проанализировала бизнес, выработала ряд гипотез, нуждающихся в проверке цифрами; описала ряд ключевых процессов — и сформулировала для них важные метрики (KPI). Для их визуализации и отслеживания построили дашборд.
3. Обобщение или детализация информации. Дашборд по конкретному процессу уже был, но стало важно получить больше данных – или посмотреть на них под другим углом. Если появляются новые пользователи с новыми запросами – возможно, будет логичнее сделать для них новый дашборд на основе работающего, а не дополнять старый данными и функциями для управления их визуализацией.
4. Копирование работающих решений из другой области. Взяли дашборд одного отдела — и внедрили его для других (с изменениями или без таковых); или же — посмотрели на конкурентов или партнеров и т.п.

Как появляются дашборды в проектах?

Есть два основных подхода к созданию программного обеспечения вообще, информационно-аналитических систем (BI) в частности – и дашбордов как части таких систем: проектный и продуктовый.

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

Чтобы создать дашборд, сначала нужно подготовить данные для него. Хорошо, если в организации есть подразделение, отвечающее за информационно-аналитическое обеспечение деятельности. .В этом случае речь идёт о постоянном анализе аудитории и удовлетворении её нужд, и здесь можно использовать продуктовый подход. А вот если такого подразделения или хотя бы постоянного подрядчика нет, то деятельность по созданию дашборда становится проектом – разовым мероприятием по созданию уникального результата с ограниченными ресурсными затратами временно сформированной командой, взаимодействующей со стейкхолдерами.

Чтобы выбрать, какой путь больше подойдет вашей команде, нужно учесть все плюсы и минусы:

Проектный метод

Плюсы проектного подхода: бюджет и срок согласованы «на берегу», роли в команде необходимы и понятны. Это гибкий и полезный инструмент управления работами, включающий методы планирования и коммуникаций.

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

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

Потому что у сотрудника, аккумулировавшего данные, есть своя точка зрения на процесс:

Сотрудник 1. Ему крайне важно понять реальную ситуацию с бизнес-процессами, чтобы принять необходимые решения и обеспечить стабильность работы и рост организации (на иллюстрации изображен осматривающим ситуацию в целом с высоты).

Сотрудник 2. Хочет, чтобы его недоработки не попали «в кадр», особенно – по выполнению плана по показателю Х в истекшем месяце.

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

Если создавать дашборд на основе взаимодействия лишь с одним сотрудником, очевидно, что у нас получится одностороннее видение.

Вот дашборд первого сотрудника. Акцент в нем — на возможности сопоставления разных показателей и интерактивность, обеспечивающую необходимую гибкость настройки отображения данных. К сожалению, этот сотрудник чаще всего занят – и делегирует задачу руководителям подчиненных подразделений. Кроме того, его время слишком ценно – и он не может позволить себе генерацию требований (полноценное интервью исключено); в лучшем случае он готов лично выбрать один вариант из нескольких предложенных.

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

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

Проектная команда в целом поддерживает третий вариант – потому что здесь исключена интерактивность, т.е. разработка будет ощутимо проще («за» высказались разработчик и руководитель проекта).

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

Что еще усложняет проектный подход

У каждого стейкхолдера вполне могут быть свои специфические интересы и цели применительно к дашборду и проекту в целом. И все их нужно учесть:

1. Разработчик: «сделать технологично и просто, а еще – использовать компонент, который я недавно освоил, и он мне нравится».
2. Сотрудник функционального подразделения: «Дашборд должен быть максимально похож на то, как выглядит отчёт, который я готовлю для руководства каждую среду».
3. Руководитель проекта: «Сделать все максимально дешево и быстро».
4. UX/UI-дизайнер: «Инструмент должен быть удобным и комфортным для пользователя».
5. Бизнес-аналитик: «Решение должно соответствовать бизнес-целям пользователей в рамках бизнес-процессов».
6. Дата-инженер: «Нужно сделать так, чтобы не пришлось дорабатывать систему-источник».
7. Любой сотрудник: «Давайте сделаем это быстро, чтобы можно было в пятницу уйти с работы пораньше».

Применение UX-дизайна усложняет планирование работ в проекте. С одной стороны, тщательная проработка макетов и прототипов сокращает затраты на разработку программного обеспечения; с другой стороны, такие задачи несколько специфичны — и планирование и управление ими может оказаться не так просто для руководителя проекта.

Минусы проектного подхода можно сократить при помощи правильной работы с командой. Руководитель должен гибко управлять сотрудниками с учетом реальных вводных – это могут быть неполные и нечеткие требования, новые роли и процессы, новые артефакты. Каждый должен понимать свою роль и общую концепцию проекта. В таком случае потери времени и ресурсов будут минимальными, а работа эффективной. Хотя такая осознанная работа над проектом и будет сложнее и, очевидно, более затратна для команды и руководителей.

Продуктовый подход

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

Допустим, у компании есть специализированное подразделение, ответственное за информационно-аналитическое обеспечение деятельности организации; в этом подразделении в частности и в организации в целом, соответственно, постоянно идёт работа по совершенствованию и поддержке системы отчетности (ответы на новые вызовы, реакция на новые требования бизнеса). Тогда работа с конкретными дашбордами становится всего лишь одним из шагов в развитии продукта в целом, а не отдельной автоматизацией.

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

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

Что выбрать и как действовать?

В ответ на такой вопрос мы предлагаем свой: а зачем выбирать? На практике подходы различаются очень сильно; настолько, что даже роли сотрудников не совпадают для большей части команд (начиная уже с менеджеров проекта и продукта). Почему так сложилось? Возможно, из-за особенностей восприятия продуктового подхода – как методологии создания чего-либо для широкой аудитории и рынка в целом.

KPI продукта обычно включают маржинальность, продвижение, ценностное предложение, перспективы развития и тиражируемости. И почему же мы не можем эти метрики воспринять не только для B2C-продукта? Каждый из этих пунктов вполне трактуется для информационно-аналитической системы внутри организации. А KPI как раз и определяют эффективность деятельности внутреннего ответственного.

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

В заключение дадим несколько более практических советов.

Пользователь:

Смело формулируйте требования. Требования – единственные возможные критерии качества.

Старайтесь ориентироваться на реальные бизнес-потребности – свои и ваших коллег.

Не пытайтесь 100% скопировать решение: не используйте что-либо только потому, что в другом месте или в другом виде оно каким-либо образом работает.

Не уходите в детали реализации – это можно оставить исполнителям работ.

Заказчик:

Настройтесь на конструктивный диалог. Если работа над результатом превратится в «перетягивание одеяла», есть риск уйти в две крайности. Первая — коллеги-сотрудники будут диктовать требования и получат неудобный и неэффективный инструмент. Вторая – исполнитель сделает все красиво и умело, но бесполезно.

Исполнитель:

Сделайте все для того, чтобы получить подробные требования, а не просто ожидайте готовый набор от Заказчика.

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