Резюме

SPL
Кстати, после проведения с десяток собесов и чтения кучи резюме, я понял, что хочу, чтобы кандидаты делали резюме на русском языке для русских. Латиница в резюме полезнее для собесов в англоязычные компании, на мой взгляд.
***
В марте я продолжил ходить на собесы, поскольку повышенной стипендии в 7 тыс на жизнь в 2017 году не хватало, и мне даже пришлось занимать деньги на еду и оплату общежития.
Мне не перезванивали, что явно не красит лицо знаменитых компаний, куда я приходил, но зла держать нет смысла. Просто будьте готовы проявить инициативу и спросить.

И вот в мае Серёга, который тоже не сдавался (потому что я у него занимал деньги), в третий раз порекомендовал меня. В этот раз на новую позицию в T-Systems, где были готовы взять и обучить джуна, который понимает основы. А благодаря школе EPAM я получил нужный базис. Чутка успел подкачать английский, который всё равно был ужасен, но собеседовавший меня мой будущий People Manager, стиснув извилины, смог понять, что же я там плету, вставляя герундий туда, куда приличные люди не вставляют. Спасибо, Илья, что поверил в мой лингвистический и технический потенциал.
Забавно, что в день собеса мой будущий тимлид был в отпуске и ему меня «сосватали» не глядя.

Иван Степаныч радуется
Junior DevOps
17 мая 2017 года — мой первый рабочий день джуном. В команде я и тимлид. Через месяц приняли в команду третьего. Потом разрослись до 6 человек через год.
О, это потрясающая пора в жизни каждого начинающего специалиста: впитываешь знания взахлёб, тупишь над простыми задачами, читаешь сложные книги, гуглишь детские ошибки. Хотя и сейчас точно также гуглю, ничего не изменилось.
Вот базис начинающего специалиста: Jenkins, Linux Administration, Bash, Git. Потом желательно Docker, Kubernetes и/или OpenShift, Ansible, Python.
Само собой, знать сразу всё невозможно. Например, Docker мне на начальных этапах не был нужен, но понимание концепции от меня ожидали и спрашивали на собеседовании. Да и никто не говорит о глубоком опыте в Linux или, о ужас, попросить установить и настроить Jenkins. Так, уметь тыкать в интерфейс, понимать, как его можно использовать в первом приближении. Обучаешься в процессе решения рабочих задач.
А чем старше проект, тем меньше в нём того, что в желательной части и больше Bash. Всё обмотать длинными спагетти Bash-кода — излюбленная автоматизация столь близкого нам прошлого. Как говорится: «Знаешь Bash? Тогда… Иди работай!».

Конечно, в мире ИТ каждому инструменту есть альтернатива и не одна. Так что единого стека технологий даже в рамках одной компании не бывает, хотя и стараются. Подготовиться к определённому стеку технологий можно месяца за два неспешного изучения раза 2 в неделю. Ко всему — месяца за четыре раза 3 в неделю.
В период джуновства большая часть задач относилась к изучению и применению команд в Linux и написанию Bash-скриптов. Ещё лично мне перепала возможность проявить себя как веб-разработчик и создать сайт для отображения информации по хостам. Специфичная для проекта штука. Скринов старой версии у меня нет, так что держите новую версию, полностью переписанную позже моим коллегой.

Здесь пригодился опыт в HTML, CSS, JavaScript, Python. Но если бы не умел, то и не стал бы делать. Так что на заметку можно взять только Python.
Middle DevOps
Прошло 10 месяцев, и меня повысили до «просто» инженера. Здесь важно понимать, что в каждой компании своё понимание того кто такой Junior (младший), Middle (средний) и Senior (старший). И разные зарплатные вилки на позиции. Слышал как-то, что в некую компанию взяли парня джуном за зарплату сеньора. Я понятия не имею, правда ли это, но не исключаю подобного.
Так вот, ведущий эксперт в одной компании может запросто стать мидлом в другой с понижением зарплаты. А вот это уже реальный кейс — информация проверена. Происходит так, потому что стек знаний и инструментов разный. А ещё задачи разные. Это если ты Java-программист, то в любой компании будешь писать код. А если ты DevOps-инженер, то под табличкой может скрываться от разработчика, до специалиста службы эксплуатации.

