Сколько времени работать на одном проекте?

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

Disclaimer

• Все данные в статье являются моими личными оценками и не являются истиной в последней инстанции.
• Смена проетка - не всегда смена работодателя. А иногда даже и новая роль на том же проекте.

TL;DR: Адекватные сроки:

Но это не точно.

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

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

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

Если менять проект чаще, то это подозрительно

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

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

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

А если менять проекты реже?

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

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

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

Теперь перейдем к срокам

Junior – 0.5-1 год

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

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

Middle – 1-2 года

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

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

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

Senior – 2-3 года

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

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

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

Teamlead – 2+ лет

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

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

Project Manager – 2+ лет

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

Как понять, что мне нужно менять проект?

Я задумываюсь о смене проекта, когда:

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

Если я отмечаю 2-3 пункта, то это повод задуматься об обновлении CV.

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

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