Обычно повышение зарплаты выглядит следующим образом. Способ №1, гуманитарный: сотрудник через год работы задумывается, что что-то пошло не так, и пора просить повышения. Дожидается своего локального максимума усилий, и на этой волне идёт к руководителю просить больше денег. С точки зрения теории игр это выглядит как «ну, я попросил, вдруг прокатит». Никаких доводов повышать оклад у руководителя нет.
Дальше сотрудник может поднять ставки. «Повышайте, а то уволюсь». В этой ситуации в проигрыше оказываются оба — руководитель теряет на времени обучении нового сотрудника и стоимости подбора. Сотрудник теряет на том, что может неожиданно уволиться.
Разработчики традиционно пользуются способом №2: сначала проходят где-то несколько собеседований, собирают офферы и приходят с ними к руководителю. «Смотри, вот тут мне предлагают на 20% больше, но мне у нас нравится, повышай на 15%, а то я перейду». Это уже предмет обсуждения. В банальном случае проще повысить и сохранить ценного сотрудника, но это обеспечит проигрыши в связанных играх. То есть создаст прецедент. Поэтому решение принимается (в упрощённой модели) с некоторой долей рандома.
У нас у многих математика в анамнезе. Рассматривая эту игру дальше, можно сделать простой вывод, что такой диалог для сотрудника всегда стрессовый, и он случается в момент после кризисного. То есть сначала человек беспокоится, потом делает потенциально невыгодные действия (проходит собеседования в других местах), потом приходит. Части надо повышать, части не надо. Следующий вопрос: можно ли найти функцию, которая обеспечит справедливую оценку? Будет ли эта функция снимать вот эти стрессовые ситуации?
Регулярная переиндексация каждый год — вариант такой функции. Условно, если в договоре прописано, что зарплата каждый год растёт на уровень инфляции — наверное, можно не беспокоиться. Но Вадим придумал более интересную фишку — привязать это к оценке полезности действий сотрудника для компании. Но как адекватный человек, без KPI.
Что такое полезность действий сотрудника для компании?
Противоречие в том, что руководитель хочет результата, а подчинённый — денег за своё время. В идеальном мире одно легко конвертируется в другое. В реальном мире это даже близко не так, потому что есть куча вариантов, что может пойти не по плану. Я предположу, что каждый из вас попадал в ситуацию запиливания фичи, которая потом не входила в релиз; либо же срочно-срочно-успевания к дедлайну, который оказался не так чтобы line, и не так, чтобы прям совсем dead.
Противоречие можно решить долей в компании для специалиста, но там подводных камней примерно столько же. На практике в большой компании для большинства сотрудников так не делают.
В общем, привет. Последний раз я писал про бизнес ещё когда не продали Мосигру. Дальше я начал погружаться в мрачные глубины развития внутреннего туризма в России. Надо сказать, время было подобрано идеально: с одной стороны, куда он временно сходил, вы знаете. С другой — оказалось, что прямо здесь и сейчас очень многое можно поменять. Потому что те, кто не были параноиками, умерли. Приятно работать в огромной команде с людьми, мыслящими как физики. Размер Туту ровно такой, что ещё не корпорация со всеми бюрократическими идиотизмами, но и не малый бизнес с тем, что всех знаешь поимённо. То есть идиотизмы уже есть, но они пока, скорее, забавные и управляемые. Примерно 400 человек, из которых 180 — ИТ. Руководители разного звена часто математики, бывшие разработчики или кто-то ещё, кто начал погружаться в бизнес не совсем с той стороны, где лежат софт-скиллы. И, как знакомые мне аутисты строят костыли в духе «макрос начала диалога: улыбнуться, спросить как дела, улыбаться 4 секунды, кивнуть два раза», так и в компании оказалось несколько довольно странных штук, исправляющих дефицит социальных навыков.
Короче, Вадим пил компот и вдруг придумал робота, который каждый месяц ходит требовать повышения зарплаты. Вообще, он изначально был совершенно не для этого. Давайте чуть отойдём в сторону на секундочку.
Пара аспектов руководства
Со стороны может казаться, что задача руководителя — определять, в какую сторону копать и ставить задачи. Это да. На деле же первая функция — обеспечить хорошую команду, а вторая — синхронизировать понимание внутри этой команды. Это когда речь о большой команде, а не о том, чтобы врываться впереди всех и делать такую же работу. То есть по мере развития компании или подразделения роль руководителя может меняться, но в более-менее устойчивом состоянии приоритет именно на том, чтобы сказать нужные слова нужным людям.
Коротко это работает так: без команды вы можете делать что-то только со скоростью X. Наняв 5 человек, вы получите уже скорость примерно 2X, потому что часть ресурсов уйдёт на транзакционные издержки внутри получившейся архитектуры. Например, люди крайне неэффективно договариваются, поэтому вместо коротких мысленных диалогов вы получите совещания каждый день. Я раньше думал, что есть какие-то серебряные пули, которые помогают быстро всё разрулить. Это было примерно в тот момент, когда 15-минутные совещания раз в неделю ещё казались вершиной эффективности.
Разные системы управления позволяют балансировать между уменьшением этих издержек и чёткостью выполнения задачи. «Бирюзовые» схемы, например, предполагают, что издержек очень мало, но и единства тоже.
Но к чёрту абстракции. Вот небольшая команда на продукте. Элементарный вопрос «что лучше всего сделать следующим» может вызвать лютый холивар. Самый яркий пример — переделывать архитектуру или вкручивать фичу, которую потом на новой архитектуре придётся писать с нуля. На деле таких выборов десятки каждый день, и они самого разного размера и генеза. В случае вопроса с архитектурой против новой фичи можно устроить поножовщину, можно выслушать «делаем как я сказал» от руководителя и грустно пойти писать заявление, а можно договориться между собой о максимально справедливом решении. Отдельно отмечу, что уровень справедливости у всех бывает разный. В строительстве, например, я слышал про критерий «так некрасиво», который сразу все поняли. У нас же обычно вводится какая-то оценочная функция, которая позволяет посчитать пользу от одного и от другого решения в попугаях или слонятах к определённому сроку. Это не всегда деньги, потому что есть вещи, которые в принципе померить достаточно сложно.
В общем, откуда-то берётся понимание, что именно нужно делать, как и в каком порядке. Эту мучительную процедуру я уже как-то описывал, поэтому давайте ближе к теме — переиндексации зарплаты.
А что такое эффективность сотрудника для компании?
Коротко цикл выглядит так:
- Сотрудник постоянно знает, что нужно делать.
- Руководитель знает, что сотрудник делает самое полезное в настоящий момент.
- В ответ на сделанные куски работы приходит корректирующая обратная связь.
Начали с того, что сделали отчёты, куда в конце месяца нужно отправлять три вещи: что от сотрудника требовалось, что получилось и что не получилось. Логика была в том, чтобы просто вовремя получать сводку с полей. Конец месяца, взял и отправил опросник.
И тут — хоба! — выяснилось, что далеко не всегда люди понимают, что самое ценное в их работе. То есть кто-то может неделями полировать какую-нибудь мелочь, когда следующая в списке коммерческая фича, которая будет стоить миллионы рублей. В день. Причём я сейчас буквально. Первые дни транспортного кризиса выглядели примерно так: миллионы рублей потерь. Чтобы их просто остановить, нужно сделать некий объём работы, план около полусотни пунктов. И если делать несогласованно, не по порядку, с ненужными совещаниями — всё это очень дорого обходится.
То есть необязательно, чтобы специалист понимал рынок, место компании на рынке и прочие тонкие материи. Можно просто получать ТЗ и работать по нему. Но важно делать то, что ждёт руководитель. У нас с этим были, есть и будут проблемы. Чтобы было понятно, какого рода, просто скажу, что были ситуации, когда подчинённый полгода не видел руководителя. Просто дали задачу, обеспечили всё нужное — и он сидит и делает. Как в анекдоте про пельмени. Условно, это настройка таких параметров как «в этот релиз делаем задачи медленнее, но с чистой архитектурой», «лепим костыли со скоростью света, нужен релиз в пятницу, и потом пусть всё горит огнём», «давай договоримся, что дизайнер помогает людям, а не посылает их лесом, если они не могут сформулировать задачу», «хорошо бы юристы отвечали как именно это можно сделать, а не почему так нельзя» и так далее. Ну и ещё часто люди делают то, что понимают, и что им нравится, а для всех штук с развитием (а обычно они самые ценные), надо делать что-то новое и пугающее.
То есть эффективность сотрудника — это соответствие ожиданий руководителя по его участку работы и факта. Проще говоря — когда в начале месяца можно спрогнозировать примерно, что будет результатом к концу месяца и каким способом он будет достигнут. Это называется «синхронизация ожиданий», и этот процесс нужно проходить и в личных отношениях, и в проекте, и с клиентами. Правда, в проекте можно сильно поднять градус циничности процесса.
Логичным путём казалось сделать встречи для обсуждения задач в начале каждого месяца. Связка отчёта и встречи позволяла в теории получать всё и сразу. Реальный мир, как всегда, дал по лицу тем, что это просто не взлетело. Как и везде, если вы хотите управлять каким-то параметром, для начала надо его измерить. Плюс среди прочего оказалось, что достижим офигенный результат «руководитель не поставил встречу».
То есть идею гуманитарного «ну мы как-то договоримся там» и привязки правила «как-то там происходит в первый понедельник каждого месяца в 11:00» пришлось отмести. Решение было соблазнительно лёгким, но не сработало.
Вторая модель
Во многих компаниях есть некое умолчание о том, что зарплата пересматривается раз в год. Либо индексируется на уровень инфляции, либо остаётся прежней («ну ты не очень поработал»), либо же меняется вверх. Внезапно оказалось, что люди профессионально растут не раз в год. Очевидно, надо было иметь более гибкую систему.
Логически напрашивалось увеличение частоты переоценок. Начали пересматривать результаты помесячно.
Первая версия автоматического роста зарплаты выглядела так: руководитель по оценке 0-1-2-3 оценивал сотрудника, где 0 — ниже ожиданий, 1 — в рамках, 2 — выше, 3 — удивил. Оценка равнялась повышению в процентах оклада, то есть можно было набрать как 0-0-0-0 в минимуме, так и 3-3-3-3. Повышение зарплаты в конце месяца шло постоянно на основе оценки, разовых премий за особый успех не было. Очевидная проблема появилась в том, что часто люди не понимали, на основании чего руководитель ставит оценку, что влияет на результат. По сути, это вылилось в мини-аналог особого ада под названием «оценка 360», когда руководители собирали обратную связь с окружения. То есть спрашивал коллег и клиентов — кого мог поймать. Как вы, возможно, догадываетесь, эта схема имеет такое же отношение к результату работы, как количество пиратов связано с глобальным потеплением.
В этой схеме была хороша модель автоповышения зарплаты без походов к руководителю с парой офферов в руке. Каждый месяц отчёт предполагал запрос такого повышения. Автоматически. Хорошо поработал — вот оценка. Просто поработал — вот оценка.
Проблемы были с самой оценкой. Обратная связь была примерно никакая.
Следующая ловушка называется KPI. Я насмотрелся в своё время бонусов по этой схеме, и могу сказать, что оно работает только тогда, когда систему не пытаются хакнуть. То есть примерно в +0% случаев. Либо же эти самые KPI надо менять быстрее, чем сотрудники их раскусят. Плюс через год получается демотивация, потому что «сегодня подвиг = завтра план». KPI хороши для двух вещей: для соревнований смен и для оценки эффективности в финпланировании. В случае мотивации план не лучший.
В случае компаний поменьше всё бы решалось руками, но где-то глубоко в ДНК компании — автоматизировать то, что обычно не автоматизируется. И вот Вадим предложил непривычную, но достаточно элегантную и стройную систему.
Третья модель
Следующий апдейт такой: а что, если в начале месяца установить правила игры, а в конце месяца сотрудник сам оценит себя по этим правилам?
Сделали форму в Конфлюэнсе. Кроме «что от меня ожидалось в этом месяце» сделали ещё и пункт в методологии «что ожидается в следующем месяце» — то есть сдвинули цикл на 1 такт вперёд. И запилили две оценки: одна приходит от сотрудника по итогам своего же отчёта и сравнения поставленных себе же задач месяца, вторая от руководителя.
То есть в начале месяца нужно узнать, как получить хорошую оценку. В конце месяца её получить, опираясь на ожидания, согласованные за месяц до этого. Это куда более просто, чем решение задачи «что нужно рынку».
При этом отчёты надо отправлять каждый месяц. Получается, что руководитель видит, насколько правильно каждый в команде понимает свой основной фокус. И, что очень важно, задачи формулируют сами сотрудники, — это двойная верификация. Если сформулировали не так или не туда — дальше они обсуждаются ещё раз. Для этого есть встреча по итогам вот такого самообзора.
Что важно — правила обсуждаются на берегу. Никаких «ну надо было понять, что это не так важно» — в начале месяца всё зафиксировали.
То есть:
- Сотрудник ставит себе оценку за месяц.
- Руководитель соглашается или ставит сотруднику другую оценку за месяц.
- Если оценки отличаются — они обсуждают, почему так в рамках установленного понятийного аппарата. Я знаю много примеров, где руководитель не соглашался и повышал оценку. Ну и наоборот тоже.
Сами оценки такие:
- 0 — поработал плохо
- 1 — ожидаемо хорошо
- 2 — сильно превысил ожидания
В этот момент вмешались кадры и сказали, что раз в месяц переиндексировать зарплаты — так себе план, потому что много где нужно делать всё в бумаге физически и давать кучу отчётов. Логичным компромиссом была переоценка раз в квартал. Идею квартальной оценки по результатам работы за три месяца отмели на старте: в этой ситуации оценивается только последний месяц, потому что так работает память и психология. Поэтому частота оценки помесячно, а пересчёта зарплаты и бонусов — поквартально.
Получилось, что за каждый квартал сотрудник получает три оценки: [0..2] + [0..2] + [0..2]:
- 0, 1, 2 — не молодец, квартал не удался, никаких премий и бонусов нет.
- 3, 4 — зарплата растёт на 2% со следующего месяца, разовая премия 10% и 17% соответственно от месячной зарплаты.
- 5 — зарплата растёт на 4% со следующего месяца и премия 30%
- 6 — то же самое, только премия 50% от месячной зарплаты.
Ещё есть премия за особые заслуги (условная скрытая оценка 3, которую может поставить только руководитель). Сначала назвали это «Нобелевской премией», но потом переименовали, потому что выдающиеся заслуги в кризис были, но Нобель подразумевает прорыв, а это был не всегда именно какой-то сконцентрированный удар.
По практике за квартал 3-4 в подразделениях имеют в районе двух третей сотрудников. Около 10% имеют 2 и менее за квартал, остальные — выше. Любой случай оценки за пределами коридора 3-4 — это повод сходить на перфоманс-ревью, то есть возможность несоответствия должности. Такая процедура делается раз в полгода в апреле и октябре. Приглашение на перфоманс-ревью не означает автоповышение должности или автоувольнения.
Одно из последних ревью было на предмет того, почему у сотрудника два последних квартала выглядит как 2-2-1 и 3-1-1. Оказалось, она числилась на неполную ставку, делала работу на полную в кризис, и руководитель ставил ей высокий результат. По ходу квартала перевели на полную ставку (за ту же работу). На ревью же проговорили всю ситуацию, каких-то дополнительных изменений не потребовалось.
Что выяснилось примерно за год
Система гораздо гибче KPI, поскольку учитывает повороты сюжета в реальном мире и реальный же вклад в работу с одной стороны. Ориентирована на честность сотрудников. С другой стороны — не думаю, что прокатит где-то в рознице, например, без какой-то доработки. Не подходит для потоковой повторяющейся работы типа колл-центра (там всё же разные виды выработки и KPI лучше), но очень хорошо подходит для разработки и проектной работы.
Были опасения, что руководитель может злоупотреблять оценкой. Этого опасались те, у кого плохие отношения с руководителем. Был задан логичный вопрос: а зачем тогда вообще работать в этой команде? Общее решение в том, что руководитель вообще-то заинтересован в том, чтобы сотрудники работали хорошо. Если этого не будет — ему тоже будет плохо. То есть я не уверен, что система применима к госкомпаниям.
Тем не менее, появилась дополнительная процедура: руководитель не может просто взять и поставить сотруднику оценку 0, если у него 1 или 2 в собственной. Для этого нужно согласовать такую оценку с руководителем более высокого уровня. В случае разработки — с техдиректором. С другой стороны, техдиректор должен отслеживать среднюю выработку в подразделениях и смотреть, за что ставят оценки (2) его руководители команд — потому что есть всё же некий стандарт по компании, что есть хорошая работа. Обнаружили это на том, что процент оценок (2) в одной из команд превысил треть. Начали разбираться — а это апрель, начало кризиса, и там реально превозмогали.
Оценок (3) было всего три за последние два квартала. Ввели ограничение, что их не может быть больше 5% (в количестве людей) на компанию за месяц, чтобы не размывать их ценность.
Результаты
Первое и важное — система гарантирует повышение по 2% в квартал при нормальной работе. То есть если просто делать то, что нужно, как обычно, без того, чтобы уйти в запой — есть автоповышение на 8,2% в год. Для взятия 4% повышения в квартал надо сделать что-то, что не укладывается в планы и должностные обязанности. Плюс есть разовые премии. На деле нельзя весь год брать 4%, поскольку «я огонь» означает, что либо сотрудник работает не на своей должности, и нужно повысить его до подходящего уровня некомпетентности, либо он сейчас сорвётся. Комментарии «ты от меня дальше так не жди, я так не смогу второй раз» вполне нормальны.
Из того, что хочется поправить:
- Нужна ответная система оценки руководителей подчинёнными. Тестируем варианты. Пока выглядит странно.
- Нужно делать отдельный инструмент, Конфлюэнс стал не самым удобным для аналитики — построить распределение оценок сложно пока. Автоматизировали на Джире, сейчас второй месяц после переезда.
- Нужно учиться проводить встречи каждый месяц, чтобы была методология, а не просто «ну вот, нам надо о чём-то поговорить». Это вопрос обучения руководителей.
- Была проблема миграции отчётов на первые числа следующего месяца, а встреч — на 10-е числа. Победили тем, что кадры напоминают и задалбывают. Стало понятно, что нужен бот с напоминаниями для тех, кто не скинул отчёт вовремя. В Джире такой инструмент уже есть.
- Нет чёткой методологии, как учитывать оценки за месяц, где было только 5 рабочих дней или месяца вообще не было из-за отпуска.
Плюс всё это ещё надо было смержить с ТК, который не разрешает двум одинаковым специалистам на одинаковых должностях с одинаковыми трудовыми обязанностями иметь разные оклады по штатному расписанию.
За 2-3 месяца выравнивание ожиданий произошло по всей компании.
Ну а теперь, пожалуйста, раздраконьте эту схему. Мне она кажется внезапно здравой, но подозреваю, есть лучше.
Автор: Сергей Абдульманов
