(не)Типичный HR

Офисные ритуалы #15. Дежурство по ротации

Представьте: три часа ночи, вы спите, а где-то в компании падает сервис.

Кто должен это заметить? Кто решает, насколько все серьезно? И главное — кто вообще будет чинить систему, пока остальные спят?

В IT для этого существует отдельная практика — on-call rotation, или дежурство по ротации.

Команда заранее составляет график, и в каждый конкретный момент есть человек, который находится "на дежурстве". Если мониторинг замечает серьезную проблему, именно ему приходит уведомление.

И да — в зависимости от компании и графика оно вполне может прийти ночью, в выходной или праздник.

Дежурный должен подтвердить, что увидел сигнал, разобраться, что произошло, начать устранять проблему или подключить нужных специалистов. Когда его смена заканчивается, ответственность переходит следующему человеку — отсюда и rotation.

Это не редкая внутренняя фишка одной компании. On-call — распространенная практика в SRE, DevOps и командах, которые отвечают за сервисы, работающие круглосуточно.

Например, в GitLab система расписана буквально по ролям и часовым поясам.

У компании есть несколько on-call-ротаций. В первой линии дежурит Engineer On Call — как правило, SRE. Если автоматический мониторинг замечает проблему с GitLab. com, первым вызывают именно его.

Есть отдельный Incident Manager On Call, который подключается для координации более сложных инцидентов, а если нужны специальные знания — можно вызвать экспертов из второй линии.

Причем GitLab использует принцип follow the sun: часть дежурств распределяется между APAC, EMEA и Америкой, чтобы круглосуточное покрытие по возможности приходилось на обычные часы бодрствования сотрудников.

Правила довольно конкретные: например, для ряда дежурств GitLab ожидает, что сотрудник подтвердит полученный сигнал в течение 15 минут. Если человек не отвечает, срабатывает заранее прописанная цепочка эскалации — зовут следующего специалиста или руководство.

А если сотрудник понимает, что в назначенную смену дежурить не сможет, для этого тоже существует процедура замены.

Похожую механику поддерживает и Atlassian: в ее системе управления инцидентами можно создавать графики on-call, назначать смены, чередовать сотрудников и прописывать, кому уйдет сигнал, если первый дежурный не отвечает.

То есть смысл ритуала не в том, чтобы заставить всю инженерную команду круглосуточно смотреть в ноутбук.

Наоборот.

В каждый момент понятно, кто именно сейчас отвечает за реакцию на аварию. Остальным не нужно жить в режиме "а вдруг что-нибудь сломается".

И здесь появляется интересная управленческая сторона.

Если один и тот же инженер постоянно просыпается в три часа ночи из-за одного и того же алерта — хороший on-call устроен не так, чтобы человек просто привык страдать.

Это сигнал: систему нужно исправлять.

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

✏️ Урок ритуала: ответственность работает гораздо лучше, когда она не размазана на "ну кто-нибудь увидит", а заранее понятно, кто, когда и что делает, если все пошло не по плану.

#ритуалы

Провальный кейс #7. Когда решили навести порядок в зарплатах

Я работала HRG в компании примерно на 150 человек. Компания быстро росла, людей нанимали в разное время, зарплаты пересматривались тоже довольно хаотично. В какой-то момент стало понятно, что дальше так нельзя.

Могли быть два человека на одинаковой должности, с примерно одинаковым опытом и задачами, но с очень разной зарплатой. Просто один пришел полтора года назад, а второго нанимали недавно и уже по другой цене рынка.

Плюс регулярно прилетали вопросы от сотрудников: что мне нужно сделать, чтобы зарабатывать больше? Почему мне подняли на 10 тысяч, а не на 20? Что вообще должно произойти, чтобы я перешел на следующий уровень?

Решили сделать нормальную систему грейдов и зарплатных вилок.

Работы там было месяца на три. Вместе с руководителями описывали уровни, разбирали роли, смотрели рынок, определяли вилки. Несколько раз все переделывали, потому что то получалось слишком сложно, то наоборот настолько общо, что смысла в этом не было.

Когда наконец закончили, я была очень довольна. Казалось, ну вот теперь хотя бы будет понятно, где кто находится и куда может расти.

А потом мы показали систему сотрудникам.

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

Кто-то был уверен, что уже давно senior, а оказался middle. Кто-то увидел, что получает почти верх своей вилки, хотя рассчитывал на серьезное повышение в ближайшее время. А один сотрудник пришел ко мне практически сразу после презентации и спросил: "То есть вы сейчас хотите сказать, что выше этой суммы я здесь получать не буду?"

Но хуже всего было с теми, чьи зарплаты оказались ниже новой вилки.

Мы, конечно, это знали еще до презентации и планировали постепенно выравнивать зарплаты. Сразу поднять всем до нужного уровня бюджет не позволял.

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

Помню разговор с одним из них. Я минут десять объясняла, как будет происходить пересмотр, почему нельзя изменить сумму прямо сейчас, какие сроки мы заложили. Он выслушал и сказал: "Я понял. Просто теперь я знаю, что мне недоплачивают".
И вот на это мне особо нечего было ответить.

Следующие несколько недель вместо вопросов «почему у нас нет понятной системы роста?» я отвечала уже на совсем другие вопросы. Почему я здесь? Почему не на следующем уровне? Почему моя вилка такая? Почему пересмотр только через четыре месяца?

В итоге грейды мы не отменили, система осталась. Но ощущения «ну наконец-то сейчас всем станет понятнее» у меня больше не было.

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

#провальныекейсы

Просто напоминание 💌

Можно не быть лучшей версией себя сегодня.

Обычно ломается не KPI.

Обычно ломается связь с реальностью.

Но цифры все еще выглядят красиво.

#какэтоломается

Иногда один человек начинает бесить буквально всех.

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

Иногда так и есть. Люди вообще бывают сложными, сюрприз.

Но если один и тот же конфликт повторяется месяцами, стоит все-таки посмотреть чуть шире. Что именно каждый раз происходит перед ним? С кем? В каких ситуациях? Почему проблема всплывает именно здесь, а в другой команде или с другим руководителем — нет?

Потому что ярлык "сложный человек" отлично объясняет все и одновременно ничего.

За ним легко не заметить руководителя, который не умеет давать обратную связь. Размытые роли. Договоренности, которые каждый понял по-своему. Или ситуацию, которую полгода никто не хотел трогать, пока она не начала раздражать уже весь отдел.

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

Даже если очень хочется.

Особенно если очень хочется.