На разных этапах развития продукта всегда стоит вопрос: каким ресурсом этот продукт будет создаваться? Бизнес всегда интересуют деньги, а вот производство превращает деньги в людей. И вот тут возникает очень интересный вопрос — как правильно распорядиться полученным от Бизнеса бюджетом?
Кажется, что логика простая: если денег мало — набираем больше людей попроще. Ну правда, зачем платить одному дорогому специалисту, если можно взять троих подешевле? Больше рук — быстрее дело.
На практике всё не так однозначно.
На старте важен профи. Один сильный специалист — швец, жнец и на дуде игрец. Он видит проблемы за километр, закрывает несколько ролей и строит фундамент, который не рухнет. Такой специалист обходит грабли, потому что набил достаточно шишек.
Интересный случай случился с NASA. В 1999 они потеряли космический аппарат Mars Climate Orbiter за $172 млн из-за того, что одна команда считала в фунтах, а другая — в ньютонах. Инженеров было много. Не хватило профи, который, почесав голову, спросил бы: «Вы вообще в одной системе считаете?».
Найм сильнейших — это не вечный рецепт. Со временем в любом проекте накапливается рутина. И тогда использование дорогого профессионала перестаёт быть оправданным. Приходит время набирать в команду тех, кто возьмёт на себя повседневные задачи, будет учиться, развиваться и расти.
Важно понять: Прирастать только сильными универсалами — болезненно и сложно. Они начинают толкаться локтями.
В маленьких компаниях часто пытаются купить максимум рук за минимум денег. Логика найма смещена в сторону: «давайте подешевле и побольше». Логика понятна — бюджет жмёт.
А в бигтехах перекос в другую сторону. Там нанимают только лучших из лучших. Потому что могут. Только вот взрывной эффективности это не даёт. Звёзды буксуют, затыкают друг друга в обсуждениях, кто-то расслабляется, теряет хватку. И в итоге превращается в балласт.
И тут побеждает не арифметика, а грамотное планирование состава команды.
Один сеньор не заменит троих джунов во всём. Он не позволит запороть фундамент.
А дальше — да, пусть команда растёт. Пусть в неё приходят те, кто возьмёт на себя технические задачи. Только пусть чертёж нарисует кто-то, кто спроектировал и запустил уже не один проект.
Мой рецепт Старт: до 3-х сильных профи на фундамент. Развитие: масштабируем, добавляя руки (ориентир — 1 к 10). Поддержка: переводим звёзд на новые проекты.
Быстро пробегусь по свежему маркетинговому выс продукту, пока он не засох, а у меня обеденный кофе.
Для ЛЛ: реклама Git in Sky, под видом статьи.
Мы умеем брать людей, которые только начинают свой путь, и делать из них уверенных и компетентных специалистов.
В прошлой статье был озвучен штат, 10-12 человек. Джунов там может быть 1 (один).
Сениоров мы рассматриваем сразу на роль архитекторов;
Это принципиально разные роли. Опять пустили маркетологов, и нет бы на хабр, где только маркетинг и остался.
мидлов растим до архитекторов внутри — стараемся построить рабочий процесс так, чтобы они брали на себя больше ответственности: договаривались с клиентом, вели мелкие шаги по проекту
То есть денег нет настолько, что разработчики, или админы, или девопс-инженеры, еще и как РП работают.
я всегда смотрю не столько на технические знания, сколько на софт скиллы и способность принять нашу культуру.
Напоминаю, что эта "культура", описанная в предпоследнем тексте - звонки посреди ночи, и полное отсутствие HA на уровне архитектуры.
Особенность нашей работы такова, что на проекте придется чаще всего оставаться с этими проблемами один на один.
То есть техподдержку вендора не купили, команды нет. Денег нет, но вы держитесь.
На собеседованиях я рассказываю реальные кейсы с проектов: такой-то стек под капотом, приходит разработчик и надо разобраться, почему у него не хватает какой-то переменной на проде. Это придется гуглить и решать, скорее всего самому.
Гуглить, почему в ваше внутреннее окружение дженкинс не затащил переменную? Пустили маркетологов в интернет, интернет от этого тупеет.
Да, говорят, что переработки — это плохо — ненормированный график, нарушение баланса работы и личной жизни и т.п. Но это лишь часть картины. Зато мы можем себе позволить работать всего несколько часов в день, используя в том числе и рабочее время для выполнения каких-то личных дел.
Это означает и отсутствие резервирования, и отсутствие архитектуры, затыкаемое по классике: Мы жуки-плавунцы или мужики российские ржаные гречневые? Али не выйдем на недоплачиваемые смены? За гроши совестью мужицкой приторговали?
Это не просто плохо, это означает почти мгновенный отсев на тех, кто сбегает подальше (нет текучки, как же), и тех, кто остается, и останавливается в развитии.
на 99% все курсы, которые сейчас есть в интернете, построены вокруг изучения только лишь базовых инструментов — как собирать Docker
Из исходников собирать ?
В целом все наши командные взаимодействия построены так, дабы сделать отдельные структурные единицы максимально самостоятельными, чтобы меня не дергали по каждому вопросу.
В предпоследнем тексте звонили в 5 утра, "не дергали". Маркетологи такие маркетологи, не помнят, что писали сами
При нормально построенном наставничестве джун до сениора может вырасти за 5 лет.
Спорно. Начиная с того, что 5 лет наставничества означает потерю 5 человеко-лет 2 сеньоров и 2 мидлов.
После публикации статьи про рабочий день DevOps-инженера меня вдохновило продолжить разговор о том, как мы подходим к найму и развитию наших сотрудников. Сегодня снова общаюсь с Дмитрием, тимлидом DevOps-команды.
"Вы просто не умеете их готовить" Многие компании избегают брать джунов, потому что это кажется долгим и трудным процессом. Но у нас это получается. Мы умеем брать людей, которые только начинают свой путь, и делать из них уверенных и компетентных специалистов. Всё, что нам нужно — это желание развиваться и учиться. И мы поможем в этом.
Как нам удается вырастить специалистов
В Git in Sky практически нет текучки. Команда стабильная, и это даёт нам большое преимущество. Но мы растем, и, соответственно, сталкиваемся с необходимостью найма. Но вместо того, чтобы искать только опытных специалистов, мы выбираем тех, кто будет расти вместе с нами. И для нас это не проблема. Это возможность.
Сеньоры-мидлы-джуны
У Git in Sky очень широкая вилка в плане найма, т.е. мы берем и джунов, и мидлов, и сениоров. На какую роль подойдет человек, становится понятно еще на этапе собеседования. Я сразу стараюсь оценить и уровень, и проект, куда человек хорошо впишется.
Сениоров мы рассматриваем сразу на роль архитекторов; мидлов растим до архитекторов внутри — стараемся построить рабочий процесс так, чтобы они брали на себя больше ответственности: договаривались с клиентом, вели мелкие шаги по проекту, а не просто щелкали задачи с доски.
Джунов также растим, но несколько иначе. В принципе джуны в моем понимании — это не самый низкий уровень. Первый — это интерны. Грубо говоря, студенты, которые уже что-то видели и хотят в джуны. Мы же говорим о следующем уровне, до которого надо еще дойти.
В джуны 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. Ни одна драцена и ни один джун не пострадали.
Работал я как-то в одной IT-компании поменьше, зарплата норм ну типа норм для джуна, работаю себе тихо спокойно баги правлю кофе пью
Тут приходит письмо мол пересматриваем зарплаты в компании. Я думаю ну всё наконец-то заметили мою гениальность
зовёт меня тимлид на разговор и говорит — слушай мы тут оценили твой вклад я уже сижу такой внутренне считаю сколько теперь смогу копить он продолжает — решили что ты молодец и мы тебе поднимем на 1000 рублей
я такой — ммм спасибо а сам думаю как бы это отпраздновать может пачку доширака взять теперь без акции
а через неделю в офис завозят новую кофемашину за 300к. тег мое
Буквально на днях в качестве эксперимента задал алибабаевской бесплатной нейросетке Qwen 2.5 написать скрипт на Powershell (в крышесносном синтаксисе которого я ни в зуб ногой, всегда писал на никсах шелл-скрипты), который будет инкрементально бэкапить виндовую папку с БД через Restic в одну или несколько локальных бэкап-реп, плюс заливать базовый бэкап или инкремент в облако через Rclone, а при ошибках или предупреждениях - отправлять их в телегу в специальный бот.
С рабочей версией v0.1 он справился за 15 минут, а вот версия хотя бы, по прикидкам, v0.3, заняла уже двое суток - при попытке заставить его разбить всё на функции для следования DRY, вынести параметры в конфиг-файл, сохранять параметры окружения в шифрованном виде во вспомогательный файл, опционализировать некоторый функционал AI быстро терял контекст, волюнтаристски выкидывал функции, добавлял баги, неработающий код, в типа "исправленной" версии мог подсунуть текст, ничем не отличающийся от предыдущего и т.д. В общем, расслабляться не стоит, всё время глаз да глаз за ним, в промптах всё время в конце задавал перепроверить полноту измененного кода.
Зато в конце второго дня это был уже вполне юзабельный продукт, даже переписанный в объектно-ориентированной парадигме. Что понравилось - весь код выдается полностью прокомментированный, можно одним промптом запилить юнит-тесты, а анализ ошибок иногда выдавал крайне нетривиальную и при этом верную причину, до которой я бы сам вряд ли додумался (например, парсинг однострочного и многострочного вывода в Powershell несовместимы в плане реализации). Плюс я довольно быстро вник в специфику Powershell и теперь могу сносно понимать, что там происходит. Кстати, забавы ради попросил переписать скрипт на Python и Golang, что моментально было исполнено, но программы ожидаемо не заработали, хоть и основной функционал на первый взгляд сохранялся - нужно было допиливать специфические для каждого языка вещи, и я забил.
Резюмирую: AI - неплохой вспомогательный инструмент, чтобы быстро накидать элементарный MVP, написать небольшую функцию, откомментить код, обмазать функционал проверками на ошибки и т.д. В общем, не писать руками рутину, отвлекающую от реализации бизнес-логики. Но полностью доверить электронному ублюдку написание законченного продукта не получится - кожаный ублюдок должен обладать всеми компетенциями, чтобы отличить рабочий код от нейросетевого гонева.
P.S. Qwen 2.5 очень порадовал тем, что он бесплатен, есть несколько моделей на выбор с разным специалитетом и разным количеством параметров, у него нет ограничений на количество запросов, и он их исполняет в 99.9%. Хайповый DeepSeek же, навскидку, на 14 попыток обращения из 15 выдает "Server is busy". Хотя, когда работает, похожим образом выдает неплохого качества результат. С ChatGPT сотоварищи не хочу возиться из-за пердолинга с оплатой.
