Лига Сисадминов

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

В джуны 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. Ни одна драцена и ни один джун не пострадали.