На связи Оля Андреева — руководитель группы аналитики по визуализации данных в каршеринг‑сервисе Ситидрайв. Мы в компании внедряем лучшие практики, строим систему отчётности и развиваем BI. Моя команда нацелена на создание красивых, понятных, непротиворечивых и удобных дашбордов для практически всех департаментов компании — от операций, маркетинга до HR. И здесь не обойтись без правильно выстроенной коммуникации с заказчиком.

В самом начале своего пути в аналитике мне очень помогла книга Тома Гривера «Articulating Design Decisions», которая убедила меня в том, что успешно выстроенные отношения с заказчиком творят магию. И хотя она посвящена преимущественно дизайну продукта, 90% описанных в ней практик идеально подходят и для разработки дашбордов. Для меня это лучшее руководство по коммуникациям для аналитиков — я рекомендую всем начинающим специалистам в своей команде начать осваивать подход к работе с заказчиками именно с этой книги.

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

1. Никогда не пропускай этап сбора требований

Заказчик может предлагать много идей, но ответственность BI–аналитика объяснить, как то или иное требование может повлиять на общий процесс разработки и финальный продукт:

«Да, добавить этот фильтр возможно, но в 2% случаев мы будем учитывать одного пользователя дважды. Важнее более точный расчёт или наличие фильтра?»

«Да, мы можем сделать это, но релиз дашборда затянется ещё на месяц. Подскажи, пожалуйста, такие сроки релевантны?»

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

2. Книги не всегда правы

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

Приведу наглядный пример. Во всех книгах по визуализации прописано правило: если рисуешь линейный график, то необходимо показать ось Y и сетку, но не показывать значения, как в варианте №1.

А если подписываешь значения графика, то необходимо убрать ось Y и сетку. Вариант №2 считается даже более верным, так как легко считывается.

Некоторые заказчики просят оставлять подписи значений, ось Y и сетку, как в варианте №3. По их мнению в работе удобно ориентироваться на все указанные элементы.

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

Правы ли книги? Конечно, правы. В 99% случаев второй вариант предпочтительнее. Если проходить собеседования на визуализацию данных, то именно этого ответа будут ожидать рекрутеры. Однако, если заказчику действительно для работы удобнее вариант №3, то его можно и нужно реализовывать.

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

3. Открытая коммуникация — это основа разработки любого дашборда

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

Кто-то сравнивает коммуникацию между заказчиком и аналитиком с конфронтацией, когда второй пытается максимально «сбрить» требования и отбить все возражения, чтобы как можно быстрее закрыть задачу. Или, наоборот, сделать вообще всё-всё, что скажет заказчик, воспринимая требования прямо и не критично: «ну заказчик же всё это попросил сделать, неважно, что разработка займёт 3 месяца». Но оба пути ошибочны. 

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

• основные требования, без которых дашборд не будет иметь смысла;

• средние по значимости, без которых дашборд может существовать какое-то время;

• необязательные пожелания, которые фактически можно пропустить. 

И именно по этим приоритетам планировать процесс разработки.

Работайте с ожиданиями. BI–разработчик должен всегда открыто доносить до сведения, что, когда и в каком объеме будет готово, а также сообщать о переносе сроков.

Будьте открыты к обратной связи. За спиной BI–разработчика может быть немало успешных проектов, пройденных курсов и прочитанных книг. Некоторые думают, что при таких знаниях ошибки невозможны, и если заказчику что-то не нравится, то дело в нём. Такой подход приведёт к обесцениванию предложений и идей, а конечный продукт потеряет в ценности. Даже на первый взгляд странное предложение заказчика стоит копнуть глубже и разобраться в причинах его возникновения.

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

Не стоит воспринимать обратную связь прямолинейно. Например, заказчик может быть недоволен, но не хочет давать открытую обратную связь и несогласие выражает через каверзный вопрос: «а почему здесь все цвета так похожи?». Скорее, ему не интересно узнать причину, а просто не нравится представленное решение. Бывает, наоборот, заказчик использует большие преувеличения. Например, «здесь ничего непонятно». Обычно за этим стоит куда меньшая проблема. Мой реальный рабочий кейс звучал так: «этот дашборд будто два разных разработчика делали!». На самом деле заказчика смутил немного отличающийся цвет на одной из визуализаций. Какой бы ни был случай, правильнее всего спросить, что конкретно волнует человека и чего хотелось бы достичь. Бывает, человек сам не может ответить на эти вопросы – тогда нужно совместно докопаться до истины.

4. Готовься к встречам заранее

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

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

• Расскажи, пожалуйста, подробнее про то, какой бизнес-процесс описывает дашборд?

• Кто является аудиторией дашборда кроме тебя?

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

• На какие вопросы дашборд должен отвечать? И какие решения на его основе принимаются? Поскольку групп довольно много, то как ты понимаешь, какие комбинации тебе нужно смотреть и куда вообще копать?

