Да настройте вы уже эти лифты…🛗

Всем привет! На связи Дима Кротов. После нескольких лет в профессии у каждого из нас появляется «профдеформация»: стоматолог первым делом смотрит прикус, дизайнер — отступы и шрифты, а аналитик… не может пройти мимо криво работающего лифта 😳

Да-да, думаю, не только я, но и многие сотрудники офисов в больших бизнес-центрах сталкиваются с трудностями использования лифтов. В нашем офисе, особенно в час-пик, добраться на лифте до нужного этажа становится очень непросто, и не только из-за толпы, но и из-за того, что лифт вдруг захотел везти тебя с первого на пятый через десятый, а по пути вниз вообще передумал, и привез на третий. Пару раз приходилось даже вести встречи из холла первого этажа)

Стоя в очередной послеобеденной очереди к лифту, я думал, как можно подойти к решению этой проблемы с аналитической точки зрения. Ведь лифт — это тот же алгоритм, задача которого собрать людей и доставить их в нужную точку, почти как тариф «Вместе» в Такси.

И вот я уже начал разгонять разные сетапы метрик для этого вечно запаздывающего механизма. На мой взгляд, набор метрик может выглядеть примерно так:

✅ Целевая: время от нажатия на кнопку до доставки на целевой этаж
🔷 Прокси: среднее время ожидания лифта, количество промежуточных остановок
🛑 Контр: доля пустых рейсов, износ лифта

А по пути можно ещё и какой-нибудь CSAT замерять🙂

Ок, а какие алгоритмы подобрать, если лифт вызывается через ввод этажа в вестибюле? У меня получилось несколько вариантов (названия я придумал сам, не судите строго):

1️⃣Batching (группировка заявок) — система собирает заявки за «интервал сбора», затем группирует людей с близкими целями в одну кабину (батчи), минимизируя число остановок и общее время поездки.

2️⃣Zoning (зональное разделение) — этажи делятся на зоны (например, 1–7, 8–14, 15–20). В зависимости от введённого пользователем этажа, система направляет его в лифт, обслуживающий именно эту зону. Это снижает количество «пересечений» между зонами и ускоряет доставку, однако разные зоны могут пользоваться разным спросом, из-за чего может простаивать свободный ресурс.

3️⃣Nearest (ближайший в своей группе) — из сгруппированных заявок система выбирает кабину, которая быстрее всех сможет забрать пассажиров и отвезти их по маршруту с минимальным «пробегом» без пассажиров.

Супер, мы близки к решению. Надо понять, как задизайнить тест.

Это оказалось непросто. Лифты работают в комплексе, и эффект от работы алгоритмов надо оценивать на целом лифтовом холле, а их у нас в бизнес-центре целых… один. Как вариант, можно сделать time‑based A/B (crossover) — переключаем всё здание между алгоритмами по дням или сменам, например: чётные/нечётные дни, утренние/вечерние смены. Или можно попробовать засетапить синтетический контроль — сконструировать его из комбинации данных других зданий или периодов, однако на практике такое сделать крайне непросто. При наличии похожих бизнес‑центров можно также попробовать сделать Difference‑in‑Difference.

Тут, конечно, придется позаботиться о логировании: фиксируем каждый вызов → поездку, промежуточные остановки, пустые рейсы, технические инциденты. Убеждаемся, что тест небесполезный: рассчитаем нужный объём выборки [кол‑во сотрудников × поездок на человека] и MDE.

На этом мой разгон закончился, так как лифт наконец-то довез меня до нужного этажа)

Как думаете, какой алгоритм был бы эффективнее? 🎯

P.S. Если вам зашла история про разбор аналитических кейсов в жизни — ставьте 🤓 и кидайте идеи задачек в чат. Разберём в следующий постах!

#ДимаКр