DodoIS HR Platform: 30k человек, 1000 ресторанов, пропускная способность как дизайн

HR для сети с высокой текучестью это не задача про фичи. Это задача про пропускную способность. 30 000 человек, 1 000 ресторанов, постоянный поток найма, онбординга, увольнений. Вопрос дизайна звучит не как «что делает система», а как «что система отпускает».

В DodoIS я пришёл инженерным лидом в HR-продукт и вырос во владельца продукта. На пике платформа держала 30 000+ сотрудников, обслуживала 1 000+ ресторанов и отправляла около 100 000 персонализированных сообщений в неделю. Ни одно из этих чисел не починилось решением про фичи. Они починились серией решений про пропускную способность.

Пропускная способность сначала, фичи потом

Когда строишь под высокую текучесть, единица анализа уже не «пользователь». Это «пользователь, сменяющийся раз в полгода, половина из которых не работала нигде, где софт сложнее мессенджера». Фича, которую ты выпустишь сегодня, попадёт к людям, которых ты ещё не нанял, и обучатся они в темпе, который ты не контролируешь.

Из-за этого приоритеты выстраиваются так.

Первое. Стоимость каждого шага онбординга накапливается. Мы мерили завершение онбординга как воронку и резали агрессивно. Первая версия (досталась от предыдущего владельца) давала завершение 62% к третьему дню после найма. После двух проходов чисток и одного редизайна первого экрана этот показатель стал 89%. 27 пунктов на когорте 1 000+ человек в квартал, это серьёзное операционное время.

Второе. Каждое «дай-ка спрошу у руководителя» это налог на руководителя, а не на сотрудника. Платформа, требующая руководителя в петле для рутинных действий, масштабируется не линейно по сотрудникам. Она масштабируется по ёмкости руководителя, которая фиксирована. Мы убирали блокирующие руководителя шаги, даже когда это добавляло сложности системе.

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

Персонализированные коммуникации: админка важнее движка

Вещь, которой я больше всего доволен из додошных лет, это система персонализированных коммуникаций. 30 000+ пользователей, 100 000 сообщений в неделю, параметризованных по филиалу, региону, роли и стажу. Бэкенд DodoIS на C#/.NET, движок коммуникаций сидел поверх: очередь, шаблонизатор, адаптеры каналов.

Интересное решение там не движок. Движок это очередь, шаблонизатор и доставка. Бэкенд-команда среднего уровня собирает такое.

Сложное решение: админский слой. Мы построили его как редактор-самообслуживание, которым менеджеры филиалов и регионов пользовались напрямую, без инженера в петле. Шаблонизатор был ограниченной песочницей на Liquid: достаточно, чтобы подставить имя, филиал, роль, стаж и пару бизнес-атрибутов; недостаточно, чтобы вызвать наружу, делать арифметику над персональными данными или писать циклы, ходящие во внешнее состояние. Инженеры проверяли сегментационные примитивы, не отдельные шаблоны.

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

Где no-code провалился

Две истории, где no-code не оплатился, обе в первый год.

Первая. Мы попробовали сделать на no-code процесс probation review (испытательный срок). Оказалось, что у самого процесса нет чёткого владельца поперёк регионов: HR думал, что им владеет операционка, операционка думала, что им владеет HR. Мы построили процесс, выкатили, и три региона за две недели запустили его по-разному, потому что никто не мог решить, чей это процесс. Шесть недель работы, ушло в архив на девятой неделе. Процесс надо было сначала перепроектировать, а не сначала конфигурировать.

Вторая. Попробовали no-code на этапе передачи оборудования при увольнении. Конфигурационная поверхность оказалась богатой настолько, что её можно было неправильно настроить. Региональный менеджер собрал процесс, который тихо пропускал чек-лист возврата ноутбука для одного типа филиала. Поймали через три месяца на квартальном аудите, после того как около 40 ноутбуков ушли вместе с уволенными.

Урок: no-code это множитель того, что снизу. Если снизу хорошо, x5. Если снизу сломано или владельца нет, x5 быстрее ошибаешься. Откатились с «настраиваемого процесса» на «инженерно-проверяемый процесс с конфигурационной поверхностью» для всего, что трогает оборудование, деньги или комплаенс.

Вовлечённость как отдельный продукт, а не вкладка

Пульс-опросы, индекс удовлетворённости, аналитика по регионам, магазин мерча, конкурсы. Можно было собрать вкладками в одном HR-приложении. Мы разделили на независимые поверхности с общим identity, по той же причине, по которой в LOOV разделили мобильное приложение: ментальное состояние сотрудника, открывающего пульс-опрос, отличается от состояния того, кто листает мерч.

Раздельные поверхности позволили ставить эксперименты на каждой. Магазин мерча итерировал петли удержания независимо от опросного инструмента. Опросник итерировал ритм и длину, не задевая коммуникации. У каждой была маленькая выделенная команда и чёткий KPI.

Что переживает смену владельца

Я ушёл с роли примерно через три года. Платформа осталась и росла. Инженер, заменившая меня как владельца продукта, человек, с которым я работал с первого года. Её первое решение: задепрекейтить две фичи, которые я двигал.

Это было правильно. Эти фичи остались с первого года, и данные по пропускной способности показывали, что они не оправдывают своего места. Я бы их не убил, она убила. Тот факт, что она смогла, и что центр дизайна выстоял без моего его защищания, это и есть настоящая мера платформы.