Comments 40
"Зачастую лучше чего-то не делать, чем реализовывать сомнительное решение либо делать по-другому." Достаточно спорно. Иногда сделать не то - лучший способ протестировать бизнес-гипотезу
У вас по ссылке в тестах ошибка, например если выбрать по всех ответах самый высокий балл, но в последнем вопросе (14/14. Харды - знание текущего стека) выбрать: Не знает / не делает / не могу ответить
То в рещультате появится:
Набрано баллов: 39 / 42
Грейд, с учетом ключевых * пунктов: Junior
Да, спасибо за комментарий. Действительно, если нет возможности оценить ключевой пункт, то и определить грейд не возможно, поэтому опросник "скидывает" результат в самый нижний. В случаях, если тимлид не может оценить какой-то из вопросов - мы привлекаем экспертов (коллег), которые смогут выставить свою оценку по данному пункту. Если эксперта нет - можно ориентироваться на самооценку и баллы (39 из 42 довольно высокий показатель)
Прошёл опросник. По моему отношению к рабочему процессу меня определили как среднего мидла.
Мне кажется, что здесь автор бросается из крайности в крайность. Да, хорошо, когда сотрудник сам разбирается в задаче, предлагает решения и всё такое.
Но в то же время в любой организации есть иерархическая структура. Как минимум твой непосредственный начальник должен знать, чем ты занят, какие у тебя проблемы по текущей задаче. Коллегам-программистам будет не лишним знать о изменениях архитектуры, если таковые появляются. Начальника отдела апи нужно бы поставить в изветность, что тебе нужен новый метод для твоей задачи, а просто втискивать в спринт соседнего отдела неучтённую задачу.
Потому я считаю варианты с полностью самоходной единицей неприемлемой крайностью.
Если сотрудник самоходен — это вовсе не означает, что он все делает, не привлекая никого к процессу. Конечно команда знает, чем он занят и с какими проблемами он сталкивается. Для этого у команд есть регулярные синки.
В соседнюю команду без ее уведомления также никто не пойдет вносить изменения. Просто самоходный сотрудник сможет с этой командой об этом договориться, а не будет ждать, пока за него это сделает его руководитель.
Компании и грейды в них - это в большинстве своем уникальный набор параметров которые на самом деле почти бессмысленно сравнивать. Где то будет меньше требований по тех скиллам, где то больше по софтскилам и т.д. - почти все уникально и основано на историческом опыте руководства/людей которые имею полномочия и компетенцию натягивать любую сову на любой глобус. Приравнивать на себя, тем более не работая в компании кажется интересным, но бесполезным экспериментом)
У вас в форме явная проблема с вычислениями
Hidden text
Обратите внимание на ключевые пункты (пункты со звездочкой). Если проявление пункта со звездочкой уровня Middle, то результирующий грейд не будет выше Middle, не смотря на бОльшее количество баллов. Ключевые пункты работают на "сдерживание
По моему эти грейды придуманы просто чтоб был формальный повод не повышать зарплату.
Я работал в 2х местах, где вводили грейды и всем после этого становилось понятно, что они не вырастут хорошо в ближайшие годы и это сильно увеличивало отток людей, тк зачем тратить время, если ты не сможешь вырасти.
В одном месте было необходимо для определенного уровня качать совершенно не нужные скиллы, но формально требуемые. То есть там либо делать какие то митапы, либо проводить интервью, либо менторить людей и еще с десяток активностей. В итоге все разработчики вместо улучшения продукта и работы над задачами искали пути как бы поделать что-то для повышения своего грейда, а это что-то часто шло несколько вразрез с продуктом.
Цель грейдов ровно обратная — показать, что нужно сделать, чтобы стать ценнее и повысить свой доход. За время существования этой линейки у нас уже выросли многие ребята. И за счет общей линейки удалось пересмотреть зарплату в бОльшую сторону. Когда нет общей линейки, в зависимости от того, кто ваш руководитель, вы можете быть как сильно недоплаченным, так и наоборот.
Ну и в дополнение отмечу, что нет ни одной компании, в которой все были бы удовлетворены линейкой грейдов на 100%. И это нормально.
Цель то может и такая, только реализация стреляет часто обратно. Когда внедряли грейды я часто видел, что людей, которые не соответствовали какому-то грейду увольняли. То есть выходило, что у них ЗП Была на грейд X, а по линейки они были ниже и им давали несколько недель на рост и не всегда это выходило.
вы можете быть как сильно недоплаченным, так и наоборот.
А собственно почему это вообще кого-то волнует, главное меня устраивает, сколько мне платят. Какое мне дело, что Вася делает тоже самое и получает в 2 раза больше?
Даже если кого-то и волнует, что ему недоплачивают, грейды это слабо решают для публичных компаний. Тк в публичных компаниях 1/2-3/4+ дохода сотрудников это акции и доход очень сильно зависит от курса акций. И выходит, что даже имея зарплату одинаковую, 2 сотрудника могут зарабатывать в разы по разному.
Когда внедряли грейды я часто видел, что людей, которые не соответствовали какому-то грейду увольняли. То есть выходило, что у них ЗП Была на грейд X, а по линейки они были ниже и им давали несколько недель на рост и не всегда это выходило.
Ситуация, в которой сотрудники могут оказаться переплаченными относительно грейдов - возможна. Тут скорее вопрос не в грейдах, а в том, как принимается решение, что с этим делать. Мы не рубим с плеча. Для нас сетка грейдов - это некоторый ориентир. В нашей ситуации пока вижу только подобную ситуацию, если и до грейдов сотрудником были не довольны
А собственно почему это вообще кого-то волнует, главное меня устраивает, сколько мне платят. Какое мне дело, что Вася делает тоже самое и получает в 2 раза больше?
Есть разные точки зрения на этот счет. Ранее у нас была эта проблема и ощущалась, как проблема, мы ее решили для себя через грейды
Давайте сперва подумаем, какие могут быть причины низкого перформинга, если человек опытный и обладает широким кругозором?
Первое, что приходит в голову — синьору скучно заниматься этими задачами. Такое бывает, если синьор сидит на миддловых задачах. В этом случае грейдирование может быть триггером, чтобы перейти в команду с более интересными для сотрудника задачами. Мы поддерживаем внутренние переходы, наши сотрудники знают об этом.
Бывают и другие причины — конфликт с командой, личные обстоятельства и др. Во всех случаях грейдирование будет триггером поговорить об этом и найти решение.
Интересные у вас требования к синьорам, и зарплата, наверняка, интересная. 400+ где-то, да?
оценка - это средне-арифметическое между мнением тимлида и самооценкой?
или результат торга, если оценка не сошлась
и в свете этого интересно
Если оценка после очередного цикла снижается, то мы не меняем грейд и
оплату, но говорим, где просадка, и просим подтянуть эти показатели.
Как быть, если мнение инженера и тим-лида не сошлось. Более того - оно падает
Тимлид с сотрудником проходится по каждому пункту и обсуждают , почему они поставили такую оценку, приводят примеры. Это способствует синхронизации между ними. По ходу диалога оценки как сотрудника, так и тимлида, могут меняться. На этом этапе нет торга за результирующий грейд, есть конструктивный диалог, в рамках которого они приходят к единой оценке в рамках критериев.
А калькулятор дает результирующий грейд, с ним сложно спорить. Есть ребята, которые считают, что это все профанация. Но, к счастью, подавляющее большинство удовлетворено конечным результатам. И знают, что им стоит подтянуть, чтобы шагнуть выше.
В случае, если тимлид и сотрудник вообще не могут найти общего языка и оба недовольны — у нас есть механизм эскалации до юнит-лида. Но тут возникает вопрос, как с таким не понимаем ребята могут слажено работать в рамках одной команды
какой период а оценки? как часто можно промоутится и менять грейды?
Есть ли какой-то механизм балансировки - за неверно поднятый грейд?
мы не меняем грейд и оплату
Вообще? или только в первый раз?
Период оценки — не чаще 1 раз в 3 месяца, не реже 1 раза в год. В среднем получается — раз в 6 месяцев. Пока считаем, что для того, чтобы новое поведение закрепилось, требуется не менее трёх месяцев.
Если у кого-то грейд будет понижаться — пересматривать зарплату вниз мы не будем. А будем разбираться, что изменилось.
Про "не меняем грейд и оплату" написано в контексте понижения грейда. Да, вообще не меняем грейд и оплату в меньшую сторону.
Кстати, смотрел как-то тарифные сетки в Германии на производствах где есть профсоюз, так увидел там интересную чем-то похожую систему. В некоторых землях оценка тарифной ступени ведется путем подсчета баллов по разным категориям. Например:
Обучение: от "Знания и навыки требующие единовременного обучения и короткой тренировки" (3 балла) до "требующие обширного и систематического обучения дольше полугода" (9 баллов)
Мыслительная деятельность: от "Простые задачи требующие обработку легкоусваиваемой информации" (1 балл) до "Новые комплексные задачи, требующие изобретательского и инновативного мышления с учетом долгосрочных перспектив развития" (20 баллов)
Диапазон автономности: от "Строго следует указаниям" (1 балл) и "Следует указаниям со свободой действий в рамках задачи" (7 баллов) до "Ориентируется в работе на общие цели с большой свободой действий и в широком спектре задач" (17 баллов)
Ну и все в таком духе. Таким "тестом" очень легко пользоваться. И он кажется максимально прозрачным. Думаю в Советском Союзе было что-то похожее, наверняка.
Думаю в Советском Союзе было что-то похожее, наверняка.
В Советском Союзе было два максимально прозрачных грейда. У одного было всё, у другого не было них*я.
Что по тесту, на мой взгляд, все вопросы кроме последнего относительно бессмыслены, потому что ответы на них определяются имеющимися процессами, регламентам, и политиками, а вовсе не уровнем разработчика.
> В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично
Как решается проблема с тем, что тимлид на каком-то моменте будет "прокликивать" ответы.
Например, он оценивает команду в 3й раз, надо оценить 5 человек: начинающий, 2 средних, 2 старших. Чтобы сократить время на ваш тест, он ставит начинающему первые пункты, страшим - третьи, одному среднему - вторые. И про второго среднего думает: "Он уже 3 года в команде, пора поднять уровень, пусть будет старшим". И ставит ему половину 2х пунктов, половину 3х.
Над содержанием пунктов тимлид не думает. Он знает, кто в команде какого уровня и какие ответы к этому пункту подходят.
Числовая градировка в тесте сделана неправильно, потому что можно заменить отсутствие одного балла наличием другого, и итоговая оценка останется прежней. Нужно брать, скажем, степени двойки в качестве чисел, тогда в итоговой сумме будет закодирован и вопрос на который давали ответ и ответ на этот вопрос.
Например: [синий = 1, желтый = 2, круглый=4, квадратный = 8, длинный = 16, короткий = 32]. По сумме сразу можно определить какие пункты были выбраны. Например 33 = синий, короткий, а форма выбрана не была. 26 = желтый, квадратный, длинный. И невозможно заменить ответ не поменяв сумму.
Когда формировали калькулятор - старались подобрать критерии и вопросы, чтобы они были довольно взвешены. Чтобы как раз и была возможность "обмена" одних пунктов на другие. Кто-то сильнее в одном, кто-то в другом, это нормально.
Но, чтобы не получилось, что очень софтовый разработчик, который практически не умеет программировать не стал синьором - ввели "ключевые" пункты, которые блокируют переход выше.
Вы правы, тимлид может "прокликивать" ответы. Но это не имеет особого смысла, так как:
— оценка построена таким образом, чтобы не тратить по 2 часа на оценку;
— после того, как обе анкеты заполнены - тимлиду предстоит общаться с сотрудником, приводя примеры и аргументируя свой выбор;
— у нас есть курирование оценки со стороны юнит-лида;
— у многих сотрудников есть запрос роста и развития, они будут спрашивать тимлида куда копать, и тут проще придерживаться общего фреймворка.
Так же, например, я, как юнит-лид, периодически запрашиваю фидбек, как внутри команд, так и во вне. Если вижу спорные сигналы, например, что разработчик не перформит — приду узнавать, как так получается.
Интересно, а почему не раскрыт самый важный вопрос- связь вашей системы грейдов и рыночной зарплатой?
И ещё вопрос, почему нету в системе грейдирования пункта о рыночном уровне специалиста? То есть о том уровне, на котором находится специалист по результатам собеседования в нескольких фирмах. Что бы он видел, что ваша система грейдов соответствует рыночной, а не являлась замаскированой попыткой снизить зарплату. (Правда в одном случае система ваша, как мне кажется станет немножко бесполезной- если рыночная зарплата будет выше чем ваша по результату опроса, сотрудник просто уйдёт)
У вас счётчик некорректно статус выдаёт
У меня серьёзные сомнения в верности вот этих утверждений.
"Челленджит предложения бизнеса"
"Аргументированно может убедить в том, что этого делать не нужно."
Во-первых, это работа для BA, а не SE - челленджить бизнес. Во-вторых, даже по техническим вопросам есть серьёзный опыт общения с "бизнесом" в попытках "аргументированно убедить". Тут два варианта. Если человек адекватный, он просто сделает фейспалм и выгорит скажет, что сделает так, как ему сказали. Второй вариант, если это неадекватная "звезда", он скажет, что вы мне все не подходите и уйдёт искать своего счастья в другой команде.
В нашем случае продакты очень близко к командам. И команды могут влиять на скоуп, который предстоит делать. Цели бизнеса по части заработка никто не челленджит из разработки, а вот продуктовые задачи — да.
Мы "бизнесом" называем продактов как ближайших представителей бизнеса по отношению к команде.
Если бы у нас была другая структура компании, наличие BA в каждой команде, то, вероятно, и опросник бы сильно отличался.
Многие аутстафф-компании, например, грейдируют исключительно по хард-скиллам, так как продают именно харды.
Данный опросник для грейдов - дичь. Почему-то менеджмент вместо общения с людьми и оценки их полезности пытается наиболее критичный процесс заменить и автоматизировать.
Какие цели ставились перед сотрудником, куда сотрудник хотел расти, как он вырос устраивает ли компанию и работника?
Мнеджера, который придумал этот опросник возможно стоит переключить на административную работу или работу по поддержке. Разработка она не про задачи, а про продукт, ценные и реализованные идеи, а не про выполненные задачи.
Банальная операционщина - удел администраторов.
А как вы решаете проблему несоответствия зарплаты новых и старых сотрудников?
Например, есть у вас сотрудник. Самоходный Автономный Универсальный. Работает у вас долго, по грейду - синьор, получает в силу исторических причин (условно) 250.
Вы выходите на рынок, а там за эти деньги можно нанять максимум миддла+, а такие САУ-синьоры просят 350.
Что вы делаете:
Ничего. Не стоит прогибаться под изменчивый мир. Пусть рынок соответствует нашим грейдам.
Нанимаете нового спеца по рыночной цене. И пересматриваете оплату, чтобы старые и новые спецы одного грейда получали сравнимые деньги, чтобы старые не грустили и не уходили к конкурентам.
Нанимаете нового спеца на соответствующий ему грейд по знаниям, но не по деньгам. Денег даете по рынку. Тогда не очень понятно, зачем грейды вообще, если они не соответствуют зарплате.
Нанимаете нового сотрудника на соответствующий ему грейд по деньгам. Но тогда ближайшее ревью выявит несоответствие опыта занимаемому грейду.
p.s. Без обид за придуманные за вас варианты ответов. Это дружеский намек.
А как вы решаете проблему несоответствия зарплаты новых и старых сотрудников?
Мы решаем эту проблему довольно просто - регулярно пересматриваем зарплаты всех сотрудников, а грейдирование нам в этом помогает. А чтобы наши зарплаты соответствовали рынку - регулярно пересматриваем и зарплатные вилки.
То есть в нашем случае, новые сотрудники приходят на те оклады, которые уже получают старые сотрудники.
я думаю, что и наличие и отсутсвие грейдов имеют свои плюсы и минусы.
в реальном мире во многих крупных компаниях грейды присутствуют в самых разных вариациях. при этом ожидания от каждого из грейдов у компаний могут быть разные. к примеру, то что важно для работы в условном IBM может уходить на второй план для компании, которая быстро бежит в какой-то B2C сегмент.
советую обратить внимание не на конкретные грейды, которые сейчас получились в Skyeng, а на процессы анализа, сбора ожиданий и внедрения - проделана большая и нетривиальная работа.
Отличные метрики! Хорошо показывают, что реально требуется от сеньора в живых проектах, а не на собеседованиях и задачах про быстрые сортировки или про люки
Где именно лежит граница между зарплатными грейдами: как это устроено у нас