А как вы решаете проблему несоответствия зарплаты новых и старых сотрудников?
Мы решаем эту проблему довольно просто - регулярно пересматриваем зарплаты всех сотрудников, а грейдирование нам в этом помогает. А чтобы наши зарплаты соответствовали рынку - регулярно пересматриваем и зарплатные вилки.
То есть в нашем случае, новые сотрудники приходят на те оклады, которые уже получают старые сотрудники.
Когда формировали калькулятор - старались подобрать критерии и вопросы, чтобы они были довольно взвешены. Чтобы как раз и была возможность "обмена" одних пунктов на другие. Кто-то сильнее в одном, кто-то в другом, это нормально.
Но, чтобы не получилось, что очень софтовый разработчик, который практически не умеет программировать не стал синьором - ввели "ключевые" пункты, которые блокируют переход выше.
Когда внедряли грейды я часто видел, что людей, которые не соответствовали какому-то грейду увольняли. То есть выходило, что у них ЗП Была на грейд X, а по линейки они были ниже и им давали несколько недель на рост и не всегда это выходило.
Ситуация, в которой сотрудники могут оказаться переплаченными относительно грейдов - возможна. Тут скорее вопрос не в грейдах, а в том, как принимается решение, что с этим делать. Мы не рубим с плеча. Для нас сетка грейдов - это некоторый ориентир. В нашей ситуации пока вижу только подобную ситуацию, если и до грейдов сотрудником были не довольны
А собственно почему это вообще кого-то волнует, главное меня устраивает, сколько мне платят. Какое мне дело, что Вася делает тоже самое и получает в 2 раза больше?
Есть разные точки зрения на этот счет. Ранее у нас была эта проблема и ощущалась, как проблема, мы ее решили для себя через грейды
Тут варианта два - либо написать, что мы не можем понять грейд, так как ключевой пункт не оценен, либо отталкиваться от нижнего уровня (jun). Как лучше?
В нашем случае продакты очень близко к командам. И команды могут влиять на скоуп, который предстоит делать. Цели бизнеса по части заработка никто не челленджит из разработки, а вот продуктовые задачи — да. Мы "бизнесом" называем продактов как ближайших представителей бизнеса по отношению к команде.
Если бы у нас была другая структура компании, наличие BA в каждой команде, то, вероятно, и опросник бы сильно отличался. Многие аутстафф-компании, например, грейдируют исключительно по хард-скиллам, так как продают именно харды.
Вы правы, тимлид может "прокликивать" ответы. Но это не имеет особого смысла, так как: — оценка построена таким образом, чтобы не тратить по 2 часа на оценку; — после того, как обе анкеты заполнены - тимлиду предстоит общаться с сотрудником, приводя примеры и аргументируя свой выбор; — у нас есть курирование оценки со стороны юнит-лида; — у многих сотрудников есть запрос роста и развития, они будут спрашивать тимлида куда копать, и тут проще придерживаться общего фреймворка.
Так же, например, я, как юнит-лид, периодически запрашиваю фидбек, как внутри команд, так и во вне. Если вижу спорные сигналы, например, что разработчик не перформит — приду узнавать, как так получается.
Период оценки — не чаще 1 раз в 3 месяца, не реже 1 раза в год. В среднем получается — раз в 6 месяцев. Пока считаем, что для того, чтобы новое поведение закрепилось, требуется не менее трёх месяцев.
Если у кого-то грейд будет понижаться — пересматривать зарплату вниз мы не будем. А будем разбираться, что изменилось.
Про "не меняем грейд и оплату" написано в контексте понижения грейда. Да, вообще не меняем грейд и оплату в меньшую сторону.
Тимлид с сотрудником проходится по каждому пункту и обсуждают , почему они поставили такую оценку, приводят примеры. Это способствует синхронизации между ними. По ходу диалога оценки как сотрудника, так и тимлида, могут меняться. На этом этапе нет торга за результирующий грейд, есть конструктивный диалог, в рамках которого они приходят к единой оценке в рамках критериев.
А калькулятор дает результирующий грейд, с ним сложно спорить. Есть ребята, которые считают, что это все профанация. Но, к счастью, подавляющее большинство удовлетворено конечным результатам. И знают, что им стоит подтянуть, чтобы шагнуть выше.
В случае, если тимлид и сотрудник вообще не могут найти общего языка и оба недовольны — у нас есть механизм эскалации до юнит-лида. Но тут возникает вопрос, как с таким не понимаем ребята могут слажено работать в рамках одной команды
Давайте сперва подумаем, какие могут быть причины низкого перформинга, если человек опытный и обладает широким кругозором?
Первое, что приходит в голову — синьору скучно заниматься этими задачами. Такое бывает, если синьор сидит на миддловых задачах. В этом случае грейдирование может быть триггером, чтобы перейти в команду с более интересными для сотрудника задачами. Мы поддерживаем внутренние переходы, наши сотрудники знают об этом.
Бывают и другие причины — конфликт с командой, личные обстоятельства и др. Во всех случаях грейдирование будет триггером поговорить об этом и найти решение.
Цель грейдов ровно обратная — показать, что нужно сделать, чтобы стать ценнее и повысить свой доход. За время существования этой линейки у нас уже выросли многие ребята. И за счет общей линейки удалось пересмотреть зарплату в бОльшую сторону. Когда нет общей линейки, в зависимости от того, кто ваш руководитель, вы можете быть как сильно недоплаченным, так и наоборот.
Ну и в дополнение отмечу, что нет ни одной компании, в которой все были бы удовлетворены линейкой грейдов на 100%. И это нормально.
Обратите внимание на ключевые пункты (пункты со звездочкой). Если проявление пункта со звездочкой уровня Middle, то результирующий грейд не будет выше Middle, не смотря на бОльшее количество баллов. Ключевые пункты работают на "сдерживание
Если сотрудник самоходен — это вовсе не означает, что он все делает, не привлекая никого к процессу. Конечно команда знает, чем он занят и с какими проблемами он сталкивается. Для этого у команд есть регулярные синки.
В соседнюю команду без ее уведомления также никто не пойдет вносить изменения. Просто самоходный сотрудник сможет с этой командой об этом договориться, а не будет ждать, пока за него это сделает его руководитель.
Да, спасибо за комментарий. Действительно, если нет возможности оценить ключевой пункт, то и определить грейд не возможно, поэтому опросник "скидывает" результат в самый нижний. В случаях, если тимлид не может оценить какой-то из вопросов - мы привлекаем экспертов (коллег), которые смогут выставить свою оценку по данному пункту. Если эксперта нет - можно ориентироваться на самооценку и баллы (39 из 42 довольно высокий показатель)
Статья не про то, что мы изобрели работу с инцидентами, а про то как мы это применили. Про прикладной подход. Про то, что не нужно ставить специальный софт и заводить специалиста, если требуется начать уже сейчас.
Конечно мы знакомились с теорией ITIL и практиками других компаний. Просто мы взяли то, чего нам было на том этапе достаточно.
И спасибо за комментарий
Для производителя проще сделать смарт типа a1200 на андройде (обычный сенсор, прикрытый крышкой), нежели чем танцевать вокруг управления андройдом только физическими кнопками.
Мы решаем эту проблему довольно просто - регулярно пересматриваем зарплаты всех сотрудников, а грейдирование нам в этом помогает. А чтобы наши зарплаты соответствовали рынку - регулярно пересматриваем и зарплатные вилки.
То есть в нашем случае, новые сотрудники приходят на те оклады, которые уже получают старые сотрудники.
Когда формировали калькулятор - старались подобрать критерии и вопросы, чтобы они были довольно взвешены. Чтобы как раз и была возможность "обмена" одних пунктов на другие. Кто-то сильнее в одном, кто-то в другом, это нормально.
Но, чтобы не получилось, что очень софтовый разработчик, который практически не умеет программировать не стал синьором - ввели "ключевые" пункты, которые блокируют переход выше.
Ситуация, в которой сотрудники могут оказаться переплаченными относительно грейдов - возможна. Тут скорее вопрос не в грейдах, а в том, как принимается решение, что с этим делать. Мы не рубим с плеча. Для нас сетка грейдов - это некоторый ориентир. В нашей ситуации пока вижу только подобную ситуацию, если и до грейдов сотрудником были не довольны
Есть разные точки зрения на этот счет. Ранее у нас была эта проблема и ощущалась, как проблема, мы ее решили для себя через грейды
О специфике расчетов упомянуто в аннотации к тесту. Вероятно, перенесем это пояснение под расчет, чтобы было более понятно.
Тут варианта два - либо написать, что мы не можем понять грейд, так как ключевой пункт не оценен, либо отталкиваться от нижнего уровня (jun). Как лучше?
В нашем случае продакты очень близко к командам. И команды могут влиять на скоуп, который предстоит делать. Цели бизнеса по части заработка никто не челленджит из разработки, а вот продуктовые задачи — да.
Мы "бизнесом" называем продактов как ближайших представителей бизнеса по отношению к команде.
Если бы у нас была другая структура компании, наличие BA в каждой команде, то, вероятно, и опросник бы сильно отличался.
Многие аутстафф-компании, например, грейдируют исключительно по хард-скиллам, так как продают именно харды.
Вы правы, тимлид может "прокликивать" ответы. Но это не имеет особого смысла, так как:
— оценка построена таким образом, чтобы не тратить по 2 часа на оценку;
— после того, как обе анкеты заполнены - тимлиду предстоит общаться с сотрудником, приводя примеры и аргументируя свой выбор;
— у нас есть курирование оценки со стороны юнит-лида;
— у многих сотрудников есть запрос роста и развития, они будут спрашивать тимлида куда копать, и тут проще придерживаться общего фреймворка.
Так же, например, я, как юнит-лид, периодически запрашиваю фидбек, как внутри команд, так и во вне. Если вижу спорные сигналы, например, что разработчик не перформит — приду узнавать, как так получается.
Период оценки — не чаще 1 раз в 3 месяца, не реже 1 раза в год. В среднем получается — раз в 6 месяцев. Пока считаем, что для того, чтобы новое поведение закрепилось, требуется не менее трёх месяцев.
Если у кого-то грейд будет понижаться — пересматривать зарплату вниз мы не будем. А будем разбираться, что изменилось.
Про "не меняем грейд и оплату" написано в контексте понижения грейда. Да, вообще не меняем грейд и оплату в меньшую сторону.
Тимлид с сотрудником проходится по каждому пункту и обсуждают , почему они поставили такую оценку, приводят примеры. Это способствует синхронизации между ними. По ходу диалога оценки как сотрудника, так и тимлида, могут меняться. На этом этапе нет торга за результирующий грейд, есть конструктивный диалог, в рамках которого они приходят к единой оценке в рамках критериев.
А калькулятор дает результирующий грейд, с ним сложно спорить. Есть ребята, которые считают, что это все профанация. Но, к счастью, подавляющее большинство удовлетворено конечным результатам. И знают, что им стоит подтянуть, чтобы шагнуть выше.
В случае, если тимлид и сотрудник вообще не могут найти общего языка и оба недовольны — у нас есть механизм эскалации до юнит-лида. Но тут возникает вопрос, как с таким не понимаем ребята могут слажено работать в рамках одной команды
Давайте сперва подумаем, какие могут быть причины низкого перформинга, если человек опытный и обладает широким кругозором?
Первое, что приходит в голову — синьору скучно заниматься этими задачами. Такое бывает, если синьор сидит на миддловых задачах. В этом случае грейдирование может быть триггером, чтобы перейти в команду с более интересными для сотрудника задачами. Мы поддерживаем внутренние переходы, наши сотрудники знают об этом.
Бывают и другие причины — конфликт с командой, личные обстоятельства и др. Во всех случаях грейдирование будет триггером поговорить об этом и найти решение.
Цель грейдов ровно обратная — показать, что нужно сделать, чтобы стать ценнее и повысить свой доход. За время существования этой линейки у нас уже выросли многие ребята. И за счет общей линейки удалось пересмотреть зарплату в бОльшую сторону. Когда нет общей линейки, в зависимости от того, кто ваш руководитель, вы можете быть как сильно недоплаченным, так и наоборот.
Ну и в дополнение отмечу, что нет ни одной компании, в которой все были бы удовлетворены линейкой грейдов на 100%. И это нормально.
Обратите внимание на ключевые пункты (пункты со звездочкой). Если проявление пункта со звездочкой уровня Middle, то результирующий грейд не будет выше Middle, не смотря на бОльшее количество баллов. Ключевые пункты работают на "сдерживание
Если сотрудник самоходен — это вовсе не означает, что он все делает, не привлекая никого к процессу. Конечно команда знает, чем он занят и с какими проблемами он сталкивается. Для этого у команд есть регулярные синки.
В соседнюю команду без ее уведомления также никто не пойдет вносить изменения. Просто самоходный сотрудник сможет с этой командой об этом договориться, а не будет ждать, пока за него это сделает его руководитель.
Да, спасибо за комментарий. Действительно, если нет возможности оценить ключевой пункт, то и определить грейд не возможно, поэтому опросник "скидывает" результат в самый нижний. В случаях, если тимлид не может оценить какой-то из вопросов - мы привлекаем экспертов (коллег), которые смогут выставить свою оценку по данному пункту. Если эксперта нет - можно ориентироваться на самооценку и баллы (39 из 42 довольно высокий показатель)
Вы абсолютно правы если команда работает над гипотезами. А если речь про реализацию "постоянных" задач, то подход меняется
Конечно мы знакомились с теорией ITIL и практиками других компаний. Просто мы взяли то, чего нам было на том этапе достаточно.
И спасибо за комментарий