👨‍💻 Система грейдов разработчиков в Mail.ru, Яндексе и оценка сотрудников

• Обсуждение технических проблем со связью.  

• Решение переподключить гарнитуру.  

• Проверка качества звука.  

• Сравнение с реальными митингами.  

• Введение в тему грейдов и их различия в крупных IT-компаниях.  

• Обсуждение целей введения системы грейдов.  

• Важность понимания целей введения системы грейдов.  

• Проблема слабых тим-лидов и необходимость их обучения.  

• Процесс обучения новых разработчиков опытными коллегами.  

• Таблица направлений для развития разработчиков.  

• Роль тим-лидов в выборе направления развития.  

• Процесс калибровки и обмена опытом.  

• Отсутствие объемных форм для оценки.  

• Возможность адаптации системы под текущие задачи.  

• Важность обратной связи и калибровки.  

• Процесс запроса повышения зарплаты.  

• Изменение зоны ответственности и компетенций.  

• Важность ретроспективных данных для принятия решений.  

• Благодарность за участие.  

• Переход к обсуждению с представителем Яндекса.  

• Перформанс ревью направлено на помощь тим лидам и рост сотрудников.  

• До появления ревью компенсации рассчитывались локальными руководителями.  

• Цель ревью - сделать систему прозрачной и справедливой.  

• Грейды расставлялись по фактической зарплате, а не по компетенциям.  

• Цель - избежать понижения зарплат и выровнять перекосы.  

• Два раза в год проводится ревью для сравнения достижений сотрудников.  

• Таблица компетенций не выдерживает испытания временем.  

• Способ выведения грейдов через попарное сравнение более универсален.  

• Грейды делятся по байкетам и сравниваются по достижениям.  

• В разработке есть грейды от 13 до 17, где 13 - стажер, 14 - младший разработчик и т.д.  

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

• В Mail.ru нет жесткой таблицы грейдов, но есть уровни, синхронизируемые с рынком.  

• Разделение на уровни: младший, обычный, старший разработчик.  

• Система фокусируется на разработчиках и тим лидах, но не на всех слоях компании.  

• В Mail.ru нет необходимости в жесткой лестнице грейдов.  

• Направление движения определяется калибровками и стилями.  

• Важность должности и компенсации для сотрудников.  

• Переход на следующий уровень требует расширения зоны ответственности.  

• Руководитель задает вектор, а калибровки подтверждают переход.  

• Мотивация сотрудников определяется задачами, за которые они отвечают.  

• Калибровка помогает минимизировать субъективность при оценке разработчиков.  

• Оценка подтверждается несколькими коллегами.  

• Пример: разработчик проходил код-ревью с третьего-четвертого раза, но последние три месяца делал это сразу.  

• Оценка выставляется непосредственным руководителем на основе выполнения целей.  

• Цели ставятся на полугодие, и разработчик участвует в одной или нескольких целях.  

• Процесс включает калибровки и сравнения между разработчиками.  

• Цели ставятся совместно с руководителем и могут быть персональными.  

• Оценка учитывает как заслуги, так и проблемы.  

• Разработчики с низкими софт скилами могут развиваться в своих сильных направлениях.  

• Сравнение проводится на основе достижений и области ответственности.  

• Оценка учитывает сложность и объем выполненных задач.  

• В больших подразделениях есть ограничения на повышение грейдов.  

• Результаты ревью известны только самому разработчику.  

• Важно уметь объяснять свои достижения.  

• Оценка учитывает не только код, но и умение его объяснить.  

• Сравнение сотрудников с рынком для определения компенсации.  

• Разные команды могут иметь разные таблицы для оценки.  

• Решения принимаются индивидуально для каждого сотрудника.  

• Система оценок и рядов нацелена на взвешенные решения.  

• Используются данные за полгода, год для принятия решений.  

• Решения о компенсации принимаются на основе рыночных данных.  

• Оценки и премии рассчитываются автоматически.  

• Решения о повышении зарплаты принимаются на основе оценок.  

• Кросс-командные решения одинаковы для всех сотрудников.  

• Субъективизм сохраняется для учета индивидуальных случаев.  

• Возможность не давить на сотрудника в трудные периоды.  

• Перформанс-ревью помогает в таких ситуациях.  

• Понижение грейдов и зарплаты не практикуется.  

• В редких случаях возможно понижение, если сотрудник сильно проседает.  

