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