❤️ Телеграм-канал

Джунов также растим, но несколько иначе. В принципе джуны в моем понимании — это не самый низкий уровень. Первый — это интерны. Грубо говоря, студенты, которые уже что-то видели и хотят в джуны. Мы же говорим о следующем уровне, до которого надо еще дойти.

В джуны DevOps приходят из интернов, с соседних проектов (с аналогичной позиции, на которой что-то не сложилось) или со смежных направлений, когда человек занимался, например тестированием, разработкой или системной аналитикой, но осознанно идет на понижение, чтобы попасть на другую должность. Другой вариант — сисадмин какой-то компании, где со временем написали некий сервис и ему пришлось пощупать его изнутри.

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

Каких джунов мы ищем

Общаясь с потенциальным коллегой, я всегда смотрю не столько на технические знания, сколько на софт скиллы и способность принять нашу культуру. Важна готовность решать проблемы и правильный подход к ним. А еще базовое знание Linux (можно даже без остальных инструментов DevOps).

Желание справляться с трудностями

Мне нравятся люди, которые еще на этапе собеседования высказывают готовность решать проблемы. Особенность нашей работы такова, что на проекте придется чаще всего оставаться с этими проблемами один на один. Готов ли человек к этому?

На мой взгляд, если джун придет и скажет: “У меня не получилось”, то получит удивленный взгляд. Если ты джун, изучи проблему, собери кейсы, построй теорию (а может и не одну) и с этим уже иди к старшим коллегам, чтобы узнать, куда копать дальше. Это шанс продемонстрировать активность в решении проблемы. И если человек делает так, ему хочется помочь. Мы любим именно таких джунов — они быстро растут и развиваются.

На собеседованиях я рассказываю реальные кейсы с проектов: такой-то стек под капотом, приходит разработчик и надо разобраться, почему у него не хватает какой-то переменной на проде. Это придется гуглить и решать, скорее всего самому. Вопрос в том, готов ли человек к этому? Будет ли он ковыряться до победного? Идеальный вариант, если человек сам уверен — уже сталкивался с чем-то подобным и вывез, а значит и тут найдет решение.

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

Готовность к переработкам

Да, говорят, что переработки — это плохо — ненормированный график, нарушение баланса работы и личной жизни и т.п. Но это лишь часть картины. Зато мы можем себе позволить работать всего несколько часов в день, используя в том числе и рабочее время для выполнения каких-то личных дел. Например, могу сходить в МФЦ в обед. Если в этот момент не было инцидента, никаких вопросов.

Умение диагностировать проблемы

Сильной стороной кандидатов считаю умение искать источник проблемы.

В последнее время на рынке труда много специалистов после курсов DevOps. Но на 99% все курсы, которые сейчас есть в интернете, построены вокруг изучения только лишь базовых инструментов — как собирать Docker или настраивать CI/CD. Там не дают фундаментальных знаний о том, как, допустим, дебажить проблемы в ОС Linux (вероятно, курсы предполагают, что эти знания у кандидатов уже есть).

На мой взгляд, без разницы, знаешь ты конкретный инструмент или нет. Когда нужно, инструмент можно выучить буквально за неделю: посмотрел видеоурок, поэкспериментировал на домашнем стенде. Но если ты не можешь пользоваться базовым набором подходов в ОС Linux, ты просто не справишься с задачей. Будешь бегать и трясти всех вокруг в поисках помощи, требуя выдать четкую инструкцию, как действовать. Такой джун в команде не нужен.

Сисадмины, эникейщики в половине или даже большей части случаев обладают нужными навыками. Все зависит от того, что именно они админили. Мне очень нравятся ребята из техподдержки операторов домашнего интернета или хостинг-провайдеров. Они все в принципе умеют работать в консоли, знают сети и подходы к поиску проблем. Каждый день 99% своего времени они как раз этим и занимаются.

Путь обучения

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

Что это за инструменты:

• бекапы

• мониторинг

• логирование

• аллерты

• disaster recovery

• CI/CD

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

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

Залог успеха этого процесса — правильный руководитель и грамотная организация команд.

Навыки руководителя

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

Как правило, самое главное препятствие — это неумение ставить цели. Постановка цели по SMART (Specific — конкретная; Measurable — измеримая; Achievable — достижимая; Relevant — значимая; Time bound — ограниченная во времени) — вроде бы элементарная везде распиаренная штука, но многие не умеют ей пользоваться — не обозначают конечный результат, когда распределяют задачи.

