Возможно, полгода — это действительно небыстро. Здесь два момента:

1. У Ops-департамента широкий спектр задач, поэтому нам кажется, что полгода до самостоятельности — хороший показатель. В другой команде с другими задачами срок может быть как меньше, так и больше.

2. Описанный в статье онбординг с ментором — больше для Junior-инженеров или, как в истории Игоря, при смена стека с Windows на Linux. Middle- или Senior-инженеры вливаются сильно быстрее. 

При необходимости добавления специалистов идёт согласование между Business Owner, Product Manager и командой, где нужен специалист. Здесь мы определяем саму необходимость (для чего нужен человек) и согласовываем бюджет.

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

1. У вас есть что-то типа матрицы компетенций с уровнями владения навыками?

У нас есть линейка грейдов, где как раз прописаны компетенции и уровни. Их мы оцениваем в рамках процесса грейдирования силами экспертной команды, которой доверяем. К сожалению, мы пока не уверены, что готовы опубликовать свою матрицу компетенций для всех, но надеемся, что чуть попозже сможем поделиться примерами, про которые вы спрашиваете.

2. Что делается с, очевидно, очень широким стеком технологий и тем, что некоторые задачи могут возникать раз в год-два? Входит ли обладание знаниями по такой технологии в план роста, оценку перехода из джуна в мидлы и далее? И вообще что делать с такими редко возникающими задачами? Как известно, чем шире стек, тем меньше глубина знаний. Есть ли специализация в командах? Мидл у вас — это тот, кто в глубину или в ширину?

Отвечу с конца, чтобы у вас было больше контекста. Глобально команды разделены по направлениям: Ops main, Ops Internal, VoIP. Каждая из них отвечает за свою часть. Например, зона ответственности Ops Internal — это администрирование сервисов логирования, сервисов мониторинга, сервисов хранения данных (CEPH), администрирование сервисов отладки, обслуживание и администрирование контуров PCI DSS. Плюс в случае необходимости мы делим команды на более мелкие сегменты и примеряем грейдирование ещё более узко. Так что необходимости выучить вообще всё и объять необъятное — нет.

Про ширину стека — чистая правда. У нас есть базовые требования к сотруднику, чтобы он мог называться junior, junior+, middle, middle+ и так далее. Например, для старта работы нужны базовые знания Linux, баз данных, архитектуры операционных систем и так далее. Но безусловно есть и узкие показатели глубины этих знаний. При переходе от одного грейда к другому эти знания всегда дополняются, так что это сочетание и ширины и глубины. Очень редкие задачи, которые появляются раз в 1-2 года, как мне кажется, учитывать в такой оценке сложно и не очень нужно.

3. Из джуна в мидлы за полгода — вообще интересно. Мидл же это не только про набор знаний как таковых, но еще и уже про опыт. Джун за полгода не соберет большинство граблей.

По нашему опыту полгода плодотворной работы всё же хватает, чтобы перейти от junior до middle-инженера. Но дальнейший путь до middle+ и тем более до senior — гораздо более долгий, это чистая правда. Мы постараемся собрать отдельный материал с примерами конкретных ребят, чтобы не отвечать абстрактно. Принесу на него ссылку сюда после публикации.

1. Какими  «линейками» вы измеряет софт и хардскиллы для оценки прогресса джуна?

У нас есть линейка грейдов, где мы прописываем чёткие показатели по навыкам и знаниям каждого сотрудника: что он должен знать на той или иной должности. Она учитывает и харды и софты. Мы пока не уверены, что готовы выложить свои линейки в публичное пространство, но думаем в эту сторону. Так что пока покажу дополнительные инструменты.

Начнём с хард-скиллов. Как и многие, мы измеряем задачи в стори поинтах. Смотрим на сложность задачи и время её выполнения, составляем пропорцию и получаем результат. Например, у нас есть задача в три стори поинта. Senior-инженер делает её за условные 3 часа, junior — за неделю. Отношение сложности задачи к скорости её выполнения хорошо показывает мощность сотрудника и его «принадлежность» к тому или иному уровню.

Что касается софт-скиллов в отдельности, история чуть более абстрактная, но инструменты здесь тоже есть. Важный фактор — это удовлетворённость заказчика. У нас есть автоматизированный опрос, где заказчики с некоторым лагом по времени фиксируют обратную связь. Сопоставляя эти данные, мы видим, есть ли улучшение. Дополнительно тимлиды и менторы присматривают за их ответами junior-инженеров в чатах и во время дежурств. На основе этой информации они могут вносить коррективы в планы.

2. Как вы формулирует цели для пар специалистов?

Поскольку основная задача — сделать так, чтобы junior-инженер мог самостоятельно закрывать рабочие задачи, от них мы и отталкиваемся. Цели привязаны к курсу компании и потребностям Ops-департамента. Поэтому мы смотрим на задачи в бэклоге, выбираем из них наиболее приоритетные и отдаём в работу ментору и его подопечному. Механика поменьше отдаётся джуну, а более глобальная цель стоит у senior-инженера. В процессе лучше понятно, какие навыки проседают, и что нужно подтягивать.

Кажется, чтобы быть конкретным в ответе, нужно приводить конкретные цели, задачи и личный пример ребят из команды. Напишем отдельный материал про конкретные кейсы с живыми примерами.

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

Мы сами сейчас идём по пути написание своего фреймворка с учётом особенностей нашей инфраструктуры и требований. Когда-нибудь про это расскажем отдельно.

1. Решение с whitelist до сих пор вызывает споры у нас самих - blacklist был бы намного проще в использовании и прощал бы нам многие ошибки, например, мы могли бы хуже следить за соответствием DSL описания API на стороне сервиса и на стороне транспорта и пропускать ошибки, связанные с кодогенерацией. Whitelist накладывает на нас более жёсткие требования в отношении корректности описаний. А поскольку мы прекрасно понимаем, что это всё - костыль, а костыль гнуться не должен - мы выбрали вариант с whitelist.

2. Про булевский флаг не очень понял, но в целом у нас уже сейчас в документ не вносятся никакие изменения, если не надо (он даже не копируется внутри памяти).

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

Минусы называем дельтами, благодаря влиянию Гарвардской школы образования (HGSE) на процессы в нашей команде. В данный момент я прохожу обучение по программе Data Wise, и благодаря обучению, имею возможность следить за тенденциями и технологиями, которые сейчас внедряются Гарвардом.Дельты - это зоны роста, то что можно улучшить. Воспринимается это намного более дружелюбно, чем "минусы" или "недостатки". Кроме того "дельта" - не эмоционально окрашенное слово, и его использование помогает не вызвать негативных эмоций в сторону мнения человека, его высказывающего.