Как себе представляет специалиста эксплуатации гуманитарий. P.S. Гуманитарии, я вас люблю
После года на проекте началась стадия глубокого погружения в специфику проекта: взаимосвязь основного приложения с помогающими в разработке и тестировании приложениями, изучение со стороны или непосредственное участие в коммуникациях всех или почти всех ролей в проекте. Специфика проекта — самое главное отличие всех проектов друг от друга. Именно специфика создаёт или отнимает конкурентное преимущество.
А ещё специфика способна сделать больно, если её создавали не вы. Но главное — вовремя вспомнить, что мы способны изменить мир, а изменить специфику — нет.
Шучу.
Всё в ваших руках. Будьте настойчивы и берите на себя ответственность, и в вашей жизни пойдёт в гору всё, а не только специфика проекта.
Senior DevOps
Через год, а именно в апреле 2019 года, я повысился до сеньора-помидора. Как говорится: «хочу салат — не вижу препятствий». Ещё говорят, что с большой силой приходит большая ответственность. Вообще, справедливо. Только в профессиональной стезе наоборот: сначала ответственность, а потом подтягивается сила и уверенность. То есть сначала нужно иметь смелость замахнуться на слона и уже потом, на пути, дорасти до его ушей.
В позиции сеньора от тебя ожидают самостоятельного принятия решений, предложения улучшений, ответственности за воспитание подрастающее поколение.
С одной стороны, это этап прокачки вглубь, с другой стороны, так как я стал сеньором уже через два года работы, то мне ещё расширяться и расширяться. Правильнее судить годами. Так вот прокачка вглубь идёт где-то после лет 3-5, если стек не меняется.
Но мир IT изменчивый: сегодня ты пишешь код на Python, а завтра от соискателей требуют прогрессивный Go, поэтому глубинная прокачка всегда сменяется изучением новых инструментов.
Однако побыть сеньором мне не дали…
В начале мая мой тимлид сказал, что уходит из проекта. А так как я с самого начала карьеры показывал своё желание расти до менеджерских функций, то мне предложили стать тимлидом. Конечно, я знал проект лучше всех, но молоко на губах ещё дрожало, и в проекте были коллеги с гораздо большим опытом, чем у меня. Однако, назвался груздём — становись грибом. Так что я стал. Раньше, чем планировал.

Это Гарольд нашёл меня
Вы ожидаете, что здесь будет раздел с названием Team Lead DevOps? А нет, повышение так не работает. Повышают не чаще раза в 9 месяцев, но это в моей компании. Где-то повышают раз в полгода, где-то в год. А вообще, спланировать график повышения невозможно наверняка, так как он зависит от твоих успехов и чуткости руководителей. Можно и за два года не получить повышение.
Однако функции тимлида пришлось выполнять уже сейчас. Первые 3-4 месяца было особенно напряжно и непривычно. Куча коммуникаций. Множество задач у всей команды, в которых нужно ориентироваться. Постоянно приходят тестеры и разработчики и что-то спрашивают или просят сделать. А так как на мне большая база знаний, то делегировать без обучения не получается. Написанные инструкции ситуацию не спасают. Среди более опытных коллег ощущаешь себя не на своём месте. Вместе с этим появляются новые микросервисы, где нужна наша помощь. В общем, потно-плотно.
***
В октябре 2019 поехали в Германию, чтобы встретиться с коллегами из Польши и Немеции. Да, я взял на себя роль тимлида, но только лишь питерской команды. Ещё по двое коллег были из этих стран. И формально, тимлид всей команды был в Германии. К сожалению, по большей части формально.
В октябре мы поняли, какой жуткий рассинхрон у нас произошёл.
Несмотря на созвоны трижды в неделю и периодические командировки, у нас не было общего мнения по одному важному вопросу. Связывали мы это на питерской стороне с тем, что коммуникации на английском языке мешают нормально объясняться, плюс сопротивление предложению со стороны иностранных коллег. В итоге на создание демо было потрачено 6 месяцев одним человеком. И после показа решение забраковали. Потому что на такие изменения команда эксплуатации не готова, ведь мы только 6 месяцев как внедрили новый подход.
Просадка в коммуникациях и взаимопонимании била по самооценке и настрою в команде. После этого случая я старался не выпускать активности вообще всех коллег из виду и вовремя реагировать и инициировать обсуждение и не пускать решение в разработку, пока не решим, что путь выбран верный.
В команде из 10 человек задача более-менее посильная, но усложнённая языковым барьером и расстоянием между всеми. Да и не только ведь этим приходится заниматься.
***
К ноябрю немецкий тимлид сообщает, что уходит в учебный отпуск до начала марта. И учиться он пошёл, не поверите, в школу DevOps.