Например, я прошу мидла сделать задачку уровня тимлида — расписать решение проблемы. Он пишет: “Сделать то-то, сделать то-то”. Все здорово, но как я принесу это бизнесу? В чем для него ценность? После обсуждения выясняется, что в результате выполнения всех пунктов будет работать метрика, указывающая, что сервис сбоит. И это действительно ценность — вот, что надо было писать с самого начала. Но перевернуть мышление в эту парадигму, научить технаря говорить на языке результатов, что по сути равно языку бизнес менеджеров, очень сложно. Так что тимлиды, которые умеют с джунами говорить на техническом языке, а с бизнесом — на бизнесовом, которые умеют декомпозировать сложные задачи на простые шаги и понимают, кто из ребят сможет с ними справиться, — на вес золота.

Есть четыре уровня делегирования:

• Первый — когда человек готов работать только по подробной инструкции. Если подобный подход выявляется на собеседовании или испытательном сроке, мы расстаемся с таким человеком. Увы, такие джуны быстро не вырастут. А еще хуже, когда такие качества проявляются у руководителя.

• Второй — когда он может работать по частично доступной информации (додумать или найти источник информации, где то в конфигурации, у команды разработки, недостающие участки и просто погуглить и решить задачу).

• Третий — когда можно сообщить о проблемном месте, а он может сам найти источник проблемы, сформулировать способы решения. По сути это снова про навыки диагностики проблем. Это кунг-фу необходимо тимлиду.

• Четвертый — когда ты просто указываешь специалисту проблемную область, даже особо не вникая, что сломано. Это самый сложный уровень. Искать и выявлять проблемы. Люди, которые им владеют, очень быстро вырастают до позиции технических директоров.

Здесь я вспомнил об этих уровнях скорее в контексте руководителей. Для работы с джунами (да и в целом для работы в нашей компании) нужно быть хотя бы на третьем. Только так можно вычленять из общего потока кандидатов джунов с навыками диагностики проблем и нагружать их соответствующими задачами.

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

Организация команд

Тандемы

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

Идею тандемов я подсмотрел очень давно — еще в начале нулевых — в какой-то книжке.  Забавно, что знания из той книги пригодились спустя столько времени. Позже я столкнулся с этими идеями в книге по менеджменту “Это так не работает”. Там это называлось “микрокоманды”. Была высказана мысль, что даже если у тебя есть команда из условно 10 человек, в ней все равно лучше выделить микрокоманды, и они будут работать эффективнее. Либо так или иначе они образуются сами.

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

На собеседовании я смотрю на специалиста и сразу стараюсь понять, кто мог бы быть у него в паре. Т.е. это речь не столько о “подойдет по стеку или нет” (понятно, что человек должен пройти по хардам для текущего проекта), сколько о комплексном видении и хард, и софт скиллов. Причем, я не обязательно подбираю джуна под сениора или ищу, чтобы сениор больше общался с клиентом, показывая пример джуну. Вполне возможна ситуация, когда за счет прокачанных софт скиллов джун, слабый в техничке, и с клиентом договорится, и к коллегам сходит, чтобы ему подсказали грамотное решение. Суть именно в комплексном взгляде. Важно, чтобы тандем — эдакий паззл внутри коллектива — собрался и заработал.

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

Самостоятельность во главе угла

В целом все наши командные взаимодействия построены так, дабы сделать отдельные структурные единицы максимально самостоятельными, чтобы меня не дергали по каждому вопросу. Это единственный способ справляться с большим объемом проектов. Если об этом не заботиться, меня будут все время отвлекать. Это будет абсолютно не масштабируемая история.

Тут важна инициативность в деталях, вплоть до того, что коллегам стоит понимать, как планировать ночные работы и согласовывать их с клиентом (даже если коллеги — чистые технари). Если у клиента принято просто написать в Telegram — это один разговор. Если же надо обязательно подготовить обращение к ответственному лицу и собрать аппрувы — другой. Надо пройти правильным путем, и главное, чтобы я не контролировал эти процессы.

