Меня зовут Ксения Зайцева и я старший бизнес-аналитик в компании «ДАР». Я хотела бы поделиться кейсом, который поможет начинающим тимлидам заранее предусмотреть проблемы из разряда «вроде всё понятно, но что-то не сходится».
В HR-аналитике есть метрики, которые «должны считаться просто»: выбрать статус, взять дату, посчитать кандидатов. На практике такие истории иногда заканчиваются нулём, потом несколькими миллиардами, а потом неделей расследований — как вообще устроены данные и почему всё это работает.
Мы с таким встречались – дальше расскажу, где именно в нашем кейсе ломалась логика и как искать контрпримеры, когда цифры выглядят правдоподобно, но не сходятся.
Итак, история. Однажды мы пересобирали уже существующие дашборды по подбору персонала для крупной промышленной компании и начали с самого несложного показателя — количества найденных кандидатов.
Задача на старте выглядела несложной:
· перевести дашборды в общий контур к другим дашбордам нашей системы
· доработать витрины
· немного изменить визуальное отображение, чтобы все смотрелось гармонично
Решено было начать с самого понятного – изучить текущие дашборды, чтобы перенести их логику в новую систему.
Приключение на 20 минут, вошли и вышли?
С чего мы начали
Первое знакомство с дашбордами слегка охладило наш энтузиазм.
Оказалось, что документации не существует, доступ к редактированию дашбордов есть только у одного разработчика, а внутри дашбордов – код на тысячи строк.
Этот код создавал промежуточные таблицы, технические поля, делал предрасчёты и считал всё на лету. Читать это было сложно – особенно нам, аналитикам, не самым большим экспертам по DAX.
Следующий шаг казался очевидным – если мы не можем быстро разобраться в логике, значит нужно просто спросить заказчиков, как именно должны считаться метрики в «идеальном мире».
Перед встречей я изучила текущие дашборды, составила список метрик, набросала гипотезы о том, как они считаются, и принесла всё это на встречу.
Почти час мы обсуждали первый показатель, Количество найденных кандидатов. После встречи у меня был исчерканный блокнот и много новых знаний о процессе подбора, но крайне слабое понимание того, как именно считать метрику – и сходимся ли мы в этом вопросе с заказчиком.
Тем не менее логика казалась очевидной:
· уникальные люди
· уникальные вакансии
· статус «Новый»
· считаем по дням
· агрегируем как сумму
На практике же всё оказалось немного сложнее.
Первая проверка данных
После этого мы решили сверить результаты с существующим дашбордом.
Написали скрипт для расчёта. Сначала классически получили ноль, потом – несколько миллиардов.
После пары исправлений и учета технических полей цифра стала похожа на правду – около 35 новых кандидатов в день для одного из предприятий.
На существующем дашборде мы увидели 40 и с облегчением выдохнули – почти сошлись! Подумаешь, дельта в 10%.
Дальше план был простой:
· выгрузить список наших 35 кандидатов
· отправить его заказчикам
· найти потерянных пятерых
Но на этом этапе выяснилось кое-что неожиданное.
Когда источник не помогает
Очень быстро выяснилось, что проверить данные напрямую почти невозможно.
Система-источник оказалась довольно ограниченной в этом плане: максимум можно было выгрузить большую таблицу и дальше разбираться с ней вручную.
Нам выгрузили такую таблицу, и моим любимым методом пристального взгляда быстро выяснилось, что:
· даты в выгрузке могут быть неправильными (иногда расходились на сутки, иногда больше)
· из-за этого отбор по дате фильтрует не все, что нужно
· использовать эту выгрузку для полноценной проверки почти невозможно
В итоге кандидатов для конкретной даты приходилось собирать буквально руками, но даже это не давало полной уверенности в результате. Довольно быстро стало понятно, что проблема не только в формуле, а в самих данных. Задача «пересчитать метрику» в какой-то момент превратилась в попытку разобраться – а что вообще происходит в данных?
Что ломало метрику?
После нескольких подходов стало понятно, что проблем у нас сразу несколько.
1. Даты.
На дашборде есть возможность фильтровать данные по произвольному периоду. При анализе кандидатов возникает классический вопрос: какую дату мы должны учитывать?
Если использовать дату статуса кандидата, мы теряем людей, которые были добавлены раньше, но всё ещё находятся в процессе подбора – в какой-то момент часть кандидатов просто исчезает из метрики, и вместе с ними начинает меняться конверсия в найм.
2. Особенности процесса.
Мы нашли в базе кандидатов, которые сразу попадали на этап интервью, минуя этап «Новый». Оказалось, в системе такое возможно для старых периодов и не является ошибкой – таких кандидатов также нужно учитывать.
3. Большое количество дублей.
Оказалось, что в историю кандидатов пишутся все изменения – даже если в вакансии изменили ее плановую дату закрытия или один из тегов. Вакансии могут несколько раз переоткрываться, а кандидат может откликнуться на несколько вакансий, даже на разные предприятия.
После того как мы показали заказчику несколько таких кейсов из базы, стало понятно, что исходную логику придётся менять. В итоге мы пришли к более устойчивому варианту: фильтруем по дате только вакансии и показываем всех кандидатов, связанных с ними.
Почему дашборд работал и не вызывал вопросов?
В какой-то момент возник вопрос – почему старая версия дашборда не вызывала серьёзных вопросов?
Причин оказалось несколько.
Во-первых, в системе-источнике нет удобных средств для проверки данных. Чтобы проверить цифры, нужно вручную:
1. найти вакансию, которая подходит под все требования
2. посмотреть всех кандидатов для нее
3. повторить это десятки раз для всех вакансий
4. повторить это в следующем месяце
Теоретически звучит хорошо, но на практике этим обычно занимаются только очень мотивированные (или имеющие много свободного времени) люди.
Во-вторых, дашборд содержал внутри себя очень сложную логику:
· промежуточные таблицы
· предрасчёты
· технические поля
Скорее всего, когда-то эта логика работала корректно, но со временем из-за объёма данных и небольших изменений процесса начала давать сбои.
И самое главное – пользователи дашборда обычно знают примерный порядок цифр. Если цифры выглядят правдоподобно, дашборду продолжают доверять – помним об описанной выше проблеме со сбором значений из источника, с которой обычно никто не хочет связываться.
Что я вынесла из этой истории?
В аналитике есть знакомая многим ситуация – метрика, которая давно считается и никем не проверяется.
Она может выглядеть правдоподобно и не вызывать вопросов, но при этом скрывать внутри множество допущений:
· особенности бизнес-процесса
· структуру данных
· историю изменений
Из-за этого при малейших попытках что-то изменить или просто разобраться в логике можно наткнуться на айсберг, о котором исходно и не подозревали.
Показалось важным и еще одно наблюдение – не стоит полностью полагаться на описание метрики от заказчика.
Не потому, что заказчик ошибается, а потому, что он обычно рассказывает о процессе, а не о данных.
Когда мы обсуждали показатель «количество найденных кандидатов», разговор шёл о том, как работает подбор:
-
когда кандидат считается найденным
-
какие этапы есть в процессе
-
что происходит дальше
Но в данных этот процесс отражается совсем иначе:
-
статусы могут ставиться не так, как ожидается
-
этапы могут пропускаться
-
один кандидат может быть связан с несколькими вакансиями
-
история изменений создаёт дубли
В итоге описание процесса и реальная логика данных могут сильно отличаться. Методику расчета приходится разбирать, проверять на данных и иногда даже переопределять вместе с заказчиком.
Что делать, если завтра вам нужно перепроверить «простую» метрику
Теперь у нас есть набор «проверь себя», к которому мы теперь возвращаемся почти в каждом похожем кейсе.
Во-первых, не стоит ограничиваться словами – лучше сразу смотреть реальные данные. Если заказчик говорит «нам нужно считать новых кандидатов», полезно попросить показать несколько живых примеров в системе и посмотреть, как эти кандидаты на самом деле выглядят в данных. Часто уже на этом этапе появляются первые несоответствия.
Во-вторых, имеет смысл посчитать метрику самым простым способом – например, вывести список кандидатов в Excel и посмотреть на результат. Отсортировать, найти выбросы, посмотреть на странные случаи – кандидатов с десятком вакансий, даты из будущего или неожиданные статусы. Такие аномалии обычно очень быстро указывают на проблемы в логике.
Отдельный вопрос – это уникальность. В HR почти всегда есть риск «двойного счёта», поэтому важно заранее понять, что именно мы считаем: людей или отклики. Один человек, который подался на несколько вакансий, – это один кандидат или несколько?
Не менее важны даты. Дата создания кандидата, дата изменения статуса, дата вакансии – все они дают разные результаты, и выбор «не той» даты может серьезно изменить все расчеты.
И наконец, если есть возможность, полезно хотя бы один раз сделать ручную сверку: например, взять конкретный день и подразделение и вместе с рекрутером проверить список кандидатов.
В целом после таких разборов начинаешь относиться ко всем метрикам немного осторожнее – обычно за ними скрывается гораздо больше деталей, чем кажется на первый взгляд.
И если попытаться это как-то сократить до одного правила, оно звучит примерно так:
если показатель кажется вам очевидным и очень простым, скорее всего, вы пока ещё не нашли пример, который все сломает.
ссылка на оригинал статьи https://habr.com/ru/articles/1041122/