Предыдущие части: Часть 1
Другие лучшие практики
Далее я привожу вымышленные сценарии, рассматривая общие стратегии, которые менеджеры должны использовать, чтобы не навредить своей Data-команде.
2) Ищите «Систематические ошибки выжившего» (survivorship bias)
(Популяризовано превосходной книгой How Not to be Wrong)
Задача: B2B софтверная компания готовит свою «дорожную карту». Их главная цель перейти от первых 200 до тысячи клиентов.
Метод: они создают и распространяют опрос среди пользователей. 20% опрошенных проголосовали за добавление некой функции в будущем.
Вывод: «этот анализ поможет нам выиграть больше, определив приоритетность набора функций, желаемого клиентами».
Проблема: эта методология хорошо подходит целям удержания или увеличения суммы покупки. Но целью было привлечение новых клиентов. Метод измерил точно не ту аудиторию. Он опросил людей, которые уже купили продукт, а не тех, кто этого не сделал. Чтобы приблизится к цели, им нужно вместо этого услышать, почему люди не покупали.
3) Оценивайте эффективность, а не контрольную группу
Задача: менеджер хочет узнать сможет ли SLA (соглашение о предоставлении услуги) увеличить среднее время ответа на предложениеSDR (специальные права заимствования).
Метод: менеджер устанавливает внутреннее SLA, все входящие запросы получают подробное предложение в течение 24 часов. Data-специалисты моделирует среднее время отклика, с учетом рабочих часов, и создают дашборд.
Вывод: «время на ответ снизилось! SLA работает!»
Проблема: все, что вы знаете, у ваших SDR было меньше входящих в последнее время, поэтому их очереди просто были короче, что объясняет более быстрое время отклика. Возможно ли, что они почти всегда встречаются с SLA, и все это случается в периоды высокой нагрузки?
4) Не забудьте про издержки
Задача: компания хочет проанализировать эффективность функции ‘Related Items’, чтобы увеличить количество покупок.
Метод: A/B тестирование проверяет функцию на странице продукта, которая предлагает заказать дополнительный артикул. Data-инженеры создают и вносят в дашборд новый KPI.
Вывод: «люди добавляют дополнительный артикул! Значит нам следует инвестировать в функцию ‘Related Items’, чтобы увеличить добавления в корзину».
Проблема: предположим, что полное построение функции на основе A/B тестирования занимает 3 недели и создает на 8% больше многопозиционных покупок, во всех продуктах. Мы оправдываем вложения в новую функцию упуская из виду альтернативные издержки. Каждый день мы сжигаем деньги на аренду, зарплату и так далее. Что если та же команда вместо этого создаст «bundle-комплекты» за 4 недели, и это потенциально увеличит многопозиционные покупки на 200%. Чем мы занимаемся, тратя время на ‘Related Items’?!?!
5) Всегда признавайте предположения
Задача: финансовый директор должен определить сколько менеджеров по расчету зарплаты нанять для поддержки нового рынка (Канада)
Метод: Data-команда использует цифры из продаж для прогнозирования спроса. Затем моделируют рост численности персонала, и определяют сколько сотрудников требуется для расчета зарплат.
Вывод: «до тех пор, пока мы не достигнем целевого уровня продаж, один работник может справится с постепенно растущими потребностями в заработной плате для новых сотрудников на новом рынке в течение следующих шести месяцев»
Проблема: мы признали, что слишком быстрый рост может повлиять на нашу оценку. Но важное предположение мы упустили [потребность в зарплате на новом рынке будет примерно равной потребностям на существующих].Как насчет валюты? Налоговое законодательство? Может быть у каждого сотрудника будет в два раза больше работы!
6) Вопрос статистической значимости
Задача: три кандидата на должность инженера отклонили письма с предложением в течение одного квартала. HR менеджер хочет выяснить, как получать меньше отказов.
Метод: представитель HR опросил каждого, почему они отказались. Все три ссылаются на возможность «оказывать большее влияние в небольшой команде». Кому нужна Data-команда в наше время?
Вывод: «мы в проигрыше только тогда, когда кандидатов не информируют что наши субкоманды гибкие и не зависимые. Наша инженерная команда из 40 человек воспринимается подавляюще. Мы должны делать акцент на небольших субкомандах, и избегать вопросов о размере общей инженерной команды»
Проблема: достаточно ли данных, чтобы сделать вывод? Нулевая гипотеза: «если бы мы упомянули небольшие подгруппы, кандидаты никогда бы не отказались». Вам не нужно напоминать о P-значении (P-value), чтобы спросить: «это вообще нормально»? Иногда вы поворачиваете голову пять раз подряд.
7) Ищите недостающие данные
Задача: у команды CX менеджера есть ранние/поздние смены; они хотят назначить лучших агентов на смену с самыми тяжелыми и срочными проблемами.
Метод: Data-команда распределяет темп роста обращений в службу поддержки на смены, и на дашборде видно эти сегменты с течением времени
Вывод: «наши самые срочные проблемы распределяются так: 55% ночью/45% днем. Значит нам нужно распределить наших лучших людей в обе смены».
Проблема: просто глядя на срочные письма мы не видим всей картины. Мы забыли посчитать звонки на телефон доверия агенту, которые, вероятно, покажут сколько срочных вопросов приходит. Возможно, они чаще поступаю к вечеру и в сочетании с данными электронной почты, это аргумент за назначение лучших сотрудников в ночную смену?
8) Остерегайтесь ложного выбора
Задача: компания хочет исследовать аппетит клиентов к потенциальным новым моделям ценообразования для своего основного продукта.
Метод: в опросе предлагают выбрать, какой новый вариант им больше нравится.
Вывод: 80% опрошенных, из 5 вариантов выбрали вариант №3. Это явный победитель.”
Проблема: как насчет всех вариантов, которые не были в вашем опросе? Что, если бы они хотели выбрать более одного варианта (и 75% также выбрали бы вариант №2). Что если ста процентам текущие цены нравятся больше, чем новые варианты?
Вывод
Не думайте, что наём доктора наук и инвестирование «тонны» времени в «модную математику» спасёт вашу Data-команду. Во время редактирования статьи, мой бывший коллега (и data all star) Райан Бреннан мудро сформулировал, что все эти примеры-просто проблемы абстракции. Когда мы представляем идеи с ежедневными числами, бремя ответственности должно быть на владельце бизнеса, чтобы гарантировать, что представления являются точными. Не уклоняйся от своего долга. Не настраивайте свою команду на провал.
Перевод статьи Michael Muse: 8 Ways To Set Up A Data Team for Success