Чтобы был шанс отпустить ситуацию, я объясняю, как сделать правильно, и фигурально выражаясь, “отворачиваюсь”. Если в итоге я вижу, что задача выполнена — хорошо. Моя цель, как тимлида, достигнута. Но так происходит не всегда, чаще инженер совершает ошибки так или иначе. Главный секрет при постановке задачи всегда объяснять преследуемые цели и критерии “когда мы считаем что задача готова, что должно быть готово” используя метод SMART .

Если ошибки случаются, я не жду какого-либо специального one-to-one, а прихожу сразу. Например, мы что-то обсуждаем с клиентом в созвоне и я даю слово инженеру, который делал задачу. А инженер говорит на встрече какие-то глупости. Прямо в процессе коммуникации я, как фасилитатор созвона, могу дать ему отсечку — самостоятельно рассказать, что он сделал более бизнесовым языком. После этого прихожу уже в личку, где мы с инженером разбираем ситуацию — почему я его прервал, какие вещи нельзя говорить клиенту и т.п. Короче, проводим работу над ошибками. Объясняю, как говорить с клиентом в сложных ситуациях, как работать с возражениями, как быть с плановыми работами, как ставить задачи, формировать цели и критерии приемки по SMART.

В целом у нас в коллективе довольно простая атмосфера. На это во многом влияет личная харизма, и я стараюсь это поддерживать. Младшие всегда могут прийти к старшим, да и я выступаю эдаким играющим тренером и равными правами по отношению к остальным участникам коллектива. Мотивировать всех участников к инициативе. Т.е. нет проблем с тем, чтобы сократить количество грабель, на которые наступать. И со временем количество ошибок действительно уменьшается В среднем инженеры уходят в эдакое “самостоятельное плавание” примерно через 4-8 месяцев после начала работы. С этого момента их уже можно почти не контролировать, лишь иногда задавать правильные вопросы. Например, инженер приносит мне план разобрать старый кластер баз данных у клиента. А я спрашиваю, а где план отката и когда ты будешь делать бекапы? Если это не было заложено изначально, инженер идет и переделывает план. Так последовательными итерациями мы приходим к полностью самостоятельному решению.

Джуны всем нужны

Опыт показывает, что джуны — это не так страшно, если уметь их правильно отбирать и готовить. При нормально построенном наставничестве джун до сениора может вырасти за 5 лет. Google считает, что на этот процесс уходит чуть больше — порядка 6-8 лет (корпорация привязывается к циклу жизни продукта и считает, что специалист до уровня сениор должен прожить весь этот цикл в одной или нескольких компаниях).

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

История этой фотографии: в 2020 году набрал команду ребят в коллективе. И был один парень, который «я же джун, у меня не получается, нужно чтобы мне кто‑то помог с задачей».

Подумал, как же отучить от такого. Сходил в большой садоводческий магазин и купил 2 драцены. Принес в офис, поставил и подписал стикеры «джун Федя» и «джун Витя».

Сказал своим джунам: «Если ты будешь называться джуном, поставлю тебя в горшок рядом и буду поливать водичкой».

P. S. Ни одна драцена и ни один джун не пострадали.

Сепарация привела к интересному результату. Из регионов вымыло не столько, и не только квалифицированную рабочую силу, но скорее:
мотивированную рабочую силу, и
мотивирующую рабочую силу.
То есть, в регионах остались не единицы квалифицированных людей, а десятки и сотни, но мотивация «затаскивать» и мотивация «затаскиваться» постепенно заканчивалась.
Люди, умеющие считать, четко понимали, что:
Кризис по образцу 1998, и 2008 года может повториться. В регионах в 2008 году масса людей просто вылетели с работ, в том числе в тепленьком ИТ. В Москве много вылетели, зарплаты просели, кто-то полгода проедал заначку. Но в Москве эта заначка была. В регионах, зачастую, нет.
После 2008, посидев с полгода на картошке с огорода и 6 соток, многие задумались про деньги.
В регионе на линейной позиции в ИТ ты мог (на 2010 год, условно) зарабатывать 15-25 тысяч. При курсе примерно 30, это 500-750$. Кстати, это 50-75 тысяч по текущему курсу.
После всех затрат у тебя оставалось 2-5 тысяч. Квартплата, транспорт, исключительно платная медицина, итд.
При перекате в Москву ты сразу мог уходить на 45-60, на 1500-2000 $. Кстати, это 150-200 к по текущему курсу, то есть не изменилось ничего.
Но, в Москве после вычета аренды (15-20), транспорта (причем, иногда в Моске уже тогда оплачивали проездной) и минимальных расходов (те же 10 к, 300$), у работника оставалось 45-15-10 = 20к. А не 2-5.
Стоит ли говорить, что приток в Москву не останавливался никогда?

