Возможно, полгода — это действительно небыстро. Здесь два момента:
У Ops-департамента широкий спектр задач, поэтому нам кажется, что полгода до самостоятельности — хороший показатель. В другой команде с другими задачами срок может быть как меньше, так и больше.
Описанный в статье онбординг с ментором — больше для 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-инженера. В процессе лучше понятно, какие навыки проседают, и что нужно подтягивать.
Кажется, чтобы быть конкретным в ответе, нужно приводить конкретные цели, задачи и личный пример ребят из команды. Напишем отдельный материал про конкретные кейсы с живыми примерами.
Префиксы помогают быстро понять, в каких сервисах находятся дубли секретов. Мы не решали именно проблему устранения дублей, мы решали проблему быстрого получения информации о тех сервисах, в которых используются одни и те же креды, чтобы понимать, какие сервисы надо перезапустить или проверить, что они подтянули новые креды.
Добрый день! Вы правы, что все фреймворки можно найти на многих других ресурсах. Причина появления статьи в том, что вопросы о том, что использовать, тоже периодически появляются в разных местах. Поэтому мы подумали, что обзор может быть полезен для начинающих. Видим, что были не совсем правы, спасибо вам за клёвую обратную связь!
Мы сами сейчас идём по пути написание своего фреймворка с учётом особенностей нашей инфраструктуры и требований. Когда-нибудь про это расскажем отдельно.
Не вас одного, конечно, отчасти поэтому Gorilla последняя в списке.
В последний месяц в issue появились несколько человек, которые, кажется, готовы выделять на Gorilla время. Надеемся, что проект будет жить. Но, сожалению, мало какой open source полностью застрахован от сценария, когда у главного контрибьютора нет свободного времени или мотивации продолжать :С
Однопоточность была у нас исходным требованием для конкурса. Естественно в реальности у нас не одна труба для данных и такие однопоточные алгоритмы обрабатывают свои потоки данных параллельно в разных потоках суммарно обеспечивая кратную пропускную способность. Про многопоточную фильтрацию одного документа мы тоже думали, но решили, что большого бонуса нам это не даст - кажется, это может уменьшить latency для обработки документов (и то я сомневаюсь), но общая пропускная способность может снизится. При этом добавляемый однопоточной фильтрацией latency на общем фоне и так исчезающе мал. Но если честно, мы с самого начала хотели подтолкнуть разработчиков к использованию векторных инструкций, а допустив многопоточный парсинг рисковали бы отправить их по ложному пути :)
Решение с whitelist до сих пор вызывает споры у нас самих - blacklist был бы намного проще в использовании и прощал бы нам многие ошибки, например, мы могли бы хуже следить за соответствием DSL описания API на стороне сервиса и на стороне транспорта и пропускать ошибки, связанные с кодогенерацией. Whitelist накладывает на нас более жёсткие требования в отношении корректности описаний. А поскольку мы прекрасно понимаем, что это всё - костыль, а костыль гнуться не должен - мы выбрали вариант с whitelist.
Про булевский флаг не очень понял, но в целом у нас уже сейчас в документ не вносятся никакие изменения, если не надо (он даже не копируется внутри памяти).
Спасибо за ваш отзыв и за то, что прочли мою статью! Мы рассматривали только представленные в статье СДО, это было еще в далеком 2019 году, и тогда многие СДО либо не пользовались популярностью, либо были не известны нашему сотруднику, проводившему анализ. В любом случае протестировать абсолютно все на рынке нереально, именно поэтому я и решила написать эту статью и помочь коллегам с таким не простым выбором.
Как я уже говорила в статье, конструктор у iSpring действительно хороший, нативный, и также позволяет внедрить большое количество функционала. Конструктором мы в целом довольны, а обучение вышло на новый уровень. Я думаю, что абсолютно любой софт будет иметь свои дельты, с которыми нужно просто научиться работать. Мы решили больше не распыляться на подбор нового софта, учитывая тот факт, что iSpring развивается с каждым обновлением. Мы решили углублять экспертизу, находить интересные решения с теми ресурсами, которые у нас есть и это помогло нам сфокусироваться больше на результате и содержании, нежели на форме :)
Здесь выбирать, конечно, вам. В целом с дельтами можно работать, также сотрудники iSpring совсем недавно пообещали, что все дельты поправят.Будем ждать!
Цель статьи была - уберечь коллег от своих ошибок и поделиться успешным опытом, который можно перенять без страха. Некоторые наши видео для курсов делала профессиональная медиа команда, которая работает на внутренние проекты и делает крутые видео для наших клиентов, здесь мы тоже не пошли легким путем)). Сами же мы перепробовали разные варианты, и сейчас лучше всего работает для нас loom.
Было бы здорово, если бы вы тоже поделились своим опытом, каким образом вы делаете обучающие вебинары! Удачи вам в вашем проекте, это нелегкий, но очень интересный путь
Спасибо большое за комментарий по OBS. Думаю, будет особо ценно для тех, кто только выбирает для себя интересные ПО.Однако, доп настройки усложняют процесс, а мы стремимся к облегчению) Loom сейчас для нас отличное решение. Все супер интуитивно и просто, есть возможность использовать различные графические инструменты, есть сразу скрипт видео, и много других полезных функций без особых усилий :)
На рынке очень много различных онлайн платформ, посмотреть их все нереально. Мы остановили свой выбор на представленных в статье платформах, и облегчили тем самым выбор для тех, кому только предстоит этот путь. Вы сможете посмотреть другие платформы и написать подобную статью, чтобы помочь нашим коллегам, так как выбор на рынке действительно очень большой.
Минусы называем дельтами, благодаря влиянию Гарвардской школы образования (HGSE) на процессы в нашей команде. В данный момент я прохожу обучение по программе Data Wise, и благодаря обучению, имею возможность следить за тенденциями и технологиями, которые сейчас внедряются Гарвардом.Дельты - это зоны роста, то что можно улучшить. Воспринимается это намного более дружелюбно, чем "минусы" или "недостатки". Кроме того "дельта" - не эмоционально окрашенное слово, и его использование помогает не вызвать негативных эмоций в сторону мнения человека, его высказывающего.
Привет! Спасибо за комментарий.
Возможно, полгода — это действительно небыстро. Здесь два момента:
У Ops-департамента широкий спектр задач, поэтому нам кажется, что полгода до самостоятельности — хороший показатель. В другой команде с другими задачами срок может быть как меньше, так и больше.
Описанный в статье онбординг с ментором — больше для 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-инженера. В процессе лучше понятно, какие навыки проседают, и что нужно подтягивать.
Кажется, чтобы быть конкретным в ответе, нужно приводить конкретные цели, задачи и личный пример ребят из команды. Напишем отдельный материал про конкретные кейсы с живыми примерами.
Илья, добрый день!
Префиксы помогают быстро понять, в каких сервисах находятся дубли секретов. Мы не решали именно проблему устранения дублей, мы решали проблему быстрого получения информации о тех сервисах, в которых используются одни и те же креды, чтобы понимать, какие сервисы надо перезапустить или проверить, что они подтянули новые креды.
Добрый день! Вы правы, что все фреймворки можно найти на многих других ресурсах. Причина появления статьи в том, что вопросы о том, что использовать, тоже периодически появляются в разных местах. Поэтому мы подумали, что обзор может быть полезен для начинающих. Видим, что были не совсем правы, спасибо вам за клёвую обратную связь!
Мы сами сейчас идём по пути написание своего фреймворка с учётом особенностей нашей инфраструктуры и требований. Когда-нибудь про это расскажем отдельно.
Не вас одного, конечно, отчасти поэтому Gorilla последняя в списке.
В последний месяц в issue появились несколько человек, которые, кажется, готовы выделять на Gorilla время. Надеемся, что проект будет жить. Но, сожалению, мало какой open source полностью застрахован от сценария, когда у главного контрибьютора нет свободного времени или мотивации продолжать :С
Спасибо за рекомендацию :)
Однопоточность была у нас исходным требованием для конкурса. Естественно в реальности у нас не одна труба для данных и такие однопоточные алгоритмы обрабатывают свои потоки данных параллельно в разных потоках суммарно обеспечивая кратную пропускную способность. Про многопоточную фильтрацию одного документа мы тоже думали, но решили, что большого бонуса нам это не даст - кажется, это может уменьшить latency для обработки документов (и то я сомневаюсь), но общая пропускная способность может снизится. При этом добавляемый однопоточной фильтрацией latency на общем фоне и так исчезающе мал. Но если честно, мы с самого начала хотели подтолкнуть разработчиков к использованию векторных инструкций, а допустив многопоточный парсинг рисковали бы отправить их по ложному пути :)
Спасибо за фидбек, могу сказать что:
Решение с whitelist до сих пор вызывает споры у нас самих - blacklist был бы намного проще в использовании и прощал бы нам многие ошибки, например, мы могли бы хуже следить за соответствием DSL описания API на стороне сервиса и на стороне транспорта и пропускать ошибки, связанные с кодогенерацией. Whitelist накладывает на нас более жёсткие требования в отношении корректности описаний. А поскольку мы прекрасно понимаем, что это всё - костыль, а костыль гнуться не должен - мы выбрали вариант с whitelist.
Про булевский флаг не очень понял, но в целом у нас уже сейчас в документ не вносятся никакие изменения, если не надо (он даже не копируется внутри памяти).
Спасибо за ваш отзыв и за то, что прочли мою статью! Мы рассматривали только представленные в статье СДО, это было еще в далеком 2019 году, и тогда многие СДО либо не пользовались популярностью, либо были не известны нашему сотруднику, проводившему анализ. В любом случае протестировать абсолютно все на рынке нереально, именно поэтому я и решила написать эту статью и помочь коллегам с таким не простым выбором.
Как я уже говорила в статье, конструктор у iSpring действительно хороший, нативный, и также позволяет внедрить большое количество функционала. Конструктором мы в целом довольны, а обучение вышло на новый уровень. Я думаю, что абсолютно любой софт будет иметь свои дельты, с которыми нужно просто научиться работать. Мы решили больше не распыляться на подбор нового софта, учитывая тот факт, что iSpring развивается с каждым обновлением. Мы решили углублять экспертизу, находить интересные решения с теми ресурсами, которые у нас есть и это помогло нам сфокусироваться больше на результате и содержании, нежели на форме :)
Здесь выбирать, конечно, вам. В целом с дельтами можно работать, также сотрудники iSpring совсем недавно пообещали, что все дельты поправят.Будем ждать!
Спасибо, что прочли и поделились мнением!
Цель статьи была - уберечь коллег от своих ошибок и поделиться успешным опытом, который можно перенять без страха. Некоторые наши видео для курсов делала профессиональная медиа команда, которая работает на внутренние проекты и делает крутые видео для наших клиентов, здесь мы тоже не пошли легким путем)). Сами же мы перепробовали разные варианты, и сейчас лучше всего работает для нас loom.
Было бы здорово, если бы вы тоже поделились своим опытом, каким образом вы делаете обучающие вебинары! Удачи вам в вашем проекте, это нелегкий, но очень интересный путь
Спасибо большое за комментарий по OBS. Думаю, будет особо ценно для тех, кто только выбирает для себя интересные ПО.Однако, доп настройки усложняют процесс, а мы стремимся к облегчению) Loom сейчас для нас отличное решение. Все супер интуитивно и просто, есть возможность использовать различные графические инструменты, есть сразу скрипт видео, и много других полезных функций без особых усилий :)
На рынке очень много различных онлайн платформ, посмотреть их все нереально. Мы остановили свой выбор на представленных в статье платформах, и облегчили тем самым выбор для тех, кому только предстоит этот путь. Вы сможете посмотреть другие платформы и написать подобную статью, чтобы помочь нашим коллегам, так как выбор на рынке действительно очень большой.
Минусы называем дельтами, благодаря влиянию Гарвардской школы образования (HGSE) на процессы в нашей команде. В данный момент я прохожу обучение по программе Data Wise, и благодаря обучению, имею возможность следить за тенденциями и технологиями, которые сейчас внедряются Гарвардом.Дельты - это зоны роста, то что можно улучшить. Воспринимается это намного более дружелюбно, чем "минусы" или "недостатки". Кроме того "дельта" - не эмоционально окрашенное слово, и его использование помогает не вызвать негативных эмоций в сторону мнения человека, его высказывающего.