Привет! Меня зовут Александр Вальд. Я старший наставник на курсе «Аналитик данных» в Практикуме, а также владелец фирмы по анализу данных Wilde Tech и музыкальной школы SoulTune. В аналитике более шести лет, из них почти три года работал аналитиком в СМИ.
Помнит тут кто-нибудь телесериал «Понять. Простить»? В нём психологи разбирают проблемы в отношениях и пытаются помочь героям. Одна из телепсихологов в конце серии иллюстрировала разобранную историю с помощью кукол.
В этой статье нашими куклами станут Аналитик и Заказчик. Вы узнаете, как аналитику следует общаться с заказчиком и почему без дополнительных вопросов брать задачу неэффективно.
Одна задача — две крайности
Приходит как-то заказчик к аналитику и ставит задачу, для решения которой нужно построить дашборд. Чётких требований у заказчика к дашборду нет, а нужен он вчера. И главное — дашборд должен быть в корпоративных цветах!
Я, разумеется, утрирую. Однако на практике заказчик часто не может дать аналитику правильно составленное ТЗ, потому что не на 100 % понимает, что ему нужно. В таком случае аналитик рискует уйти в одну из крайностей: «продавить» свой вариант заказчику или без лишних вопросов сделать всё буквально по ТЗ.
Почему нельзя полагаться только на свой опыт, игнорируя ТЗ? Заказчик может плохо представлять результат, но он знает, какие цели у его компании и на какие вопросы должен отвечать дашборд. А задача аналитика — использовать свою экспертность, чтобы помочь бизнесу достичь этих целей.
Другая крайность — ставить профессионализм заказчика выше своего и чётко следовать ТЗ. Вы профессионалы в разных сферах. Заказчики не погружены в тонкости аналитики и BI-систем. Они могут не замечать проблем и ошибок в прошлых решениях, не видеть какие-то закономерности в процессах в компании и на рынке, неверно представлять себе возможности дашбордов.
Сохранить баланс и не уйти в крайности поможет общение.
Семь раз спроси
Однажды ко мне обратился генеральный директор региональной фирмы по продаже строительной химии, чтобы поговорить об отделах продаж и рекламы. Проблема была в том, что оба отдела готовили в Excel отчёты для своих руководителей, а потом эти отчёты объединялись и шли на стол гендира.
Для таких разговоров есть универсальные рекомендации, как себя вести аналитику:
Допустите, что ваш опыт в этом конкретном случае может быть нерелевантным. Пользуйтесь своей экспертностью, но не ставьте себя выше заказчика.
Внимательно выслушайте заказчика, не перебивая его и не навязывая своё мнение.
После рассказа заказчика задайте дополнительные вопросы. Переспрашивайте и уточняйте, верно ли поняли тот или иной момент.
В конце обязательно спросите: «Какой ещё вопрос мы не обсудили?». Это часто помогает получить неожиданную информацию. Ведь заказчик задаст вопрос сам себе и ответит на него.
Удачное название для этого набора рекомендаций — «Метод Коломбо» — я подсмотрел у BI-аналитика Романа Бунина. Кстати, Роман один из авторов курса «Визуализация данных и введение в BI-инструменты» в Практикуме.
Так вот, название отсылает к старому детективному сериалу про лейтенанта Коломбо. Герой выглядел и разговаривал просто, никогда не возвышался над собеседником и всегда приговаривал «и ещё кое-что», собираясь задать очередной вопрос. Словом, Коломбо — мастер интервью с заказчиками.
Чтобы приложить рекомендации к практике, перескажу свой разговор с заместителем директора той фирмы и добавлю пояснения.
З: У нас проблема с рекламой и продажами. Нужен дашборд.
А: Хорошо. А что за проблема?
З: Да просто всё в кучу собрано, и ничего не понятно.
А: Вы не видите общей картины, верно понимаю?
Не бойтесь переспрашивать. Перефразируйте вопрос и задайте его ещё раз. Это поможет однозначно определить, что вы и заказчик понимаете проблему одинаково.
З: Да, приходится выделять на пару недель несколько сотрудников, чтобы те свели в единый отчёт всё, что произошло. И ошибки в данных остаются…
А: То есть сейчас вы собираете единый отчёт из разных отчётов, верно понимаю?
З: Ага, что-то из 1С, что-то из Excel.
А: А как часто вы готовите отчёты?
З: Раз в квартал. Чаще не получается.
А: А как часто вы бы хотели смотреть отчёт?
Вопрос о частоте обновления данных в любом случае нужно задать. И поскольку заказчик указал на эту проблему в числе первых, сразу уточняю, что ему хочется исправить.
З: Ну… Я бы хотел каждый день, но в этом не так много смысла, наверно…
А: Ну почему же? Всё зависит от потребностей и наличия данных для показа. Пока не изучу данные, я не готов гарантировать вам ежедневное обновление. Но вернёмся к этому вопросу, когда я покажу вам прототип. Сейчас я хочу записать ваши пожелания.
Не создавайте заказчику лишние рамки. Пусть выложит вам всё, что он действительно хочет. Полезно узнать «идеальный» вариант. При этом не давайте на первой же встрече обещаний. Давать их можно уже после изучения всех требований, пожеланий и данных.
З: Да, видеть отчёт каждый день было бы здорово! Но ещё есть гендир, и ему нужна отчётность по рекламе и продажам в одном месте…
А: Кстати, а кто будет пользоваться дашбордом?
Вопрос о пользователях дашбордов, как правило, задают раньше. Но пока заказчик говорит, лучше его не перебивать. Аналитик может спросить после.
З: Гендир, я, отдел рекламы и отдел продаж.
А: А линейные сотрудники из отделов рекламы и продаж тоже?
Опять же, уточняйте все детали. Заказчик может подразумевать какие-то вещи, не проговаривая их явно по привычке. Или просто — забыть упомянуть.
З.: Да, линейные тоже.
А.: Нужны ли отделу продаж показатели рекламы? А гендиру — максимальная детализация?
З.: Вообще, продажникам про рекламу знать не нужно. А гендир иногда просит детали, да.
А.: Знаете, можно сделать несколько дашбордов: для отдела рекламы, для отдела продаж и для руководства. Это распространённая практика. Ваш гендир при необходимости сможет открыть дашборд с подробностями по рекламе или продажам.
З.: Да, так было бы идеально!
Заказчик не подумал или даже не знал, что дашборд может быть не один. Но это не значит, что заказчик некомпетентен. Очевидные для аналитика решения могут быть вовсе не очевидными для заказчика.
В итоге получился продуктивный разговор. Аналитик аккуратно выяснил требования и предложил одно из возможных решений, которое сам заказчик не рассматривал.
Здорово, когда заказчик доверяет опыту аналитика и открыт его предложениям. Но иногда приходится работать с теми, кто не готов слушать, и с кем непросто построить продуктивную рабочую коммуникацию.
З: Нужно свести абсолютно все показатели фирмы в один дашборд. Наш цикл производства — от лесопилки до продажи в магазине. Все процессы должны быть видны.
А: Понимаю вас. Но что, если разделить метрики на несколько дашбордов?
З: Нельзя! Только такой вариант. Он уже утверждён.
Когда заказчик настаивает на своём, не факт, что причина в его скверном характере. Частая история: заказчик не может принять решение самостоятельно, а его руководитель уже утвердил ТЗ, не подумав об удобстве пользования. Игнорировать требования вышестоящего заказчик не может. Тогда аналитик предлагает протестировать несколько вариантов.
А: Какой дедлайн?
З: Всё должно быть готово ровно через три месяца.
А: А что если через месяц я покажу вам урезанную рабочую версию — несколько дашбордов? Давайте протестируем их с вашим руководством. А через три месяца принесу финальную версию по ТЗ.
З: Даже не знаю… ТЗ ведь утверждено…
А: Понимаю. Поэтому заранее покажу более простые дашборды, а ваш руководитель даст комментарии, которые я учту к дедлайну.
З: Вообще, неплохая идея. Давайте так и сделаем.
Спорить с заказчиком нет смысла. Предмета спора ещё не существует. А показав первую версию дашборда, уже можно говорить о корректировках в ТЗ. Даже если заказчик откажется от вашего варианта и продолжит настаивать на своём, вы как минимум предложили разумную альтернативу, и выбор заказчика стал более осознанным.
Рекомендации и выводы
Хороший аналитик — это разговаривающий аналитик. Без диалога задачу, конечно, можно выполнить, но пользы от такой работы будет мало или не будет вовсе.
Аналитик должен разглядеть или хотя бы предположить истинный запрос со стороны заказчика, но не решать за него.
Заказчику нужно решить проблему, а не проверить навыки и знания аналитика. Поэтому не стоит бояться показаться непрофессиональным. Задавайте вопросы и вместе с заказчиком разрабатывайте удобный план, который можно будет скорректировать в потенциально выгодную для бизнеса сторону.
Используйте итерационный подход в решении задачи. На промежуточном этапе заказчик сможет сам увидеть, что в изначальном ТЗ попросил больше, чем ему было нужно, или упустил что-то важное.
Если с первых минут разговора вы поняли, чего хочет заказчик, — не спешите завершать встречу. Вспомните, что излишняя самоуверенность может привести к долгим правкам или бесполезным дашбордам.
Работа аналитика над проектом начинается с общения с заказчиком, поэтому так важно провести интервью правильно. Этот софтскил я, как наставник, регулярно тренирую у студентов: они по очереди отыгрывают аналитика, а я — заказчика. После интервью и согласования ТЗ начинается ещё более интересная часть — анализ данных и построение дашбордов. Научиться этому можно на курсе «Аналитик данных» в Практикуме.