• Исторически такие случаи были единичными.  

• Грейды не должны быть недостижимой целью.  

• Оценка проводится независимыми экспертами.  

• Оценка комитета определяет перевод в другой грейт.  

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

• Переоценка при найме может привести к проблемам в будущем.  

• Решение о понижении грейда принимается на основе долгосрочных показателей.  

• Испытательный срок помогает понять, способен ли сотрудник расти.  

• Если сотрудник не проходит испытательный срок, это может быть радикальным решением.  

• Длительные периоды проверки оправданы для оценки роста сотрудников.  

• Вопрос о корреляции роста и зарплаты для сотрудников, работающих в компании долгое время.  

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

• Система автоматизирует процесс напоминания руководителям о необходимости повышения зарплаты.  

• В Убере есть понятие "фейв перформанс", где сотрудники, которые хорошо работают, получают больше.  

• Каждый год сотрудники должны получать не меньше, чем в предыдущем году.  

• Общий доход сотрудника, работающего в компании долго, больше, чем у нового сотрудника.  

• В Mail.ru нет системы опционов, вся компенсация выплачивается деньгами.  

• Опционы удерживают сотрудников, так как акции растут со временем.  

• Опционы имеют смысл для сотрудников, которые нужны компании в долгосрочной перспективе.  

• Процесс расставания уникален для каждого случая и может быть растянутым.  

• Если сотрудник не справляется с задачами, ему предлагают помощь или переводят в другую команду.  

• Система оценок позволяет минимизировать количество болезненных расставаний.  

• Если сотрудник растет, ему предлагают задачи, соответствующие его уровню.  

• Текущий тим-лид может искать замену, если сотрудник начинает расти.  

• Руководители видят рост сотрудников и помогают им перейти в другие команды или проекты.  

• Люди часто сталкиваются с трудностями при переходе на новую позицию.  

• Важно проявлять себя через менторство и помощь другим командам.  

• Достижения по скилам должны быть отмечены и компенсированы.  

• В компании нет идеального разработчика, который умеет все.  

• Важно определиться с направлением роста.  

• Сравнение происходит по горизонтальным критериям, таким как объем проектов.  

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

• Важно учитывать ответственность и сложность задач.  

• Система оценки должна быть адаптирована под конкретные цели.  

• Важно найти сильных тим-лидов для обучения.  

• Совместная работа над системой оценки улучшает результаты.  

• Первые итерации могут быть неудачными, но это нормально.  

• Расширение зоны ответственности приводит к изменению компенсации.  

• Важно проявлять себя и получать поддержку от руководителя.  

• Стабильная системная деятельность важна для грейдапа.  

• В других компаниях могут быть свои подходы к росту.  

• Важно делать ревью на других и адаптироваться к новым системам.  

• Для повышения зарплаты или изменения роли нужно обратиться к менеджеру.  

• Для повышения тайтла требуется заявка на рассмотрение комиссии из пяти человек.  

• Комиссия оценивает сотрудника по матрице компетенций, включая качество кода и участие в опенсорс инициативах.  

• При увеличении нагрузки важно учитывать планирование времени.  

• Не всегда можно просто добавить новые компетенции без подготовки.  

• Необходимо уделять внимание планированию и поддержке сотрудников.  

• Есть два пути: инженерная роль или лидерская роль.  

• Важно учитывать, что не все сотрудники готовы к лидерству.  

• Некоторые могут чувствовать себя некомфортно в роли лидера и предпочитают оставаться инженерами.  

• Технические и менеджерские навыки становятся все более интегрированными.  

• Разработчики начинают выполнять больше задач, что ускоряет процесс.  

• Классический грейдинг меняется из-за изменений в технологиях и задачах.  

• Система городов полезна для обмена знаниями и обучения между командами.  

• Важно создать процесс обмена знаниями и ревью решений.  

• Это помогает развивать навыки и улучшать качество работы.  

• Оба подхода возможны: как специализация в одной теме, так и универсальность.  

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

• Важно выбирать путь, который соответствует вашим интересам и возможностям.  

• Участники обсуждают, как система роста в команде может влиять на небольшие команды.  

• Вопрос о том, не вредит ли циркуляция людей в команде, если они быстро растут и уходят.  

• Подчеркивается важность структуры команд для предотвращения "упирания в потолок".  

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

• Пример, когда сеньоры привыкают решать вопросы самостоятельно, что приводит к конфликтам.  