Так вышло, что он не был DevOps специалистом изначально в проекте. Он начал как разработчик и затем постепенно перешёл в Инженеры Конфигурации ПО. И, вероятно, неожиданно сам для себя стал тимлидом в 2017 году. Так что выбрать DevOps-школу было верным для него решением.
Однако тогда я думал, что причиной послужила ситуация на проекте…
***
В ноябре было принято решение сбавить темпы разработки и начать пилить большой монолит на маленькие кусочки. И я воспринимал немецкую DevOps-школу для тимлида как кусочек общего пазла, который подготовит нас к переменам, чтобы войти в них эффективно.
С ноября я начал замещать тимлида. Пытался придерживаться свежесозданной дорожной карты. Пытался, потому что точного понимания происходящего у меня не было. В создании карты участия я не принимал. А когда её презентовал тимлид, то я не понимал как её можно улучшить и правильно использовать. Однако, имея план, руководить проще, чем не имея.
Новые обязанности выполнял я, откровенно говоря, не очень. Только отошёл от шока тимлидства в Санкт-Петербурге, как теперь ещё плюс две локации. К тому же полноценным руководителем я себя не ощущал: функции тимлида нигде не описаны, примера для подражания не было. На что опираться?
Поэтому как я могу руководить всеми? Да ещё более опытными иностранными коллегами. К своим я постепенно привык и освоился, а тут новая партия подъехала. И ладно бы партия стандартного калибра, так ведь один из снарядов такой бронебойной силы, что чуть отвернёшься, а у тебя чат 30-ю сообщениями завален от него и новая Bash-портянка готова. Bash — это хорошо, Bash — это здорово. Однако нужно понимать, когда нужно использовать Bash, а когда другой язык или инструмент.
***
В январе 2020 приехало повышение за июнь. Снова ожидаете Team Lead DevOps заголовка? А не будет его. Тимлид — это роль, а не должность. Так что вряд ли вам напишут в трудовую книжку руководительский подвиг в технической команде. Вам нужно в Project Manager'ы для этого идти.
Получается, что тимлидом может быть и джун. А меня повысили до…
Expert DevOps
Январь и февраль прошли. Вернулся немецкий тимлид. «Наконец-то!» —, подумал я. За это время у меня сложилась картина, что нужно делать, чтобы повысить нашу эффективность: как правильно создавать дорожную карту, распределять задачи, выстраивать коммуникации, обсуждать, проверять чужие решения.
А я уже представляю, как всё это ему рассказываю. Как он кивает головой, говорит: — «Sure», — и вокруг нас расцветает малина.
Но нифига.
Вернувшись в проект, тимлид не забирает на себя свои обязанности, типа проведение созвона для сбора статуса. Не интересуется задачами коллег. Не инициирует беседу, если видит что-то непонятное для себя. Ведет себя абсолютно пассивно. Я понимаю: первую неделю или две, но ведь уже апрель.
Тогда я решаю, что хватит ощущать себя пушистым сопляком и беру бразды правления в свои руки в полную силу. Начинаю свободнее ввязываться в темы, которые не затрагивают меня и мою экспертность. Отслеживаю все активности и поднимаю вопрос о целесообразности сделать так или иначе. Создаю слепок дорожной карты, но итоговый вид обсуждаем все вместе, чтобы каждый ощущал свою причастность и ответственность. Структурирую доску с задачами, чтобы в ней было легко ориентироваться и приоритизировать. Поднимаю вопросы по изменению процессов в проекте с релиз-менеджерами и отделом эксплуатации. В общем, выпустил внутреннего бычка.
И под конец апреля выясняется, что текущий тимлид ещё зимой принял решение уйти в другой проект, где проходил практику от DevOps-школы. Только теперь на позицию специалиста эксплуатации.
Тут мне стало понятно почему он так легко отнёсся к «отжиму» обязанностей с моей стороны.
Наши дни
Как вы догадываетесь, с июня 2020 года я считаюсь тимлидом международной команды Инженеров Конфигурации Программного Обеспечения (написал с заглавных букв, потому что так красивее). Делает ли это меня экспертным экспертом? Да нифига.
За год руководства я значительно остановился в скорости инженерного развития, поскольку стал коммуникатором и наставником в большей степени, чем инженером. Однако я нисколько не разочарован своим выбором. Я на своём месте, пусть даже и понимаю, что однажды придётся начать итерацию роста до тимлида заново.
Каковы мои дальнейшие возможности? Их несколько.

• Ничего не менять с точки зрения позиции. Продолжать «лидить», параллельно изучая новые инструменты и углубляя знания. Рано или поздно дойти до позиции архитектора по DevOps профилю.
  
• Перейти в другую команду и снять с себя роль тимлида. Сосредоточиться на изучении новых инструментов и прокачиваться как инженер. Рано или поздно дойти до позиции архитектора по DevOps профилю и роли тимлида.
  
