Комментарии 22
"Приятно много просмотров получила статья про рабочий день DevOps-инженера."
8,7к просмотров - это очень мало, как и 2 комментария под статьёй. Так что можно считать, что статью никто не увидел. Хотя вопросов по ней должно быть много, т.к. вы там говорите, что являетесь DevOps инженером, тимлидом и архитектором сразу, выполняя в одиночку работу целого отдела. Прочитав сейчас всю статью целиком, могу сказать, что вы работаете на "разрыв аорты", т.е. явно стремитесь к сердечному приступу. По организации труда тоже много вопросов. В общем, компания, где вы работаете, похожа на типичную галеру, где просто сжигают свой персонал в погоне за сверхприбылью.
Дмитрий сути является партнёром, и такой режим работы — это его личный выбор. Конечно, всегда можно найти место, где проще и можно ковыряться в носу. Work-life balance безусловно важен. Если в команде кто-то начинает выгорать, мы снимаем человека с проекта и даём возможность отдохнуть на менее сложном проекте.
Вот тоже это хотел отметить:
Например, могу сходить в МФЦ в обед. Если в этот момент не было инцидента, никаких вопросов.
Обед - ваше личное время, а не рабочее. Чем вы на нём занимаетесь компанию интересовать не должно независимо от наличия инцидентов.
Сама статья хорошая, мне понравилось как Вы расписали принципы, по которым выбираете джунов, сам придерживаюсь похожих подходов.
А как же мнение что джун это одни убытки, он требует слишком много времени более опытных товарищей
Джун - это убытки, когда ты тратишь ресурсы на его обучение, т.е. выделяешь ему ментора, даёшь задачи минимальной сложности и постепенно его растишь до нужного компании уровня.
У автора статьи другой подход. Джун - это расходный материал, который ты кидаешь в самое пекло и оставляешь его один на один со сложной задачей. Справился, молодец, держи следующую задачу. Не справился, ок, ищем тогда другого джуна, а этого просто утилизируем.
Оба подхода имеют право на жизнь. Первый более гуманный и нацелен на долгосрочное сотрудничество, но он не всегда окупается по деньгам, поэтому и говорят, что джун - это убытки. Второй подход - это про ничего личного, просто бизнес. Берём человека, выжимаем из него все соки, а потом выкидываем на улицу и нанимаем вместо него другого.
Самое главное в айти это умение во всем разбираться самостоятельно. Второй подход - как раз про это. Просто не надо лезть в эту сферу если нет этого навыка, тогда и вопрос про "гуманность" не возникнет.
Согласен. Иногда в такие моменты вспоминаю, как сам начинал: программирование в школе на уроках информатики казалось китайской грамотой, и поэтому я даже не пытался вникать в эту тему. Но потом, после школы, как-то от нечего делать пришла в голову одна задача, потом стал думать, а как её я бы решил с помощью Pascal (а знания, к окончанию школы, учителя через нехочу всё же вбили). И как-то думая, разбираюсь и решая алгоритмы (сам, и тогда даже "погуглить" невозможно было), вник в эту тему с головой... Сейчас у меня довольно прибыльный личный проект.
Вам бы с вашим подходом в программирование, да теорию информации
Согласен, для IT это критичный навык
Вряд ли какая-то компания на рынке может взять всех возможных джунов. У нас есть алгоритм отбора джунов, который работает. Утилизируем - не считаю такой термин уместным для сотрудников. Не все люди подходят для всех должностей и всех компаний, и критерии отбора у компаний разные.
А что думаете про джунов 35+?)
Вопрос только за чей счёт банкет. Если за Ваш, то все норм
Но это ж все на собеседовании не выявить. Как решаете эту проблему? Берете всех, кто кажется подходящим, а потом неподходящих увольняете на испытательном сроке?
Официально правильно уволить по тк РФ даже на испытательном задача не простая.
Конечно, такие риски есть. Проверяем на собеседовании желание решать проблемы, софтскиллы и уверенные знания для траблшутинга. Научить проще человека без опыта, который хочет решать проблемы, чем постоянно искать идеального джуна.
Статья оставляет куда больше вопросов, чем ответ, особенно, в совокупности с предыдущей:
Абсолютно не понятно почему же вы не боитесь джунов? Джун без ментора в новом и сложном проекте, как ёжик в тумане. Кто занимается его менторством: лид, который не боится джунов, или синьор/мидл, которому в пару скинули этого джуна, потому что микрокоманды? Брошенный на амбразуру джун (как сие описано в тексте) может либо пойти и стараться сделать (молодец, но не понятно какой ценой по ресурсам и с какой целью и итогом), либо сгореть и уйти. Сколько занимает его адаптация, что считать точкой контроля и определением что это отработанный материал или в нем есть толк? Что за инженеры-джуны такие, что не пошли в одном проекте и тут их внезапно раскрывают в другом: а точно ли в первый раз их корректно определили/онбордили лиды и скольких таких же "неподошедших" за борт вываливается в вашей команде? И самое главное как наращиваются навыки траблшутинга у джунов, ведь одно дело устройство инструментов по списку (точнее список групп инструментов, который ну очень базовый и сложно говорить о заявке на мидла по такому списку), а другое как их применять, трактовать их результаты и решать что нужно что-то менять?
Тандемы безусловно могут быть хороши, но как они ведут себя в условиях недокомплекта - в отпуске/больничном/наборе одного из членов тандема, увольнении ведущего? Второй начинает работать с перегрузом, становится временно не нужным или начинает день сурка с другим инженером?
В условиях неплохой компетенции лида (кое было описано в первой статье) да и в целом потребности в его знаниях (мы ведь понимаем, что лиды все же люди ранее выходцы из инженеров) плюс наличие неких проработанных планов работ от команды/микрокоманды, зачем присутствие ведущего или начинающего инженера на созвонах с клиентами? Лид не в состоянии донести мысль команды до заказчика "нужным языком"? Потратить время и нервы инженера? Прокачать ему софт скилы (коих джуну ещё отчасти рано без бекграунда, а синьору может быть лишнего)? Зачем выставлять своего инженера в не лучшем свете, если за ним приходится на созвоне что-то исправлять при клиенте? Восхищаясь инженерами из поддержки телекома стоит понимать, что конечному заказчику до его инженеров не добраться "на поговорить" и для этого есть выстроенные линии по компетенциям.
Чем же в итоге занимается лид, который не боится джунов: менторством всех новичков и управлением всеми проектами в одно лицо или же "эффективным" распределением обязанностей и подкидыванием новых малообученных ресурсов и задач в текущие команды?
Не боимся джунов, потому что есть четко сформированные задачи и есть базовая компетенция траблшутинга у джуна - это высокая вероятность успеха. Мы проверяем эту компетенцию на этапе собеседования.
Тандем работает над одной задачей, а над проектами работают команды, в которых больше двух инженеров. Так что здесь проблем нет.
Отодвигание джуна от коммуникации превращает его в исполнителя по инструкции. Наша цель - прививать джунам ответственность и самостоятельность, поэтому коммуникация для них важна.
Лид занимается целеполаганием и работой над ошибками, наставничеством.
Если все сто вы описали правда, то это достойное человеческое уважение!
Я тимлид и я не боюсь джунов