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

А зачем воообще менять проект?

Казалось бы, зачем нужно что-то менять? Зачем менять работу, если все устраивает? Каждый выбирает сам, но для себя я решил: не только я отдаю что-то проекту, но и проект – мне. Когда я рассматриваю новые проекты, то я пытаюсь найти нечто, чему я могу научиться. Есть афоризм: нужно быть самым глупым в комнате. Такой же аналогией я руководствуюсь и при смене проекта. Нужно искать людей, у которых можно и нужно научиться чему-то новому для себя.

Смена проекта имеет смысл для специалистов, которые только в начале своей карьеры. Для состоявшихся разработчиков для смены работы есть и другие причины: интересная предметная область, другой стек технологий, опыт работы в распределенной команде либо новая роль в команде. Задуматься о новом проекте стоит, когда ты чувствуешь, что делаешь изо дня в день рутину и ничто тебя не может удивить. Работа должна приносить удовольствие

Как часто стоит менять работу?

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

Частая смена работы – это подозрительно, на мой взгляд. Если специалист меняет компании раз в полгода, то это может быть признаком того, что:

  • человек не умеет выбирать компании/проекты и быстро уходит, так как ошибся с выбором
  • человека “просят” уйти, так как он не сумел влиться в команду
  • человек импульсивен и готов легко оставить начатое дело.

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

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

Если разработчик давно работает в компании, которая предоставляет аутсорс/аутстафф услуги заказчикам, то я смотрю на сроки смены проекта. Если же человек “сидит” в одной продуктовой компании долго, то это повод задуматься для меня. Наблюдал ситуации, когда люди в продуктовой компании для удержания своего места

Junior – 1 год

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

Middle – 1.5-2 года

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

Senior – 2-3 года

Для сеньорских позиций нормой я бы рассматривал сроки от двух лет до трех даже. Уровень ответственности, возлагаемый на сеньора, предполагает не просто разработку и перемещение тикетов из статуса TODO в DONE, но и построение новых процессов, и влияение на качество разработки проекта. От сеньора я жду и ответственность за ведение какого-то модуля в системе, и менторинг коллег с меньшим опытом. Следовательно, результат работы сеньора будет наблюдаться только спустя время, а не через две недели спринта. Более того, я жду, что сам специалист понимает это и наблюдает за примененными изменениями. Если же разработчик считает, что “сейчас запилим по-быстрому, а там хоть трава не расти”, то это я характеризую как красный флаг к тому, чтобы его нанять.

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

Teamlead – 2+ лет

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

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

Project Manager – 2+ лет

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

Не только цифры

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