Привет! Меня зовут Рамиля. Я лидирую маркетинговые исследования в Додо. Обычно я общаюсь с гостями, но однажды меня попросили оценить, насколько участники нашей IT-команды довольны инструментами Data Platform.
Об этом кейсе я и расскажу в статье, а в конце приложу гайд для тех, кто захочет провести подобное исследование в своей команде, и ссылку на реальный опрос. Начнём с запроса, с которым ко мне обратились:
«Есть потребность на опрос пользователей data-платформы, хочется замерить удовлетворённость использованием разных инструментов, качеством данных, удобством и скоростью, и получить ряд болей по инцидентам, неудобствам, проблемам. Это поможет выделить ключевые проекты и инициативы по улучшениям, а в дальнейшем отследить эффект от нововведений с точки зрения изменения оценок и метрик удовлетворённости»
Задача — получить метрики (критерии и цифры), которые бы показали удовлетворённость сотрудников инфраструктурой data-платформы. Также заказчик выделил 2 сегмента, оценку которых важно получить: специалисты, работающие с данными, и пользователи, изучающие отчёты и дашборды.
Быстрый осмотр вариантов подобных замеров в других компаниях не привёл к положительному результату: обычно используются базовые метрики типа CSI и NPS, которые не раскрывают реальных проблем. Это как градусник, который показывает высокую температуру, но не раскрывает причин жара.
Заказчики хотели оценить инфраструктуру по следующим критериям: удовлетворённость использованием различных инструментов, качество данных, удобство и скорость работы. Конкретных метрик не было, поэтому на первом этапе логично было сфокусироваться на поиске чётких критериев оценки опыта сотрудников и сформулировать их. Так что я решила не ограничиваться одним опросом и начала с качественного исследования — серии интервью —, чтобы собрать боли пользователей.
Шаг 1. Проведение интервью
Начала с лидеров команд, которые знакомы с особенностями работы нашей Data Platform. Вместе мы выделили верхнеуровневые проблемы: ошибки в данных, медленную скорость работы, ограниченный функционал SuperSet и т.д. Так я поняла, что сегментация на тех, кто работает с данными, и тех, кто изучает отчёты и дашборды — слишком широкая. Да и лидеры могут не знать обо всех проблемах. Нужно погрузиться в боли каждой из ролей: аналитиков, инженеров, маркетологов, бизнес-девелоперов.
Далее самые сложные для меня роли: аналитики и инженеры. С одной стороны, я не специалист по работе с данными. С другой — в этом и мой плюс: ребята рассказывали мне о своих проблемах, а я не могла за них ничего додумать. Задавала вопросы, частенько глупые, о расписании их рабочего дня: что делают? Что занимает много времени? Что просто бесит? На этом шаге было важно понять, какие задачи выполняют сотрудники на своих ролях, а также сложности и блокеры, с которыми они сталкиваются.
Ниже представлена таблица, где показаны вопросы и примеры из нашего кейса:
Вопрос | Что важно получить | Пример из нашего кейса |
Чем ты занимаешься? Из чего состоит твой рабочий день? | Связка «роль – работа» | Data-аналитик преобразует event’ы, создаёт витрины. Инженер собирает витрины и отлаживает процессы, чтобы оптимизировать расходы. |
С какими сложностями ты сталкиваешься? | Верхнеуровневый список болей | Не всегда есть события, которые необходимо преобразовать. Отсутствие правил нейминга, стилизации кода, диаграмм. Встречаются витрины с похожими названиями. Уходит много времени на поиск нужной базы, разбор чужого кода. Функционал SuperSet ограничен. Приходится тратить больше сил и времени на базовые задачи. |
Что занимает у тебя очень много времени? | Проблемы-блокеры, которые влияют на скорость работы | Получение доступов. Не всегда есть описание того, как получить доступ, часто это бывает завязано на человеке. Процесс получения доступа воспринимается как «квест на несколько дней». Нет доверия к качеству данных. Сначала сотрудники подозревают проблемы в своём коде и тратят время на его проверку. Но со временем они перестают сомневаться в коде и сразу винят качество данных. |
Что больше всего тебя раздражает? | Список эмоционально окрашенных болей. При этом они могут не занимать много сил и времени. | Вынужденное ожидание «апрува» кода. Непонятно, кто несёт ответственность за качество данных. |
Как ты обычно решаешь такие проблемы? | Способы решения | Решение одно — написать в канал data-инженеров или «Дашборды». Сотрудники долго ждут ответов, а инженеры тратят время на рутинные задачи вместо продуктивной работы. Это демотивирует команду и снижает эффективность использования ресурсов. |
Неожиданно для меня оказалось, что люди на разных ролях и в разных командах могут выполнять одинаковую работу. Например, инженеры и аналитики могут преобразовывать ивенты. А значит... Сегментация по ролям тоже слишком широкая. Придётся оценивать опыт сотрудника на каждом этапе работы с данными — от ивента до дашборда. Из них я выделила следующие:
преобразую ивенты и/или дотягиваю данные до silver;
использую данные из silver и gold;
использую данные из Kusto;
создаю витрины;
строю дашборды в SuperSet;
смотрю готовые дашборды.
Позже появилась просьба оценить ещё и опыт заказчиков, которые ставят ad-hoc задачи продуктовым и data-аналитикам. Поэтому я провела ещё несколько бесед с маркетологами и бизнес-девелоперами. Им я задавала всё те же вопросы, всё с теми же целями: собрать боли, блокеры и эмоционально-окрашенные сложности.
Шаг 2. Формулируем боли
Во время бесед я собрала список проблем, которые раздражают сотрудников и/или отнимают у них время, для всех сегментов. Так, например, выглядят проблемы ребят, преобразующих ивенты:
нет понятного описания процессов, ответственных;
нет событий, которые необходимо дотянуть до bronze;
сделал(а) по шаблону, возникла ошибка, не знаю, что делать;
данные некорректные, с ошибками;
не могу автоматизировать расчёты и обновления;
долгие расчёты (при создании и/или обновлении);
долгое ожидание ответа коллег и заказчиков;
приходится разбираться с качеством данных, хотя это не моя основная работа;
доступ к данным: не знаю, как получить, долго искать и получать.
Шаг 3. Формулируем метрики из болей
Теперь можно перейти к самому интересному и важному — преобразованию болей в метрики. Например, проблема «не понимаю, как получить доступ» превращается в метрику «Доступность (данные и доступы есть, я знаю, где их найти)».
Я старалась сделать так, чтобы метрики разных сегментов звучали одинаково. Например, понятность — общая метрика, но на этапе создания ивентов мы говорим о понятности природы данных, метрик, описания таблиц, а на этапе просмотра дашбордов — о понятности описания дашбордов и показателей.
В таблице ниже указаны боли аналитиков и маркетологов, а также формулировки метрик для обоих сегментов:
Боль аналитиков | Боль маркетологов | Метрика для аналитиков | Метрика для маркетологов |
Долгие расчеты при создании и/или обновлении | Медленно обновляется дашборд | Скорость инструментов. Всё работает быстро | Скорость. Всё работает быстро |
Сделал(а) в первый раз по шаблону, возникла ошибка, не знаю, что делать | Не понимаю, как рассчитываются показатели, как вообще читать дашборд | Порог входа (насколько легко начать работать с данными с настоящими описаниями таблиц и процессов) | Порог входа (насколько легко начать работать с дашбордами) |
Нет понятного описания процессов, ответственных | Если мне нужен дашборд, но я не знаю, существует ли он, я спрашиваю у обеих аналитических команд. Если такого дашборда нет, ставлю задачу на его создание | Доступность. Данные и доступы есть, знаю, где их найти | Доступность. Дашборды и доступы есть, знаю, где их найти |
Приходится разбираться с качеством данных, хотя это не моя основная работа. Нет доверия к качеству данных | Нет доверия к качеству данных. В дашбордах часто бывают ошибки | Качество данных. Нет дублей, нет ошибок | Качество данных. Все показатели корректные, без ошибок |
Шаг 4. Соберём опрос
Полученные боли и метрики необходимо собрать в опрос, чтобы отправить коллегам. Примеры вопросов, которые вы можете задать, я оставила в Google Docs. А сам опрос, который вы можете пройти как респондент — по ссылке в Oprosso.
Я собирала опрос на сервисе Oprosso. Можно также использовать Google Forms, JotForm, TypeForm и «Анкетолог». Выберите тот сервис, где можно настроить логику перехода между вопросами и их отображение в зависимости от предыдущих ответов.
Первый вопрос — о роли сотрудника, очевидно, с одиночным выбором. Вряд ли ваши сотрудники совмещают 2 или 3 роли. Второй — о задачах сотрудников, с множественным выбором. Настройте логику для него: от ответов будет зависеть отображение следующих вопросов.
Для общей оценки удовлетворённости работой выбрала эмодзи-вопрос и добавила описание. Если у вас такого нет, используйте вопрос с текстовыми вариантами ответов.
Для оценки основных показателей я использовала шкалу рейтинга. На основе данных, полученных с её помощью, будет легче посчитать среднее значение и долю положительных оценок.
Для оценки важности барьеров использовала матрицу. Она выглядит громоздкой, поэтому в опросах для гостей её нет — они отвечают с телефона. Но сотрудники будут проходить опрос на больших экранах в рабочее время, сложностей не возникнет.
Шаг 5. Собираем и анализируем результаты
Готовый опрос мы разослали по рабочим чатам команд и несколько раз напомнили о том, что его нужно пройти. Результаты проанализировал data-аналитик. Были рассчитаны следующие показатели:
количество ответов в разных сегментах;
средние значения показателей в целом и по сегментам.
Используйте столбчатые, линейчатые (с накоплением и без), лепестковые диаграммы для визуализации результатов. Также вы можете искусственно объединить и проанализировать ответы в разрезе более крупных сегментов: команда данных и пользователи из бизнеса. Вот примеры графиков, которые мы использовали в своём отчёте:
В результате наш аналитик выделил основные проблемы, которые требуют наибольшего вовлечения, а лидеры команд прописали пути их решения:
Часть изменений уже внедрена. Например, аналитики провели публичную приоритизацию задач и обновили процесс сбора ad-hoc запросов. Лидеры команд расставили приоритеты, заложили задачи в OKR и использовали результаты опроса для согласования бюджетов и ресурсов. Главное — коллеги перестали обсуждать и начали уверенно решать проблемы. Чего и вам желаем.
Гайд по шагам
Теперь сам гайд. В нём я кратко перечислю этапы создания опроса. Он будет полезен тем, кто хочет в виде метрик оценить, насколько их сотрудники удовлетворены инфраструктурой.
Сегментация. Выделите сегменты сотрудников. Удобно использовать роли (data-аналитик, продуктовый аналитик, инженер, маркетолог) или задачи, которые они выполняют (преобразуют ивенты, создают дашборды и т.д.).
Качественное исследование — интервью. Проведите его с парой сотрудников из каждой группы, которую вы выделили в предыдущем шаге. Для проведения интервью по возможности привлеките стороннего человека. С ним респондентам будет проще делиться болями, чем с коллегой.
Проанализируйте интервью. Соберите список болей и сложностей каждой группы.
Из этих сложностей и болей выделите метрики, по которым можно оценивать удовлетворённость условиями работы.
Создайте опрос на сервисе Google Forms, JotForm, «Опроссо», TypeForm или «Анкетолог». Поделитесь ссылкой на опрос с сотрудниками.
Соберите данные, проанализируйте результаты (средние значения, доли положительных оценок), соберите их в понятный отчёт. Используйте различные методы визуализации.
Обсудите результаты в команде, превратите полученные инсайты в гипотезы или конкретные решения и действия.
Повторите опрос в следующем квартале. Оцените, есть ли положительная динамика в метриках.
Поделитесь, как вы замеряете удовлетворённость своих сотрудников, коллег и пользователей технических инструментов. Буду рада прочесть ваши комментарии и предложения по такой оценке. Нам ещё предстоит вторая волна замера, а значит мы успеем её улучшить.