• Противоположный опыт: сеньоры, выросшие вместе, могут находить консолидированные решения.  

• Вопрос о том, как сохранить мотивацию и рост сотрудников, достигших потолка в компании.  

• Обсуждение возможных решений, таких как предоставление новых задач и проектов.  

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

• Обсуждение проблем с грейдингом и его влияния на сотрудников.  

• Вопрос о том, как компании справляются с негативными последствиями грейдинга.  

• Пример, когда сотрудники уходят из компании из-за отсутствия роста и поддержки.  

• Грейдинг имеет как позитивные, так и негативные стороны.  

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

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

• Система грейдов провоцирует как позитивное, так и негативное отношение к компании.  

• Любая система имеет свои плюсы и минусы, и она необходима в больших компаниях.  

• В МТС система грейдов плоская, что делает проблемы роста очевидными.  

• В МТС вводят систему мотивации команд и OKR.  

• Вместо стандартных целей, команды ставят амбициозные задачи, такие как запуск ракеты на Луну.  

• Процесс внедрения OKR сложен и требует адаптации.  

• Недовольные сотрудники часто появляются после грейдинга.  

• Важно работать с негативом, особенно среди топ-менеджеров и сильных специалистов.  

• Опросы не всегда показывают прямую корреляцию с негативом.  

• Грейды условны, и сотрудники могут проходить несколько шагов внутри грейда.  

• Руководящих ролей становится меньше, и они требуют высокой квалификации.  

• Система грейдов помогает определить ценность каждого сотрудника.  

• Ежеквартальные бизнес-ревью требуют много времени и усилий.  

• В Яндексе команды собираются вместе для оценки, что ускоряет процесс.  

• Предварительная калибровка оценок помогает снизить количество вопросов.  

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

• Опросы и анонимные опросы помогают выявить недовольство.  

• Система грейдов не идеальна, но она необходима для управления ресурсами.  

• Регулярная оценка и внутренняя конкуренция помогают мотивировать сотрудников.  

• Создание конкуренции и интересных задач внутри команды стимулирует рост.  

• Внутренняя мотивация важнее, чем просто оценка компании.  

• Успешные методы гемификации зависят от тим-лида.  

• Тим-лид должен знать команду и их способности.  

• Грамотное распределение задач и мотивация через задачи помогают удерживать команду.  

• В успешных командах костяк остается стабильным.  

• Зарплата не всегда является ключевым фактором удержания.  

• Внутренняя конкуренция и заинтересованность важны для сохранения команды.  

• Спикеры могут выйти, если не планируют говорить.  

• Вопросы о внедрении системы оценки на постоянной основе.  

• Система оценки должна быть непрерывной и влиять на грейд.  

• Внедрение системы оценки требует времени и ресурсов.  

• Важно, чтобы критерии оценки были четкими и не вызывали абьюза.  

• Система баллов должна влиять на грейд, а не только на деньги.  

• Система баллов должна быть разнообразной и не линейной.  

• Важно, чтобы каждый разработчик оценивался по разным критериям.  

• Система должна показывать прогресс по каждому ресурсу.  

• В МТС есть система "Снежинка" для оценки риска оттока.  

• Система "Скажи спасибо" помогает оценить взаимодействие с коллегами.  

• Эти системы могут быть полезными, но требуют доработки.  

• Важно мотивировать команды на ускорение и улучшение качества.  

• Система грейдов должна быть пересмотрена.  

• Комьюнити внутри компании могут лучше калибровать и мотивировать сотрудников.  

• Перфоманс-менеджмент включает не только грейды, но и систему мотивации, фидбека, технических ограничений и хэт-хаттинга.  

• В компании Elljoy внедряют скил-матрицы для инженеров, где описываются не только конкретные скилы, но и поведенческие индикаторы.  

• Важна система мотивации, которая может не совпадать с системой мотивации компании.  

• Система грейдов должна учитывать как вертикальный, так и горизонтальный рост.  

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

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

• Справедливость в повышении грейдов зависит от вклада в генерацию денег и ответственности.  

• Повышение грейда должно сопровождаться увеличением зоны ответственности.  

• Важно учитывать стратегическую важность продукта и готовность рынка платить за аналогичные услуги.  

• Алекс делится негативным опытом работы в Яндексе.  

• Команда работала как стартап, запускала экспериментальные фичи.  