• Пойти в менеджерскую ветку. Мне предлагали рассмотреть роль Scrum-мастера. Неожиданно, правда? Однако сейчас такой возможности уже нет, ввиду организационной трансформации в компании в матричную структуру. Вообще, это не единственный способ перейти в менеджмент в T-Systems, однако подробности за рамками этой статьи.

Позиция руководителя мне привычна и вызывает больший отклик. Тактики, стратегии, психология и социология — one love. Однако здесь важно быть увлечённым проектом/продуктом. Что для меня задача не из простых. Чтобы вы понимали что я за человек: я мог бы открыть точки продажи кофе, пиццерии, производство пластиковых упаковок, свою криптобиржу, однако я не хочу делать то, что или деструктивно, или вредно, или бесполезно. Даже если это окупается моментально или приносит сверхприбыли.
Так что заряда огня мне хватит до тех пор, пока я получаю новый опыт. Это может быть достаточно долгий путь, но в скором времени идти в Scrum-мастера у меня желания нет.
Так что или 1-ый или 2-ой вариант. Желаю себе успехов на одном из них!

Послесловие и благодарности
Вообще, я бы хотел стать знаменитым певцом…

*Играет музыка*
Ну что поделать — всему своё время. Сначала научусь петь.
Буду рад любому фидбеку в комментариях. Ну а если я заинтересовал новой профессией и у тебя есть вопросы, то пиши туда же.
Кстати, есть ещё одна возможность стать DevOps-инженером быстро и безболезненно.
В сентябре планируем открыть набор в DevOps-школу в T-Systems. Точнее будет понятно в начале или середине августа. Участие бесплатное и с трудоустройством после успешного завершения. Из требований: Linux на уровне пользователя и английский. В программу обучения входят упомянутые и неупомянутые в статье инструменты: Kubernetes, OpenShift, Jenkins, GitLab, Ansible, стек для мониторинга и ещё немного других полезностей.
Я один из лекторов школы. Так что у тебя есть шанс попасть на мою вводную лекцию о таинственном однорогом звере.
За мой карьерный путь, наставничество и чуткость руководства благодарю моего бывшего тимлида питерской команды Сергея Жекписова (я капец как многому у тебя научился!), моего пипл менеджера Илью Семерханова, руководителя направления Дмитрия Жаркова и моих коллег, когда-либо работавших вместе со мной.
Сергей Ли, без тебя я бы и не начал этот путь. Ты знаешь мою благодарность, дружище.
Большое спасибо Иномджону Мирджамолову за первое прочтение и предложенные правки в данной статье, а также отделу коммуникаций T-Systems.
Моя текущая команда, вы суперские, мужики! Жму ваши виртуальные руки.
===========
Источник:
habr.com
===========
Похожие новости:

• [Управление продуктом, Управление проектами, Управление разработкой] Что делать, если в вашей команде появился «эффективный» менеджер?
  
• [Amazon Web Services, DevOps, Magento, Интернет-маркетинг] Adobe Community Meetup #15
  
• [Карьера в IT-индустрии, Разработка игр, Удалённая работа, Управление персоналом] Ещё 5 профессий, нужных в геймдеве
  
• [DevOps, IT-компании, Конференции, Управление продуктом] Продуктовый разворот: от фигачечной к сознательной работе инженеров
  
• [IT-инфраструктура, DevOps, Микросервисы, Kubernetes] Повышаем безопасность микросервисов с Istio
  
• [DevOps, Настройка Linux, Облачные вычисления, Серверное администрирование, Системное администрирование] Основы Ansible, без которых ваши плейбуки — комок слипшихся макарон
  
• [DevOps, Системное администрирование] Новый HAProxy Data Plane API: два примера программной конфигурации
  
• [Apache, DevOps, Nginx, Разработка веб-сайтов, Серверное администрирование] Расширенная настройка web сервера (Nginx + Apache2)
  
• [Agile, Интервью, Управление персоналом, Управление проектами] Точка кристаллизации негатива в команде: Как ее найти и что с ней делать?
  
• [Amazon Web Services, Kubernetes] Изоляция и бункер (Silos) для хранилищ данных в мультиарендных (multitenant) решениях

Теги для поиска: #_devops, #_upravlenie_proektami (Управление проектами), #_devops, #_upravlenie_komandoj (управление командой), #_upravlenie_proektami (управление проектами), #_blog_kompanii_tsystems (
Блог компании T-Systems
), #_devops, #_upravlenie_proektami (
Управление проектами
)