Данные, запросы, чарты, требования, больше требований, снова данные, в конце концов релиз и уже новый проект, новый отчет. Мы вкладываем силы в дашборды на стадии разработки, user acceptance testing и переключаемся на новые задачи, а потом с грустью обнаруживаем печальную статистику использования.

Также замечаю у BI аналитиков (в том числе у себя) склонность защищать свое виденье того, как должен быть организован конкретный дашборд, объясняя пользователю что он неправ, когда не понимает его и не ценит его возможностей, дизайна и т.д. Отдельные негативные фидбеки автор скорее отсекает, как случайные, и не замечает проблемы, что отчет не понят и не принят пользователями массово. Своеобразный report developer cognitive bias. Самое простое - сказать "Мерзкий юзер вечно хочет свой эксель, что я могу".

Короче, далее размышление пойдет о CustDev в дешбординге, а именно о получении фидбеков в процессе жизненного цикла аналитических продуктов, а точнее настройки потока обратной связи для лучшей адаптации отчетов.
CustDev практики хорошо работают в продуктовой разработке - любой пользовательский интернет сервис, мобильное приложение - делают все, чтобы настроить поток обратной связи от пользователя, анализируют воронки на пути клиента от первого контакта до ухода. Для такого продукта любые улучшения в этой области дают прямой эффект на финансовый результат (через классические метрики ARPPU, LTV и т.д.).
При этом в BI проектах идеи CustDev представлены нешироко, хотя достаточно посмотреть на отчет как на продукт, а на пользователя как на платящего клиента. Прям какая-то унылая артельная гордость есть в нежелании BI команд принимать продуктовый подход.

Стоит отметить, что проблема обратной связи актуальна именно для массовых кросс-функциональных отчетов - когда автор и заказчик отличаются от целевой группы пользователей отчетов. Именно такие отчеты попадают под модель, где количество уникальных пользователей и просмотров говорит о его ценности. Когда отчёт локальный - developer - customer gap не образуется, ведь разработчик отчета или сам является его пользователем (делает для себя) или имеет прямую связь с небольшой группой пользователей.

В системном сборе обратной связи на BI-проекты стоит сразу отделить широкомасштабные корпоративные опросы от механизмов непрерывного сбора фидбеков (anytime/ongoing feedback) внутри различных продуктов и тулов.

Первые (1) собирают в целом удовлетворенность от пользования системами или о работе отделов и команд, (2) проводятся обычно централизованно с частотой 1-2 раза в год. Можно делать специализированные опросы по BI системе - вы получите ценную информацию для ее развития, но без деталей по ситуации в конкретных отчетах. Это, в частности описывал Рома Бунин, говоря о «Аля NPS» метрике.

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

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

Форма предполагала

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

Результат был около нуля. На отчете с 200 уникальными пользователями в месяц мы получали ~ 0-2 фидбека. Очевидно, что это не то, что способно существенно помочь команде и проекту в качественной адаптации отчёта.

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

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

Прошло время мы прикинули что фидбеки таки нам интересны. Начали анализировать.

Нехватка информированности решается до некоторой степени промоушеном, нотификациями, тренингами и пр. Тут все как везде.

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

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

Мы решили двигаться дальше и развивали тему - так появилась идея построить фреймворк который будет находить тех, кому есть, что сказать, и запрашивать их фидбек адресно.
Кажется логичным два сценария:
1) смотрим какими отчетом пользовался сотрудник за месяц чаще всего и просим его письмом дать обратную связь на этот конкретный отчет.
2) смотрим каким отчетом сотрудник пользовался стабильно 3+ месяца, но в течении последнего месяца перестал. Запрашиваем письмом причину.

Таким образом мы гарантируем, наш запрос будет релевантным для юзера, отчет узнаваемым и значимым.

Далее собственно генерируем отправку сразу сотен кастомных писем активным пользователям раз в месяц. и Ждем)

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

На текущий момент нет еще данных об эффективности этого подхода.
Фреймворк пока в середине беклога, но реализация не сложная и в текущем году мы точно дойдем до него. Видимо совместим сразу со следующим шагом - переводом процесса в Чат-бот, более нативный канал общения с сотрудниками в корпоративном мессенджере (slack, teams etc). Если вместо писем бот будет стучаться и просить о фидбеке - это качественно повысит количество ответов. В моем представлении выбрать звезды или смайлик, написать пару слов о понятном для тебя отчете и вернуться к другим делам - будет вопросом 10 секунд.

Скажу в конце страшную вещь - не факт, что и этот подход взлетит. А даже если и взлетит - не факт, что все из вас готовы и хотят получать столько "правды" от пользователей и менять свое мнение об отчетах) Тут как в жизни, каждый решает сам, во что комфортнее верить. Я то за любой интересный BI-кипиш кроме садомии.