• Продукты делались быстро, но оценка была несправедливой.  

• Команда получала хорошие оценки, но отдельные разработчики – плохие.  

• Никто не понимал, почему так происходит.  

• Алекс покинул компанию с плохой оценкой, не понимая причин.  

• Тим лид давал расплывчатые ответы на вопросы.  

• Алекс пытался улучшить оценку, но получил среднюю оценку.  

• Непрозрачность процесса ревью вызывала диссонанс.  

• Важно сделать процесс ревью максимально прозрачным.  

• В больших компаниях это сложно, но можно внедрить через ивенты.  

• Регулярный фидбек от менеджера играет ключевую роль.  

• Письменный фидбек помогает понять причины оценки.  

• В стартаповской команде не всегда можно было поставить KPI.  

• Сравнение людей в команде может привести к разным оценкам.  

• Объяснение причин оценки может демотивировать.  

• Введение системы мотивации может ограничить власть линейного руководства.  

• В некоторых случаях аутстаффинг программистов может быть более эффективным.  

• Вопрос о том, как бы сотрудники отнеслись к открытости зарплат.  

• Обсуждение полезности программистов для бизнеса.  

• Зарплата зависит от умения продавать себя, а не от труда.  

• Прозрачность зарплат важна для понимания, кто за что получает деньги.  

• Система OKR в Google и других компаниях помогает в этом.  

• Открытость зарплат может вызвать негатив и несправедливые оценки.  

• Калибровки позволяют сохранять справедливость в оценке.  

• Руководители обсуждают результаты без участия разработчиков.  

• Честность важна для защиты от несправедливых решений.  

• Альтернатива открытой зарплате — необходимость выпрашивать повышение.  

• Это создает дополнительную моральную нагрузку.  

• Открытая зарплата позволяет избежать таких ситуаций.  

• Сравнение достижений на одном грейде должно быть справедливым.  

• Скрытие зарплат слабо работает, люди все равно делятся информацией.  

• Различия в зарплатах могут демотивировать сотрудников.  

• Система грейдов должна отцеплять оценку от успеха проекта.  

• На высоких грейдах влияние выполнения целей выше.  

• Риски и компенсации должны быть пропорциональны вкладу в проект.  

• Разделение зон ответственности важно для предотвращения конфликтов.  

• Вопросы о зонах ответственности должны обсуждаться с руководителем.  

• При расформировании команды возможен ревью при переходе в другую команду.  

• Закрытие проекта не влияет на грейды сотрудников, если они остаются в компании.  

• Вознаграждение может измениться в зависимости от команды и проекта.  

• В экспериментальных командах риски выше, но и вознаграждение может быть выше.  

• Молодые специалисты часто не понимают систему грейдов и поощрений.  

• В каждой компании свои правила и подходы к оценке и поощрению.  

• Важно разбираться в системе, чтобы не быть в худшем положении.  

• Лиды могут совмещать кодинг и лидерство в разных пропорциях.  

• Чем выше уровень руководителя, тем меньше он занимается кодингом.  

• Важно, чтобы руководитель понимал технические аспекты работы.  

• Лиды могут отвечать за техническую составляющую, руководство командой или найм и увольнение.  

• Чем выше уровень, тем меньше лид занимается кодингом.  

• Компетенции и роли в компании могут варьироваться в зависимости от уровня.  

• Некоторые сотрудники могут не стремиться к менеджерским ролям, но приносить пользу компании.  

• Важно оценивать их вклад и предлагать возможности для роста.  

• Иногда приходится расставаться с ценными сотрудниками, если они не растут вертикально.  

• Обсуждение перфоманса и достижения целей.  

• Важность экспертизы и её влияние на команду.  

• Вопрос измерения перфоманса для экспертов.  

• Индивидуальные контрибьюторы в западных корпорациях.  

• Карьерный путь в российских компаниях.  

• Вопрос удержания экспертизы в компании.  

• Разделение на сееров по бюрократии и разработке.  

• Важность развития софт-скилов.  

• Ограничения роста на основе технических навыков.  

• Оплата труда руководителей направлений в Сбербанке.  

• Ограничения на оплату опытных инженеров.  

• Предложение о продолжении обсуждения на фронтейнерских завтраках.  

• Призыв к участию в фронтейнерских завтраках.  

• Благодарность участникам и спикерам.  

• Прощание и пожелания всего хорошего.