Сейчас с этим притоком есть проблема, точнее с его качеством. Причем, проблема многогранная. Или, даже и не проблема.

Проблема первая, квалификация.
Сколько раз сказано, что просмотр видео «берем сперва укропу, ведро воды» - не учит готовить плов.
Сколько раз сказано, что просмотр видео «дети, вот это докер, докер это дети» - не учит понимать, что это, зачем оно, и куда оно. Ну вот докер, да.
Коллеги недавно плакали, громкими слезами, люди пишут в резюме «ставил докер». Если кто не в курсе, то процесс крайне увлекательный и сложный, целых 2 (две) строчки:
sudo apt-get install docker-ce
sudo docker run hello-world

Примечание. В Европе тоже любят писать Python, или Zscaler. Уровень знания - картинку с ним видели, в интерфейс IDE заходили, создать словарь, не говоря уже о загрузке словаря из файла, уже не могут. Fizz buzz не сделают.

Ничего удивительного в этом нет, люди где-то, в 2025 году, под 2019 AD - находят PDC и BDC. Не FSMO, так и пишут – PDC.
То есть, определенная часть поколения после 2000 года рождения, начисто потеряла умение читать, и понимать текст. И до этого у многих были проблемы с пониманием написанного, но, когда человека с 5-10 лет окружает, в основном, видео – он не то что потеряет, он не приобретет умение конспектировать и перерабатывать видео в текст, а текст забивать в МНУ (Межушный нервный узел). На это еще Фейнман жаловался, но соотношение стало хуже, на мой взгляд.

Намазываем на это отсутствие квалифицированных преподавателей (см. вымывание кадров), отсутствие корректной русскоязычной литературы, цыганские курсы, общие верования – и получаем, что получаем.
Изменилось само соотношение. Люди то есть.

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

Поколениям «до 2000 года» - деление, конечно, условное, точнее «поколениям до, примерно, 1980-1985 года рождения» много лет вбивали, что надо «понять, осознать, и покаяться». То есть, если начальник ругается, то нужно стоять и обтекать, вне зависимости от того, прав начальник, не прав. И всегда надо надеяться на светлое будущее. Не подняли зарплату хотя бы по инфляции – ну ничего, потерпим.
Али не выйдем на недоплачиваемые смены? За гроши совестью мужицкой приторговали? Да нет, я по глазам вашим мужицким вижу, что тут зарплатных нет.

До какого-то момента это работало, что в СССР, что в мире. Грамоты, медальки, значки, доска почета – это все работало и работает, но есть нюанс – работает только после закрытия первичных потребностей. В современном мире это своя квартира, своя машина. И только так. Своя квартира пояснений не требует, а своя машина, это не только вывоз тещи на дачу для похорон картошки, это еще и легко реализуемый актив, и в разы лучшая мобильность. Особенно в регионах. Даже в Москве до, примерно, 2010 года. А может и потом.
Сейчас перестало, или стало работать хуже. Genetation Next даже не будет тебе цитировать продолжение поговорки «ты работай дурачок», оно просто уйдет, и от конфликта, из из организации. Рабочая сила стала мобильной, и это хорошо.

НО.
Из того что я слышу в разговорах с приезжающими из РФ, и с оставшимися в РФ бывшими коллегами (опять же, надо заметить, что почти та же ситуация есть и в Европе), что бизнес пока не готов отказаться от двоемыслия и речекряка (Duckspeakers)

Бизнес (говоря про ИТ) прекрасно видит, что нехватку квалифицированной дешёвой силы не закрыть деньгами.
Можно поставить в вакансии заветные 300кк, придут все те же, ничего не знающие, люди.
Можно делать модно, по заграничному, до последнего скрывать размер вилки. И потом плакать, что плак плак, как так, где же люди, почему они все хотят работать за деньги, нас на кратких курсах учили, что мотивация должна быть нематериальной, максимум грамотка. Почему с нас ржут, ведь мы заказали такие красивые блокнотики, а кандидаты при их виде начинают смеяться, ОБИДНО!

