Сколько в компании разработчиков, столько примерно и мнений. Например, где именно проходит граница между мидлом и синьором? Нам нужен был справедливый инструмент оценки, который помогает понять, не получает ли наш специалист зарплату меньше, чем должен был бы. И, самое главное, что нужно делать для того, чтобы развиваться.
В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично, есть грейд и зарплата в нём (у нас по три уровня внутри каждого грейда, например, джун-джун, опытный джун и джун 80-го уровня). Если оценки не совпадают — начинается процесс переговоров с приведением примеров для синхронизации по части оценки и ожиданий, чтобы потом на следующей итерации они всё-таки совпали.
Пока мы попробовали этот подход на 120 разработчиках. Выглядит многообещающе. Но я хотел бы показать вам сам опросник, детали системы и обсудить, насколько прозрачной получилась такая система. Дальше в посте — предпосылки её создания, разбор каждого из параметров и ссылка на форму, которая показывает результат по нашей системе грейдов.
Почему мы не грейдируем только по хардам
Итак, основной смысл грейдирования — платить больше тем, кто приносит больше пользы компании. Многие компании предпринимают попытку грейдировать только по хард скиллам. При этом польза, приносимая сотрудником, имеет зависимость от уровня хардов, но на деле нужно смотреть шире. Например, мы ожидаем от синьора не только архитектурных решений и высокого качества кода, но и понимания, что же требуется бизнесу.
Подготовку опросника для проведения грейдирования я начал с того, что опубликовал опрос на всю разработку, чтобы понять, кто для нас синьор и чем, собственно, он отличается от мидла. Мне нужно было собрать общую массу мнений самих разработчиков, чтобы выделить наиболее часто упоминаемые качества.
Из опроса удалось получить большой список факторов, которые влияют на уровень именно с точки зрения разработчиков.
Основное, в чём сходились почти все опрошенные, — это то, что мы позже назвали «самоходность», то есть умение решить задачу самостоятельно. Или, если точнее, целиком и полностью реализовать задачу с достаточным качеством в разумные сроки и при этом понимать, что в задаче важно бизнесу и почему, на какие метрики будут смотреть продакты и какие технические метрики важно собирать. Второй наиболее часто упоминаемый фактор — это «технический кругозор», под которым мы понимаем владение текущим техническим стеком. Мы решили, что без двух этих качеств разработчик в принципе не может быть синьором. А позднее к ним добавились ещё «понимание бизнес-проблемы» и «умение действовать в условиях неопределённости».
Что убрали из оценки
Следующий шаг — я посмотрел на значимость каждого критерия, которые получились в результате опроса, а потом постарался выкинуть то, что не влияет на успешность решения задач в описанном выше ключе, чтобы сделать опросник простым и справедливым.
Как это ни странно, ушла из списка коммуникация с коллегами и заказчиком. Да, коммуникация с коллегами очень важна, но мы не можем на её основании определить грейд. Плюс у нас есть достаточно общие вопросы, которые косвенно включают в себя это проявление. Важно помнить, что грейд — это про уровень решения задач, про результативность. Если синьор токсичный, то это не значит, что он не может классно решить задачу. Это значит, что, возможно, мы просто не будем готовы с ним работать, но это не повод снижать грейд.
Также вылетели из списка клиентоориентированность, регулярность поставки изменений (это скорее про декомпозицию крупных задач) и многое другое.
В общем и целом осталось только то, что характеризует именно компетенцию. Получилось 14 базовых критериев, они представлены ниже.
Давайте их и разберём.
Опросник
Первая версия опросника, естественно, была собрана в гугл-документах, чтобы начать собирать данные и получать быструю обратную связь. На этой форме мы прожили более полугода, прежде чем начали переход в другой интерфейс.
Тут всё просто: самоходность — показатель автономности в решении задач в рамках своей компетенции. Конечно, мы не ожидаем, что разработчик сам придумает продукт, нарисует дизайн и займётся продажами. Мы ожидаем, что разработчик задаст необходимые вопросы продакту по проблеме и решению, спроектирует задачу, а дальше сможет оценить её, разложить по спринтам и проконтролировать её путь от начала разработки до успешной выкладки в прод. И всё это — в адекватные сроки. Мидлов в такой парадигме нужно контролировать от спринта к спринту, а джунов — регулярно в течение спринта. Синьоры могут прекрасно самостоятельно справляться с задачами, но это не означает, что они не могут и не должны поднимать какие-то вопросы и приходить за консультациями.
Один из важных аспектов контроля — это понимать, что разработчик не тратит много времени на реализацию какой-то известной библиотечной функции, не изобретает велосипед и не городит костыль там, где есть нормальное решение. Думаю, вы сталкивались с тем, что бывает, когда какой-то вопрос, который у опытного разработчика занимает полчаса, джун тихо и упорно решает пару недель.
Как и в следующих пунктах, тут нет какой-то объективной оценки вроде подсчёта частоты задаваемых вопросов, вполне хватает субъективной самооценки тимлида, и она по тестам оказывается довольно точна.
Это второй определяющий критерий для синьора в наших условиях. Если нет умения решать задачу в ситуации неопределённости, то перед нами — исполнитель, работающий преимущественно по ТЗ. А синьор — это тот, кто может выяснить и решить, как надо делать. Кто-то может справедливо отметить, что это может делать PM, но не стоит забывать, что критерии отличаются от компании к компании исходя из внутренней культуры.
Простую типовую задачу «под ключ» может решить и джуниор, а вот в случае, когда бизнес приходит и говорит «хотим сделать, чтобы вот так», часто надо придумать решение, которое не только «сделает вот так», но и выбрать архитектуру, понять, кого это может задеть внутри компании и на что ещё может повлиять, договориться с инфраструктурой, смежными командами и так далее, а потом уже сказать, какие есть варианты и чем они отличаются. Это похоже на аналитику задачи, но включает в себя умение искать оптимальное решение в локальной ситуации.
Ещё один пример неопределённости — это когда нужно что-то поправить, а никто не знает, где вообще эти правки вносить.
Понимание проблемы — это ответ на вопрос, зачем, собственно, решается эта задача. Разница принципиальна: если просто реализовывать ТЗ, то может быть выбрана не та архитектура. Или вообще может выясниться, что задачу в таком виде решать не надо, потому что есть другой путь. И опытный специалист должен его показать.
Конечно, бывают разные проектные менеджеры. Для некоторых важно, чтобы то, что они сказали, было сделано именно так, как они хотят. Но мы считаем, что такое слепое следование ТЗ обычно говорит о недостаточном понимании бизнес-задачи и имеет больше негативных последствий. Очень часто нужно делать не прямо по хотелкам, а чуть больше, чуть иначе и вообще обсуждать эти решения и их последствия. Но аргументированно.
А это уже навык аргументированного обсуждения, дополняющий прошлый пункт. И смысл не в том, чтобы порождать бессмысленные споры на ровном месте, а в том, чтобы видеть, предлагать и доносить разумные альтернативы.
Зачастую лучше чего-то не делать, чем реализовывать сомнительное решение либо делать по-другому.
Стратегическое мышление — это черта сильного специалиста с богатым кругозором и насмотренностью. Синьор будет проектировать решение, которое закрывает среднесрочные и долгосрочные цели бизнеса без дополнительных крупных затрат. Конечно, не всегда так получается, но пытаться важно. Хорошо, если специалист об этом думает и регулярно проявляет эту черту.
Очень часто бывает, что приходит бизнес, говорит: «А покрасьте вот эту кнопку в красный». Джун возьмёт и покрасит через костыль. Мидл сделает отдельный класс красных кнопок и позволит ставить их там, где надо бизнесу. Синьор спросит, как часто нужно красить кнопки, зачем, какие ещё есть цвета, и, возможно, даст возможность бизнесу самому выбирать цвет кнопки без того, чтобы ходить в разработку.
Межкомандная работа — это наша специфика и временами боль, поэтому этот критерий попал в опросник. У нас много команд и много пересекающегося функционала. Охотно верю, что в других компаниях не так, но мы ждём от своих синьоров умения организовывать работу над межкомандными задачами. Чтобы они брали ответственность на себя, собирали тех, кто нужен для решения, раскручивали цепочку, как решать, и решали, а не просто оставляли задачу болтаться, «потому что непонятно, кто у них там должен».
То есть по факту у нас нельзя стать синьором, не имея хоть одной задачи, решённой на стыке команд.
В данном пункте нам интересно, как проявляется реакция на ошибку на проде. Думаю, что по формулировке пунктов опросника понятно, где для нас проходит разница. В отличие от предыдущего пункта не обязательно иметь опыт крупного падения в своей биографии: вполне может оказаться, что ошибок на проде специалист просто не допускал, как правило, в командах это видно сразу.
Это, пожалуй, самая субъективная оценка нашего опросника, потому что измеряется исключительно по ощущениям руководителя. Здесь мы оцениваем, насколько эффективно сотрудник выполняет задачи, с учётом скорости, количества решённых задач и качества их исполнения. Понятно, что в идеале надо сводить метрики по всей компании и сравнивать всех со всеми.
Сразу уточню, что перформинг на разных проектах и в разных командах может сильно отличаться. В нашей системе нет понижения грейдов, то есть если разработчик однажды показал хороший результат в одном из критериев (стабильно на протяжении нескольких месяцев), то вниз мы его не переоцениваем. Поэтому, если перформинг упал, мы думаем о том, что могло пойти не так в команде, руководстве или процессе.
Для оценки перформинга можно смотреть на количество закрытых задач, суммарное затраченное время, среднюю погрешность оценки и медиану погрешности оценки.
Этот пункт — про внимательность и ответственность за состояние задачи на момент её передачи в тестирование. Если разработчик считает, что его задача — «код писать, а не тестить» и передаёт её QA без проверки, то увеличивается нагрузка на тестировщика, а жизненный цикл задачи растягивается, так как она возвращается на доработку.
Пока для простоты оценки выбрали метрику «кол-во возвратов задачи после тестирования», но, как уже подсвечивали коллеги из некоторых команд, такая метрика не всегда объективна. Например, у QA могут быть проблемы с инфраструктурой, а не кодом. Поэтому как альтернатива метрике — это дойти до QA и узнать, насколько качественно сделаны задачи, передаваемые в тестирование.
На старте нового проекта или реализации большой задачи опытный разработчик закладывает архитектуру, которая долгое время позволяет гибко реагировать на запросы бизнеса. Этот критерий дополняет «стратегическое мышление», но там больше про потребности бизнеса и риски, а тут — про реализацию.
Тут, думаю, всё понятно.
У нас есть процесс технического ревью — это когда команда обсуждает и планирует конкретное техническое решение задачи. В разных компаниях данный процесс называется по-разному, но, как правило, суть одна.
Опытный разработчик уделяет много внимания этапу подготовки и планирования задачи, так как в этот момент даже крупные изменения будут значительно дешевле, чем на более поздних этапах.
Code Review — устоявшаяся практика в разработке, поэтому она тоже попала в оценку.
Знание стека — это суммарная оценка хардов по каждой части используемого стека, она проводится отдельно и просто заносится в опросник как один из пунктов. Важно, что нельзя стать синьором, не обладая глубоким пониманием технологий и умением применять их на практике.
Недостатки
Первая особенность в том, что у начинающего тимлида в команде по итогам оценки может оказаться больше синьоров, чем у опытного, поскольку его будет легче убедить в наличии отсутствующего навыка из-за субъективности оценки. В таких случаях рекомендуется проводить опросник в формате 270 градусов (самооценка, оценка руководителя, оценка коллеги или той роли, которая может оценить).
Вторая особенность — не все навыки объективно могут проявиться в конкретной команде. Например, у нас достаточно команд, которые работают полностью автономно без взаимодействия с кем-то ещё, и там нельзя показать ту же компетенцию межкомандного взаимодействия. Мы предполагаем, что разработчик, который поймёт, что хочет расти дальше, сможет при необходимости перейти в команду, где такая практика есть, просто чтобы получить нужный опыт. Либо сможет затащить какие-то проекты на уровне юнита или компании, находясь в своей команде.
Третья особенность — сами критерии достаточно субъективны: сразу стало заметно, что пункты начинают трактоваться по-разному. Сейчас выравниваем эту трактовку через добавление примеров.
Если оценка после очередного цикла снижается, то мы не меняем грейд и оплату, но говорим, где просадка, и просим подтянуть эти показатели. Это защита от субъективных колебаний и влияния атмосферы разных команд на разных проектах. В идеале синьор в одной команде будет синьором и в другой. Но никто не застрахован, что в другой команде он будет непродуктивен. Это либо изменение условий, либо конфликты в команде, либо некорректная предыдущая оценка. В любом случае это решается за пределами системы грейдов.
В итоге у нас есть рабочая модель, которая проверена на 120 разработчиках. Для них это справедливое ранжирование по деньгам, для компании — ещё и возможность прогнозировать бюджет. Для тимлидов — возможность показать сотруднику, в чём лучше развиваться внутри команды, и синхронизировать ожидания от роли.
Безусловно, не все приняли систему оценки с распростёртыми объятиями, был и ярко выраженный негативный фидбэк. Важно понимать, что оценка — процесс меняющийся, и требуется регулярно его обновлять и корректировать исходя из ситуации. Поэтому мы периодически собираем обратную связь и вносим коррективы.
Вот здесь за пять минут можно пройти опросник и оценить, какой грейд был бы у вас в Skyeng.
Комментарии (32)
AndreySu
26.05.2022 11:41+1У вас по ссылке в тестах ошибка, например если выбрать по всех ответах самый высокий балл, но в последнем вопросе (14/14. Харды - знание текущего стека) выбрать: Не знает / не делает / не могу ответить
То в рещультате появится:Набрано баллов: 39 / 42
Грейд, с учетом ключевых * пунктов: Junior
dmkuznetsov Автор
26.05.2022 13:27-1Да, спасибо за комментарий. Действительно, если нет возможности оценить ключевой пункт, то и определить грейд не возможно, поэтому опросник "скидывает" результат в самый нижний. В случаях, если тимлид не может оценить какой-то из вопросов - мы привлекаем экспертов (коллег), которые смогут выставить свою оценку по данному пункту. Если эксперта нет - можно ориентироваться на самооценку и баллы (39 из 42 довольно высокий показатель)
lxsmkv
27.05.2022 11:19Вариант "Знает теорию, мало практики" получается, по той же причине расценивается как " Не знает / не делает / не могу ответить" ? Потому что выбор первой позиции в 14-ом вопросе так же "сбрасывает" категорию до самой нижней.
igosja
26.05.2022 13:36Прошёл опросник. По моему отношению к рабочему процессу меня определили как среднего мидла.
Мне кажется, что здесь автор бросается из крайности в крайность. Да, хорошо, когда сотрудник сам разбирается в задаче, предлагает решения и всё такое.
Но в то же время в любой организации есть иерархическая структура. Как минимум твой непосредственный начальник должен знать, чем ты занят, какие у тебя проблемы по текущей задаче. Коллегам-программистам будет не лишним знать о изменениях архитектуры, если таковые появляются. Начальника отдела апи нужно бы поставить в изветность, что тебе нужен новый метод для твоей задачи, а просто втискивать в спринт соседнего отдела неучтённую задачу.
Потому я считаю варианты с полностью самоходной единицей неприемлемой крайностью.
dmkuznetsov Автор
26.05.2022 15:10Если сотрудник самоходен — это вовсе не означает, что он все делает, не привлекая никого к процессу. Конечно команда знает, чем он занят и с какими проблемами он сталкивается. Для этого у команд есть регулярные синки.
В соседнюю команду без ее уведомления также никто не пойдет вносить изменения. Просто самоходный сотрудник сможет с этой командой об этом договориться, а не будет ждать, пока за него это сделает его руководитель.
abbath0767
27.05.2022 11:00+1Компании и грейды в них - это в большинстве своем уникальный набор параметров которые на самом деле почти бессмысленно сравнивать. Где то будет меньше требований по тех скиллам, где то больше по софтскилам и т.д. - почти все уникально и основано на историческом опыте руководства/людей которые имею полномочия и компетенцию натягивать любую сову на любой глобус. Приравнивать на себя, тем более не работая в компании кажется интересным, но бесполезным экспериментом)
Flying
26.05.2022 16:08+2У вас в форме явная проблема с вычислениями
Hidden text
dmkuznetsov Автор
26.05.2022 18:38Обратите внимание на ключевые пункты (пункты со звездочкой). Если проявление пункта со звездочкой уровня Middle, то результирующий грейд не будет выше Middle, не смотря на бОльшее количество баллов. Ключевые пункты работают на "сдерживание
Flying
26.05.2022 20:07+4Тогда налицо проблема с пояснениями. Зачем публиковать соотношение баллов и грейдов, если пользователь в итоге видит картину, не совпадающую с заявленной? Или хотя бы стоит упомянуть о специфике рассчёта, о которой вы пишете.
billyevans
26.05.2022 19:29+3По моему эти грейды придуманы просто чтоб был формальный повод не повышать зарплату.
Я работал в 2х местах, где вводили грейды и всем после этого становилось понятно, что они не вырастут хорошо в ближайшие годы и это сильно увеличивало отток людей, тк зачем тратить время, если ты не сможешь вырасти.
В одном месте было необходимо для определенного уровня качать совершенно не нужные скиллы, но формально требуемые. То есть там либо делать какие то митапы, либо проводить интервью, либо менторить людей и еще с десяток активностей. В итоге все разработчики вместо улучшения продукта и работы над задачами искали пути как бы поделать что-то для повышения своего грейда, а это что-то часто шло несколько вразрез с продуктом.
dmkuznetsov Автор
27.05.2022 11:41Цель грейдов ровно обратная — показать, что нужно сделать, чтобы стать ценнее и повысить свой доход. За время существования этой линейки у нас уже выросли многие ребята. И за счет общей линейки удалось пересмотреть зарплату в бОльшую сторону. Когда нет общей линейки, в зависимости от того, кто ваш руководитель, вы можете быть как сильно недоплаченным, так и наоборот.
Ну и в дополнение отмечу, что нет ни одной компании, в которой все были бы удовлетворены линейкой грейдов на 100%. И это нормально.
billyevans
27.05.2022 19:41Цель то может и такая, только реализация стреляет часто обратно. Когда внедряли грейды я часто видел, что людей, которые не соответствовали какому-то грейду увольняли. То есть выходило, что у них ЗП Была на грейд X, а по линейки они были ниже и им давали несколько недель на рост и не всегда это выходило.
вы можете быть как сильно недоплаченным, так и наоборот.
А собственно почему это вообще кого-то волнует, главное меня устраивает, сколько мне платят. Какое мне дело, что Вася делает тоже самое и получает в 2 раза больше?
Даже если кого-то и волнует, что ему недоплачивают, грейды это слабо решают для публичных компаний. Тк в публичных компаниях 1/2-3/4+ дохода сотрудников это акции и доход очень сильно зависит от курса акций. И выходит, что даже имея зарплату одинаковую, 2 сотрудника могут зарабатывать в разы по разному.
WolfTheGrey
26.05.2022 20:49А мне интересно послушать более детально аргументацию касательно скорости работы. Я понимаю, бизнес, time to market, но получается это ключевой навык и по вашей оценке, если не «поспеваешь», то и не миддл/сеньор, даже если набрал много-много лет опыта и широкий кругозор.
dmkuznetsov Автор
27.05.2022 11:56+1Давайте сперва подумаем, какие могут быть причины низкого перформинга, если человек опытный и обладает широким кругозором?
Первое, что приходит в голову — синьору скучно заниматься этими задачами. Такое бывает, если синьор сидит на миддловых задачах. В этом случае грейдирование может быть триггером, чтобы перейти в команду с более интересными для сотрудника задачами. Мы поддерживаем внутренние переходы, наши сотрудники знают об этом.
Бывают и другие причины — конфликт с командой, личные обстоятельства и др. Во всех случаях грейдирование будет триггером поговорить об этом и найти решение.
egor_nullptr
26.05.2022 20:53+2Интересные у вас требования к синьорам, и зарплата, наверняка, интересная. 400+ где-то, да?
MMgo
27.05.2022 00:07оценка - это средне-арифметическое между мнением тимлида и самооценкой?
или результат торга, если оценка не сошлась
и в свете этого интересно
Если оценка после очередного цикла снижается, то мы не меняем грейд и
оплату, но говорим, где просадка, и просим подтянуть эти показатели.Как быть, если мнение инженера и тим-лида не сошлось. Более того - оно падает
dmkuznetsov Автор
27.05.2022 12:43Тимлид с сотрудником проходится по каждому пункту и обсуждают , почему они поставили такую оценку, приводят примеры. Это способствует синхронизации между ними. По ходу диалога оценки как сотрудника, так и тимлида, могут меняться. На этом этапе нет торга за результирующий грейд, есть конструктивный диалог, в рамках которого они приходят к единой оценке в рамках критериев.
А калькулятор дает результирующий грейд, с ним сложно спорить. Есть ребята, которые считают, что это все профанация. Но, к счастью, подавляющее большинство удовлетворено конечным результатам. И знают, что им стоит подтянуть, чтобы шагнуть выше.
В случае, если тимлид и сотрудник вообще не могут найти общего языка и оба недовольны — у нас есть механизм эскалации до юнит-лида. Но тут возникает вопрос, как с таким не понимаем ребята могут слажено работать в рамках одной команды
MMgo
27.05.2022 00:12какой период а оценки? как часто можно промоутится и менять грейды?
Есть ли какой-то механизм балансировки - за неверно поднятый грейд?
мы не меняем грейд и оплату
Вообще? или только в первый раз?
dmkuznetsov Автор
27.05.2022 12:45Период оценки — не чаще 1 раз в 3 месяца, не реже 1 раза в год. В среднем получается — раз в 6 месяцев. Пока считаем, что для того, чтобы новое поведение закрепилось, требуется не менее трёх месяцев.
Если у кого-то грейд будет понижаться — пересматривать зарплату вниз мы не будем. А будем разбираться, что изменилось.
Про "не меняем грейд и оплату" написано в контексте понижения грейда. Да, вообще не меняем грейд и оплату в меньшую сторону.
lxsmkv
27.05.2022 02:26Кстати, смотрел как-то тарифные сетки в Германии на производствах где есть профсоюз, так увидел там интересную чем-то похожую систему. В некоторых землях оценка тарифной ступени ведется путем подсчета баллов по разным категориям. Например:
Обучение: от "Знания и навыки требующие единовременного обучения и короткой тренировки" (3 балла) до "требующие обширного и систематического обучения дольше полугода" (9 баллов)
Мыслительная деятельность: от "Простые задачи требующие обработку легкоусваиваемой информации" (1 балл) до "Новые комплексные задачи, требующие изобретательского и инновативного мышления с учетом долгосрочных перспектив развития" (20 баллов)
Диапазон автономности: от "Строго следует указаниям" (1 балл) и "Следует указаниям со свободой действий в рамках задачи" (7 баллов) до "Ориентируется в работе на общие цели с большой свободой действий и в широком спектре задач" (17 баллов)
Ну и все в таком духе. Таким "тестом" очень легко пользоваться. И он кажется максимально прозрачным. Думаю в Советском Союзе было что-то похожее, наверняка.
nronnie
27.05.2022 11:13+2Думаю в Советском Союзе было что-то похожее, наверняка.
В Советском Союзе было два максимально прозрачных грейда. У одного было всё, у другого не было них*я.
Что по тесту, на мой взгляд, все вопросы кроме последнего относительно бессмыслены, потому что ответы на них определяются имеющимися процессами, регламентам, и политиками, а вовсе не уровнем разработчика.
anitspam
27.05.2022 03:17> В итоге мы сделали опросник из 14 пунктов, по которому за несколько минут можно оценить себя. То же самое делает про вас тимлид, и если оценки совпадают, то всё отлично
Как решается проблема с тем, что тимлид на каком-то моменте будет "прокликивать" ответы.
Например, он оценивает команду в 3й раз, надо оценить 5 человек: начинающий, 2 средних, 2 старших. Чтобы сократить время на ваш тест, он ставит начинающему первые пункты, страшим - третьи, одному среднему - вторые. И про второго среднего думает: "Он уже 3 года в команде, пора поднять уровень, пусть будет старшим". И ставит ему половину 2х пунктов, половину 3х.
Над содержанием пунктов тимлид не думает. Он знает, кто в команде какого уровня и какие ответы к этому пункту подходят.
lxsmkv
27.05.2022 11:37Числовая градировка в тесте сделана неправильно, потому что можно заменить отсутствие одного балла наличием другого, и итоговая оценка останется прежней. Нужно брать, скажем, степени двойки в качестве чисел, тогда в итоговой сумме будет закодирован и вопрос на который давали ответ и ответ на этот вопрос.
Например: [синий = 1, желтый = 2, круглый=4, квадратный = 8, длинный = 16, короткий = 32]. По сумме сразу можно определить какие пункты были выбраны. Например 33 = синий, короткий, а форма выбрана не была. 26 = желтый, квадратный, длинный. И невозможно заменить ответ не поменяв сумму.
dmkuznetsov Автор
27.05.2022 12:52Вы правы, тимлид может "прокликивать" ответы. Но это не имеет особого смысла, так как:
— оценка построена таким образом, чтобы не тратить по 2 часа на оценку;
— после того, как обе анкеты заполнены - тимлиду предстоит общаться с сотрудником, приводя примеры и аргументируя свой выбор;
— у нас есть курирование оценки со стороны юнит-лида;
— у многих сотрудников есть запрос роста и развития, они будут спрашивать тимлида куда копать, и тут проще придерживаться общего фреймворка.Так же, например, я, как юнит-лид, периодически запрашиваю фидбек, как внутри команд, так и во вне. Если вижу спорные сигналы, например, что разработчик не перформит — приду узнавать, как так получается.
Draedan
27.05.2022 07:03-1Интересно, а почему не раскрыт самый важный вопрос- связь вашей системы грейдов и рыночной зарплатой?
И ещё вопрос, почему нету в системе грейдирования пункта о рыночном уровне специалиста? То есть о том уровне, на котором находится специалист по результатам собеседования в нескольких фирмах. Что бы он видел, что ваша система грейдов соответствует рыночной, а не являлась замаскированой попыткой снизить зарплату. (Правда в одном случае система ваша, как мне кажется станет немножко бесполезной- если рыночная зарплата будет выше чем ваша по результату опроса, сотрудник просто уйдёт)
igorp1024
27.05.2022 12:11У меня серьёзные сомнения в верности вот этих утверждений.
"Челленджит предложения бизнеса"
"Аргументированно может убедить в том, что этого делать не нужно."
Во-первых, это работа для BA, а не SE - челленджить бизнес. Во-вторых, даже по техническим вопросам есть серьёзный опыт общения с "бизнесом" в попытках "аргументированно убедить". Тут два варианта. Если человек адекватный, он просто сделает фейспалм ивыгоритскажет, что сделает так, как ему сказали. Второй вариант, если это неадекватная "звезда", он скажет, что вы мне все не подходите и уйдёт искать своего счастья в другой команде.dmkuznetsov Автор
27.05.2022 17:47В нашем случае продакты очень близко к командам. И команды могут влиять на скоуп, который предстоит делать. Цели бизнеса по части заработка никто не челленджит из разработки, а вот продуктовые задачи — да.
Мы "бизнесом" называем продактов как ближайших представителей бизнеса по отношению к команде.Если бы у нас была другая структура компании, наличие BA в каждой команде, то, вероятно, и опросник бы сильно отличался.
Многие аутстафф-компании, например, грейдируют исключительно по хард-скиллам, так как продают именно харды.
vyatsek
27.05.2022 15:58+1Данный опросник для грейдов - дичь. Почему-то менеджмент вместо общения с людьми и оценки их полезности пытается наиболее критичный процесс заменить и автоматизировать.
Какие цели ставились перед сотрудником, куда сотрудник хотел расти, как он вырос устраивает ли компанию и работника?
Мнеджера, который придумал этот опросник возможно стоит переключить на административную работу или работу по поддержке. Разработка она не про задачи, а про продукт, ценные и реализованные идеи, а не про выполненные задачи.
Банальная операционщина - удел администраторов.
sunnybear
"Зачастую лучше чего-то не делать, чем реализовывать сомнительное решение либо делать по-другому." Достаточно спорно. Иногда сделать не то - лучший способ протестировать бизнес-гипотезу
dmkuznetsov Автор
Вы абсолютно правы если команда работает над гипотезами. А если речь про реализацию "постоянных" задач, то подход меняется