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

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

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

Востребованность технологий

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

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

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

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

Естественно, не нужно убиваться, если у вашего работодателя нет какой‑то новой хайповой технологии. Достаточно, чтобы у него были технологии, что упоминаются хотя бы в 50% всех вакансий.

Соответствие задач вашему уровню

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

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

Наличие нужных позиций

Иногда разработчики хотят развиваться в какой‑то конкретной области, которая присутствует у небольшого числа компаний. Этот момент тоже нужно учитывать. Вы не сможете стать архитектором платежных шлюзов, если ваша компания не разрабатывает платежные шлюзы, да и вообще не имеет достаточно людей, чтобы заводить отдельную роль архитектора. Поэтому если при планировании своей карьеры (вы же планируете свою карьеру?) вы выбрали определенную позицию, нужно проверить, сможет ли ваш текущий работодатель вам её предоставить.

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

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

Чувство импакта

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

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

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

Счастливые разработчики видят то, что их труд кому‑то полезен, они понимают, что именно они своей работой делают какой‑то импакт для продукта, для компании и её клиентов.

Культура компании

Можно долго спорить о том, как правильно развивать инженерную культуру в компании, как внедрять инновации, находить поддержку среди разработчиков и так далее.

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

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

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

Правильная жизненная стадия компании

В стартапе ожидается, что разработчик будет получать достаточно большое количество задач, где у него будут расплывчатые требования по типу: «Сделай хорошо» или «Сделай, как себе». Вся ответственность за принятие решений по архитектуре, безопасности, тестированию и CI/CD также будут на разработчике. Также ожидается высокая скорость работы и местами переработки. Но как бонус, разработчик получается свободу и возможность расти по карьере, ибо в растущей компании всегда появляются новые позицию, и те, кто тянут, получают рост.

С другой стороны, мы имеем зрелые компании с огромными it‑отделами, где работа порой ограничивается согласованием спецификаций по 5–6 раундов созвонов с архитекторами заинтересованных сторон, восстановлением консистентности данных для каких‑то пользователей системы и обновлением пакетов в силу устаревания или нахождения проблем отделом аудита. Как итог, мы получаем предсказуемость работы, предсказуемость роста ответственности по грейдам и некоторую веру в светлое будущее с ипотекой и молочным шоколадом в баре компании.

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

И тут нужно понимать, что некоторые разработчики любят гонять чаи и рисовать UML‑схемы, а кто‑то любит писать код и быть на острие прогресса.

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

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

Политика найма компании

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

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

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

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

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

Деньги и бенефиты

IT-рынок довольный честный и прозрачный. Если у вас появится вопрос, сколько получает разработчик вашей квалификации, то это можно узнать очень быстро: - job-сайты, что собирают статистику по ЗП (Хабр, Доу, Джини, Гласдор) и так далее;

• Вилки по вакансиям по рынку на job-сайтах;

• Телеграм каналы с указанием зп в вакансиях;

• Сливы грейдных сеток различных компаний;

• Профессиональные отчеты от HR-компаний по трендам отрасли;

• Личные беседы с коллегами по айтишному бизнесу;

• Обсуждение зп с HR на собеседованиях и первичных созвонах.

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

Поэтому я скажу так, если вы получаете рынок — это хорошо. И неважно, как вы этого добились: инициативой со стороны работодателя, переговорами, контр-офферами или сменой работы. А если вы получаете меньше или больше — это повод задуматься, почему.

Прозрачная оценка вашей работы

«Я видел такое... видел такое, что вам, людям, и не снилось. Атакующие корабли, пылающие над Орионом», разработчики, что затаскивали проект в узкие рамки дедлайна, при этом не имея ни малейшего понимания, хорошо они поработали или нет. И это чувство, что тебя вот‑вот придут увольнять за то, что ты плохо работаешь.

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

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

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

Прозрачные процессы внутри компании

Поговорив с людьми, которые увольнялись из различных компаний, вы можете услышать ответы уровня: «Да, что‑то какая‑то муть началась: то мы запускаем проект, то мы отменяем, то мы набираем людей, то увольняем. Не хочу больше тут работать, вообще не понимаю, что происходит».

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

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

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

Авралы и переработки

Неприятные ситуации иногда случаются, когда приходится что‑то оперативно исправлять или дорабатывать. IT‑системы состоят из множества компонентов, которые, к сожалению, иногда ведут себя не так, как мы ожидаем.

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

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

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

Уважение и адекватность

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

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

И хотя в большинстве компаний будет именно так, порой попадаются компании, в которых руководство ведет себя, словно перед ними сидят не профессионалы, а балбесы, на которых они имеют смелость морально давить, обвинять и угрожать. И, к сожалению, таких примеров в последнее время было немало.

Тут есть лишь один совет: не работать в таких местах и отговаривать свои друзей и коллег не работать в этих местах. Имейте уважение к себе и своему профессионализму.

Вы не боитесь завтрашнего дня

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

Если это про вас, то, похоже, у вас большие проблемы на работе, и чтобы защитить свое физическое и ментальное здоровье, её нужно было уже давно поменять, а вы все тянете и тянете.

Осознаем текущее положение вещей с работодателем

Для того, чтобы адекватно понять, насколько вас устраивает текущий работодатель, берем все причины, которые чаще всего ведут к увольнению, и составляем таблицу вашего текущего положения дел.

В колонке слева мы указываем значимость критерия для себя (для каждого человека что‑то важнее, а что‑то менее важно), а справа ставим текущее положение дел. После того, как вы составите эту таблицу, вы сможете наглядно оценить текущего работодателя и понять, насколько вас устраивает текущее положение.

Обсуждаем проблемы с текущим работодателем

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

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

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

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

Вам что-то не нравится — говорите об этом! Не нужно все держать в себе, накручить и ждать, что кто-то все же заметит ваши проблемы.

Быть услышанным, но непонятым

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

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