Отдельно надо отметить сложности с экономикой некоторых проектов. Проект закладывался, скажем, исходя из того, что 5 программистов по 500к каждому в ФЗП (фонд заработной платы, то есть то, с чего потом возьмут ЕСН, травматизм, потом еще раз НДФЛ, и еще раз возьмут НДС) наработают прибыли на 1.000к в месяц каждый, что окупит и офис, и менеджеров, и макбуки, и еще останется. При 650к проект уже начинает трещать по балансу, при 750к баланс не сходится совсем. И, даже если и сходится, то у любого проекта есть заложенная норма прибыли. Зачем вкладываться в проект с прибылью 10%, когда можно положить деньги в банк под 20%.

Добавляем то, что люди по 500к (до всех налогов) эту катку могут не затащить. То есть не смогут запустить проект. Физически не могут – для одних слишком сложно, другие не могут работать с менеджером, который орет «вы все тут бездари». Минус один программист на проекте означает минус два, потому что, даже если нового тут же найдут, его ж кому-то надо учить. Это базовейшая из баз, мифический человеко-месяц, но кто ж его читал-то?

Добавляем то, что психологически бизнес не готов публично признать, что дешёвые люди кончились.
И часть бизнеса не понимает, как так - техника же работает все быстрее (это правда, все эти авто-дополнения, анализаторы, LLM, co-pilot очень хороши), но почему и раньше на проект надо было 10 человек, и сейчас на проект надо 10 человек.  Нет понимания, почему машзал на 1000 стоек в 2000 году сейчас поместится, пожалуй, в десяток. Почему раньше «огромный» проект занимал 100.000 строк и выполнялся за 5 минут, а сейчас надо 1.000.000 строк кода, и железо в 20 раз мощнее выполняет задачу хорошо если за 5, а скорее за 15 минут.

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

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

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

Удивительно, но труд в РФ не дорожает, если рассматривать в долларе. Как стоил мидл 4000 - 6000$, так и стоит, как стоил сеньор 6000-12000 $, так и стоит. Но нет, мантра 'вы же покупаете в рублях, зачем вам доллары' прочно засела в некоторых головах. Но мидл и сеньор тем и отличаются, что в курсе , что даже в Турции, берут доллары. И что телефон покупается за доллары (или юани). И, слушая эти рассказы, плавно утекают.

Отдельно надо сказать, что в РФ с ростом зарплат в рублях пытаются бороться на самом высоком уровне, но не афишируя этот процесс.
Осенью 2024 менеджмент в РФ пел «сейчас будут сокращения», подразумевая «надо лучше работать, сократим самых отстающих в части ритуальной похвалы меня по утрам».
Сейчас, судя по некоторым крикам боли, оказывается, что сократили или тех, кто реально работал, или тех, кто работал исключительно в части софт-скиллов, то есть много говорил, но ничего не умел.
Новая песня на 2025 – тут у нас обстоятельства, надо потерпеть, повышение, обещанное еще осенью, сдвинуто на следующую осень.

Начинает работать следующий этап сепарации – те, кто готов терпеть, остаются сидеть (но их производительность труда начинает страдать), а те, особенно из Gen Next, кто в этим сказки не верит – берут и уходят. Иногда в никуда, иногда уходят проедать подушку, иногда уходят на мамкины борщи (ТМ), иногда уезжают.
И вот тут бизнес начинает орать – ЧТО Ж ВЫ ДЕЛАЕТЕ, МЫ ВОТ ТАКИМИ НЕ БЫЛИ.
Да были вы, были и остались.

PS.
Полная цитата
General: Now each battalion has a specific code-name and mission. Battalion 5, raise your hands!

General: You will be the all important first defense wave, which we will call "Operation Human Shield".

Chef: Hey, wait a minute...

General: Now keep in mind, 'Operation Human Shield' will suffer heavy losses. But don't lose your spirit men! Stay until the bitter end. Battalion 14?

General: Right, you are 'Operation Get Behind The Darkies'. You will follow Battalion 5 here and try not to get killed for God's Sake. Are there any questions men?

General: Yes Soldier?

Chef: Have you ever heard of the Emancipation Proclamation?

General: I don't listen to hip-hop!
South Park: Bigger, Longer & Uncut

Английский вариант

Русский вариант