Комментарии 4
Какими "линейками" вы измеряет софт и хардскиллы для оценки прогресса джуна?
Как вы формулирует цели для пар специалистов?
Илья, привет, и спасибо за вопросы!
1. Какими «линейками» вы измеряет софт и хардскиллы для оценки прогресса джуна?
У нас есть линейка грейдов, где мы прописываем чёткие показатели по навыкам и знаниям каждого сотрудника: что он должен знать на той или иной должности. Она учитывает и харды и софты. Мы пока не уверены, что готовы выложить свои линейки в публичное пространство, но думаем в эту сторону. Так что пока покажу дополнительные инструменты.
Начнём с хард-скиллов. Как и многие, мы измеряем задачи в стори поинтах. Смотрим на сложность задачи и время её выполнения, составляем пропорцию и получаем результат. Например, у нас есть задача в три стори поинта. Senior-инженер делает её за условные 3 часа, junior — за неделю. Отношение сложности задачи к скорости её выполнения хорошо показывает мощность сотрудника и его «принадлежность» к тому или иному уровню.
Что касается софт-скиллов в отдельности, история чуть более абстрактная, но инструменты здесь тоже есть. Важный фактор — это удовлетворённость заказчика. У нас есть автоматизированный опрос, где заказчики с некоторым лагом по времени фиксируют обратную связь. Сопоставляя эти данные, мы видим, есть ли улучшение. Дополнительно тимлиды и менторы присматривают за их ответами junior-инженеров в чатах и во время дежурств. На основе этой информации они могут вносить коррективы в планы.
2. Как вы формулирует цели для пар специалистов?
Поскольку основная задача — сделать так, чтобы junior-инженер мог самостоятельно закрывать рабочие задачи, от них мы и отталкиваемся. Цели привязаны к курсу компании и потребностям Ops-департамента. Поэтому мы смотрим на задачи в бэклоге, выбираем из них наиболее приоритетные и отдаём в работу ментору и его подопечному. Механика поменьше отдаётся джуну, а более глобальная цель стоит у senior-инженера. В процессе лучше понятно, какие навыки проседают, и что нужно подтягивать.
Кажется, чтобы быть конкретным в ответе, нужно приводить конкретные цели, задачи и личный пример ребят из команды. Напишем отдельный материал про конкретные кейсы с живыми примерами.
Ой, много вопросов будет.
У вас есть что-то типа матрицы компетенций с уровнями владения навыками? Очень интересно было бы увидеть какой-нибудь пример из нее. Как делить владение технологиями по уровням (условно есть nginx, один умеет делать proxy_pass, второй человек умеет адские конфиги на луа и перле и при этом они оба "умеют в nginx". пытаетесь ли вы это как-то определять или делить)?
Что делается с, очевидно, очень широким стеком технологий и тем, что некоторые задачи могут возникать раз в год-два? Например - каждый день мы заливаем железки, но раз в год или два мы завозим какую-нибудь неведомую штуку типа условного STF или приходится ковыряться в какой-нибудь базе, с которой на постоянной основе не работаем? Входит ли обладание знаниями по такой технологии в план роста, оценку перехода из джуна в мидлы и далее? И вообще что делать с такими редко возникающими задачами? Как известно, чем шире стек, тем меньше глубина знаний. Есть ли специализация в командах (один гайки крутит и в случае чего может в манифест и код, а другой любит ямл и изредка может на железку залезть, но обычно не хочет)? Мидл у вас - это тот, кто в глубину или в ширину?
Из джуна в мидлы за полгода - вообще интересно. Мидл же это не только про набор знаний как таковых, но еще и уже про опыт. Джун за полгода не соберет болшинство граблей и простое изучение документации и просмотр видео по конференциям ему в этом никак не помогут. Поэтому интересна шкала оценки
Привет, и спасибо за классные вопросы.
1. У вас есть что-то типа матрицы компетенций с уровнями владения навыками?
У нас есть линейка грейдов, где как раз прописаны компетенции и уровни. Их мы оцениваем в рамках процесса грейдирования силами экспертной команды, которой доверяем. К сожалению, мы пока не уверены, что готовы опубликовать свою матрицу компетенций для всех, но надеемся, что чуть попозже сможем поделиться примерами, про которые вы спрашиваете.
2. Что делается с, очевидно, очень широким стеком технологий и тем, что некоторые задачи могут возникать раз в год-два? Входит ли обладание знаниями по такой технологии в план роста, оценку перехода из джуна в мидлы и далее? И вообще что делать с такими редко возникающими задачами? Как известно, чем шире стек, тем меньше глубина знаний. Есть ли специализация в командах? Мидл у вас — это тот, кто в глубину или в ширину?
Отвечу с конца, чтобы у вас было больше контекста. Глобально команды разделены по направлениям: Ops main, Ops Internal, VoIP. Каждая из них отвечает за свою часть. Например, зона ответственности Ops Internal — это администрирование сервисов логирования, сервисов мониторинга, сервисов хранения данных (CEPH), администрирование сервисов отладки, обслуживание и администрирование контуров PCI DSS. Плюс в случае необходимости мы делим команды на более мелкие сегменты и примеряем грейдирование ещё более узко. Так что необходимости выучить вообще всё и объять необъятное — нет.
Про ширину стека — чистая правда. У нас есть базовые требования к сотруднику, чтобы он мог называться junior, junior+, middle, middle+ и так далее. Например, для старта работы нужны базовые знания Linux, баз данных, архитектуры операционных систем и так далее. Но безусловно есть и узкие показатели глубины этих знаний. При переходе от одного грейда к другому эти знания всегда дополняются, так что это сочетание и ширины и глубины. Очень редкие задачи, которые появляются раз в 1-2 года, как мне кажется, учитывать в такой оценке сложно и не очень нужно.
3. Из джуна в мидлы за полгода — вообще интересно. Мидл же это не только про набор знаний как таковых, но еще и уже про опыт. Джун за полгода не соберет большинство граблей.
По нашему опыту полгода плодотворной работы всё же хватает, чтобы перейти от junior до middle-инженера. Но дальнейший путь до middle+ и тем более до senior — гораздо более долгий, это чистая правда. Мы постараемся собрать отдельный материал с примерами конкретных ребят, чтобы не отвечать абстрактно. Принесу на него ссылку сюда после публикации.
Менторство в команде Ops: внедрение процесса и первые результаты