• Есть ли ещё заинтересованные лица, с которыми необходимо встретиться и обсудить дашборд?

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

• Нужно ли нам всё-таки показывать долю combo клиентов? Или стоит убрать колонку?

• Насколько нужны графики по Retention для количества заказов?

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

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

Всегда имей альтернативу. При создании мокапа или демонстрации первой версии дашборда имеет смысл предлагать альтернативные версии. Заказчики, как правило, положительно реагируют на возможность выбирать варианты и влиять на конечный продукт. Коммуникация может быть в таком формате: «‎Есть один вариант мокапа дашборда, на нём изображено X. У него есть плюсы А и B, а минусы С и D. А также есть второй мокап дашборда, он отличается тем-то и тем-то, и у него есть следующие достоинства и недостатки. На мой взгляд, всё же лучше будет первый вариант. Что думаешь?».

Вдруг заказчик будет настаивать на более неудачном варианте? Если мы не можем объяснить почему одно решение лучше другого, значит мы не очень хорошо подготовлены – не понимаем ценность продукта или потребности. 

Бывает, мы попадаем в ментальную ловушку – видим только одно решение из-за того, что спешим или всё кажется просто очевидным. Это может привести к негативному фидбеку – не имея альтернатив, заказчик предложит своё решение или просто будет не согласен с предложенным вариантом.

Кто может поддержать тебя? В сложных кейсах стоит продумать, кто из коллег может помочь договориться с заказчиком, например, твой менеджер, другой BI разработчик или аналитик из соседнего отдела, который подтвердит твои слова. Перед встречей нужно договориться с коллегой, что его поддержка понадобится в определенном вопросе, чтобы он подключился к обсуждению в нужный момент. Например, «‎Да, в другом проекте мы использовали такой подход в подсчете показателя X. Это ускорило разработку и точность не хуже». Так аргументация получит больший вес. При этом на встрече нужно оставаться нейтральным и не склонять помощника в свою сторону.  Подчеркну, что задача тут не обмануть заказчика, продавив его общим мнением, а быстрее прийти к консенсусу и эффективному решению.

5. Работай с заметками после встречи

Делать заметки — это своеобразный контракт с заказчиком, поэтому кратко формулировать договорённости по итогам встречи в интересах BI–разработчика.

Какими должны быть заметки?

• Своевременными — направлены чем раньше, тем лучше. 

• Структурированы, чтобы быстро найти нужную информацию.

• Короткими – выделены только самые важные пункты.

Что стоит включать в заметки?

Действия. Прописать, что нужно со стороны заказчика и со стороны BI–разработчика. 

Со стороны BI разработчика:

• Подготовить макет дашборда.

Со стороны менеджера Ивана Ситидрайвова:

• Уточнить требование, нужна ли разбивка по кварталам.

• Выслать excel-файл, который сейчас используется за неимением дашборда.

Когда будет следующая встреча. Например, «на следующей неделе мы продолжим обсуждение, приглашение отправлю в конце рабочего дня». Это сформирует ожидания.  

Согласованные требования. Прикладываем список требований, которые согласовали на встрече.

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

Pro Tip: Если заказчик склонен к частой смене требований и апелляции «а мы о другом договаривались» — попросите проверять минутки и писать, что он ок с ними.

6. Объясняй свои решения, а не ссылайся на умные книжки

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

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

7. Верь в лучшее в людях

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

8. Если после встречи что-то пошло не так – это можно исправить

Давайте разберём несколько примеров проблем, с которыми может столкнуться аналитик после встречи.

Возможная проблема №1: Внезапно понял, что какое‑то из согласованных требований противоречиво или плохо влияет на дашборд. Начинающий BI‑разработчик может постесняться перечить заказчику, раз согласовали — нужно делать. Но правильно будет отложить это требование в сторону и попробовать обсудить этот вопрос ещё раз.

Возможная проблема № 2: Обсуждали‑обсуждали, но так ни к чему не пришли. Такое бывает, если заказчик не знает чего хочет. Здесь есть 2 варианта решения. Первый — дать время на подумать и согласовать перенос задачи. Второй — взять инициативу в свои руки и самостоятельно разработать макет чернового дашборда, который станет отправной точкой для дальнейшего обсуждения и сдвинет проект. В последнем сценарии важно не закопаться в детали и потратить минимум времени. Цель — не сделать полностью готовый продукт на основе своей бурной фантазии, а создать стартовый плацдарм, который поможет заказчику определиться с требованиями. Даже очень сырое решение может помочь.

Финальные мысли

Развитие доверительных отношений BI‑разработчика с заказчиками похоже на банковский счёт. Сделал всё точно и в срок — получили зачисление. Прозрачно и понятно объяснили, как пользоваться дашбордом — получили зачисление. Забыл важное требование или упорно настаивал, что не будешь вносить правки — получили списание.

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