Як довго варто залишатися на одному проєкті. 6 кейсів досвідчених спеціалістів
Нещодавно на форумі DOU викликав жваве обговорення топік «Працювати 2+ роки на одному проєкті: норм чи деградація?». У численних коментарях під ним думки аудиторії розділилися. Одні стверджували, що для саморозвитку доцільно змінювати проєкти раз на рік-два. Інші ж переконані, що багаторічна робота на одному проєкті критично важлива для професійного зростання.
Тож ми запитали у фахівців з різним досвідом, як часто треба змінювати проєкти. Хтось працює два роки на одному проєкті, хтось — десять, а хтось змінює їх часто. Показуємо, які є підходи та думки щодо цього.
Вадим Міхневич, Application Architect у SoftServe
«Якщо проєкт приносить задоволення, то навіщо його змінювати? Якщо ж ні, то навіщо залишатися?»
На поточному проєкті працюю рівно п’ять років. У
Наразі я працюю в американській команді — вони вирішили змістити фокус із лікарських практик на школи, які також ведуть медичні картки учнів. Значна частина «лікарняного» функціонала виявилася школам не потрібною, тож цей проєкт вирішили відділити від «ядра», яке залишилося для клієнтів з Європи, і прибрати все зайве.
Загалом за ці п’ять років я «пережив» 7 менеджерів і близько 6 ротацій майже повного складу команди. Довше за мене тут працюють лише двоє людей з боку замовника — Product Owner і Lead QC.
Про причини довго залишатися на проєкті. По-перше, тут немає критичних речей, які викликають хронічний дискомфорт і бажання піти. Графік гнучкий, колеги чудові, із замовником відносини хороші, навантаження адекватне. Тобто зона психологічного комфорту. А це дуже важливо, коли звідусіль штормить — то зі школою проблеми, то зі здоров’ям, то в родині, але є місце, де все порівняно спокійно, логічно і за планом.
По-друге, на проєкті я давно, тож до моєї думки дослухаються. Є можливість просувати покращення, впливати на розвиток проєкту.
По-третє, ми ще не все заплановане втілили, та й беклог далеко не порожній, тож поки що нудьгувати не доводиться.
Про те, як часто варто змінювати проєкти. Усе залежить від проєкту: якщо він приносить задоволення, то навіщо його змінювати? Якщо ж ні, то навіщо залишатися?
Багато хто згадує про потенційну відсутність нового досвіду через незмінний стек технологій на одному проєкті. Але якщо глянути ширше, то це зводиться до того самого питання: чи приносить проєкт задоволення. Просто для когось задоволенням є освоєння нових технологій, а для когось — поглиблення експертизи в тих, що є.
Про технології на проєкті. Наш замовник використовує свій власний фреймворк — таку собі надбудову над Spring+Hibernate. Оскільки ця штука пропрієтарна, на ринку вона не дуже затребувана. Але це не критично — фреймворки постійно змінюються, а базові принципи залишаються.
Втім певним недоліком є те, що цей фреймворк писали під Java 8, і через деякі залежності він не працює з Java 16+. Нам, програмістам, звісно, хочеться використовувати найновіше, але в бізнесу свої пріоритети, і це треба розуміти.
Технічно, крім основного фреймворку (який теж, до речі, розвивається, цим займається окрема команда), довелося на проєкті опанувати кілька суміжних технологій та навичок. Інколи «несподіваних», як-от DSL на JSON або автоматизоване тестування.
Варто мати на увазі, що розвиток на проєкті не обмежується технологіями — це насамперед розуміння потреб бізнесу, бо саме вони формують потребу в технологіях.
Про освоєння нових технологій. Додаткові технології є сенс вивчати, якщо є можливість їх застосовувати. Без цього вони забуваються. Я так уже забув Scala, наприклад. Варто вивчати архітектуру та інженерію, тобто системні підходи, а не конкретні технології чи фреймворки.
Своїх пет-проєктів у мене наразі немає, але у компанії є волонтерські проєкти, на одному з них я підпрацьовую архітектором. Там Java 17, Spring Boot, GraphQL і все по-іншому. Волонтерські — це або з відкритим кодом, або безкоштовні для замовника (зазвичай, якщо замовником є громадська організація).
Про попередні проєкти й зарплату. На одному з колишніх проєктів я працював років 5 чи 6. То була ІР-телефонія для нідерландців. Цікавий був проєкт, але врешті його згорнули через низьку прибутковість. Ще мав кілька коротких — до року-півтора. Зазвичай такі проєкти змінював через закінчення терміну контракту із замовником або через зміну роботи.
У нинішній компанії є періодичні перегляди зарплати, щоб не відставати від тенденцій опитувань на DOU. Ну, або пов’язані з промоушеном. Я на цьому проєкті доріс з техліда до архітектора, тож у мене були перегляди обох типів.
Про цінність роботи з багатьма людьми. Вважаю, найцікавіше на проєкті — це люди, з якими працюєш. Не лише у професійному плані, адже це й коло спілкування. Завдяки періодичним «змінам курсу», ротаціям на проєкті довелося працювати з багатьма людьми, з різними підходами, потребами та пріоритетами. Дуже цікавим виявився мультикультурний досвід — ми взаємодіяли з французами, італійцями, німцями, південноафриканцями й румунами.
Але і серед українців вистачало цікавих особистостей. Наприклад, один інженер щотижня добирався «блаблакаром» із Вінниці до Чернівців (тоді ремоут ще не був мейнстримом), а потім купив машину і став сам підвозити людей у цьому сервісі. І щотижня були якісь історії, пов’язані з поїздками: то він їхав у бусику для хасидів, то гасив по дорозі пожежу, то просто цікавий пасажир трапився.
Інший колега перейшов в ІТ з адвокатури — від нього я багато дізнався про юридичну кухню. Взагалі, в ІТ з інших галузей переходять не лише в Україні — серед колег-американців були і колишній моряк з авіаносця, і колишній археолог. Траплялися і курйозні випадки. Наприклад, одну дівчину тричі скорочували з проєкту, і тричі вона поверталася. Один із німецьких менеджерів, Патріс, через деякий час став Патрісією (не питайте як). Lead QC виявилася не просто Lead, а ще й з найвищої касти брахманів (каста в Індії — ред.).
Усі ці дивовижні моменти, події, історії дають додатковий простір для розмов, жартів, щоб спілкування не обмежувалося коментарями до код-рев’ю та мітингами.
Максим Морозов, Technical Lead у Luxoft
«Если чего-то не хватает или что-то не устраивает, стоит попытаться изменить это в текущем проекте»
Работаю около 10 лет в одном проекте, занимаемся визуализацией навигационных систем в автомобильной промышленности. Огромный проект с большим количеством команд в разных локациях.
Об особенностях работы на долгосрочном проекте. Нынешний мой проект и движок старые, но стараемся внедрять и использовать свежие технологии, насколько позволяет это сделать встраиваемая система.
Направления касательно навигации в автомобильной промышленности развиваются, у клиента постоянно появляются новые пожелания, соответственно пишем новый функционал.
Проект всегда поощряет профессиональное развитие. Организация и оплата тренингов, конференции, программы для обучения и самообучения. Что касается зарплаты, то у меня стабильное повышение. Не помню, чтобы в проекте вопрос с компенсацией у кого-то остро звучал.
О других проектах. Параллельно у меня есть еще несколько личных небольших проектов. Обучение новым технологиям происходит постоянно как на работе, так и в личное время. В частности, на работе организовывают тренинги по технологиям, которые не используются в проекте. Также для себя изучаю то, что мне интересно и не используется в работе.
Раньше я работал в небольших компаниях, там на проектах оставался по
О частой смене проектов. На мой взгляд, менять проекты по расписанию не стоит. Все зависит от поставленных целей, зарплаты, технологии, коллектива. Если чего-то не хватает или что-то не устраивает, то стоит попытаться изменить это в текущем проекте.
В свое время проводил много интервью с кандидатами. И когда видел в резюме частую смену проектов, например раз в год, то сразу оценивал это как серьезный риск для проекта.
Лично для меня важна стабильность в целом, понятно поставленные процессы, коллеги-друзья, материальная стабильность. Как бы то ни было, смена проекта — это всегда риск.
Антон Мартиненко, Founder у CloudNinja AB
«Частая смена работы поможет вам вырасти профессионально и в зарплате»
Дольше всего я работал в компании YouScan — немного меньше трех лет. И я до сих пор считаю, что это была лучшая работа в моей карьере.
Иногда приходилось менять место не по своей воле, например, когда компания закрывала офис разработки. Там, где было все более-менее хорошо, я работал примерно полтора года. Иногда уходил, потому что компания никуда не двигалась и не росла. Или из-за конфликтов. Ну и, конечно же, при переезде в другой город или другую страну.
Считаю, что долго сидеть на одном месте есть смысл, если:
- вас повышают каждый год;
- у вас есть акции компании, и они растут;
- вы сидите в комфорт-зоне и занимаетесь своими делами/семьей/etc.
Во всех остальных случаях, особенно в аутсорсе, частая смена работы поможет вам вырасти профессионально и в зарплате. Раз в полтора-два года. В каждой новой компании вы встретите специалистов с новыми знаниями и подходами к разработке. У них вы сможете чему-то научиться.
Также это позволит построить профессиональные связи с людьми по общим интересам. Это может помочь в будущем попасть в компанию мечты, стартануть бизнес или уехать за бугор. Еще вы сможете поработать с кучей технологий, фреймворков и библиотек, что расширит кругозор.
Однако сильно часто менять проекты не стоит, это отпугивает некоторых работодателей. В Швеции отлично работает система откликов (references). Нанимающая компания звонит в прошлые компании и наводит справки о вас. Если вы уходили по-хорошему, то проблем не будет.
За время работы в разных компаниях я встретил много профессионалов, у которых научился, как разрабатывать софт. Сейчас в Стокгольме знакомства помогают во многом. Например, как правильно стартануть свою компанию и где искать клиентов. Почти в каждой более-менее серьезной компании у меня теперь есть знакомые, которые держат в курсе дел. Это помогает понять, что происходит на рынке и куда лучше не идти.
Максим Павлов, Solutions Consultant у Ciklum
«Каждый может подстраивать проект под себя»
На нынешнем проекте я уже более двух лет. Это разработка облачного решения в сфере финтех для автоматизации работы мировой корпорации. Остаюсь здесь, потому что у проекта большой импакт: пользователи продукта — это тысячи компаний по всему миру. Также, несмотря на мой обширный опыт в сфере, я все еще нахожу, чему учиться у коллег из интернациональной команды архитекторов.
Об интересных технологиях. Мне важно, чтобы были интересные технологии. Здесь используются Azure ML, Event Grid, Durable Functions. Множество паттернов и коллегиальное принятие решений по сквозным проблемам типа шины сообщений делают стек актуальным и эффективным.
Также я делаю свой пет-проект в сфере ML. Базовые знания применимы как в работе, так и в хобби. Но на удивление основной проект более интересен и полон вызовов, чем пет.
На любом проекте каждый разработчик может стимулировать переход к более современному стеку, бороться с техдолгом и легаси. Были проекты, которые «отставали», но я всегда помогал команде и менеджменту устранять проблему, а не бежать от нее.
Об опыте на других проектах и повышении зарплаты. Все мои проекты в жизни, кроме одного, длились по
До Ciklum я работал Senior .NET в EPAM. Проект, на котором я был, уже отпраздновал
В рамках работы на одном проекте были повышения по зарплате, и компания легко на это шла. Кому сейчас сложно с пересмотром компенсации? Рынок диктует правило «удерживай или жди нового, обучай». На замену таланта в компаниях без пула уходит от шести месяцев. В Ciklum это уже давно «проработали», поэтому «скамейка запасных» существует, но на проектах все равно удерживают ребят в разумных пределах.
О бесполезности частой смены проектов. Не согласен с мыслью, что на одном проекте не нужно долго оставаться. Считаю, что каждый может подстраивать проект под себя. В ІТ давно уже прислушиваются к талантам, и вместо того, чтобы менять проект, гораздо эффективнее развиваться вместе с ним.
Сама эта тема вызвана ростом количества «скакунов» по проектам на рынке. Сейчас, по сути, программисты меняют компанию, часто не закрыв онбординг-чеклист на проекте. Четыре раза за год сменил проект, считай, и не работал вовсе, просто репортишь, что «изучаешь исходники» :) Проекты не нужно менять, их нужно изменять.
Дмитро Дундич, Automation Test Engineer в Intellias
«Проєкт варто змінити, коли на ньому вичерпано можливості професійного зростання»
Працюю в Intellias на проєкті HERE Technologies уже чотири роки. Це проєкт з Automotive Domain. Ми розробляємо й інтегруємо навігаційну систему в інформаційну систему авто. Мені подобається специфіка автомотів-розробки, робота із «залізом», продукти й технології на проєкті, а ще можливість професійного зростання, компенсація.
За цей час стартували підпроєкти, змінювалися клієнти, вендори, сама система, тому не було відчуття, що стоїш на місці. Також я беру участь у внутрішніх процесах компанії: проводжу інтерв’ю, оцінювання, готую документи для пресейлів, ділюся досвідом, виступаю на вебінарах і конференціях.
Про технології та власні пет-проєкти. Загалом на нинішньому проєкті цікаві технології, деякі я обирав і впроваджував самостійно, беручи до уваги також їхню новизну і попит на ринку. Менеджмент вітав такі інновації. Після успішних інтеграцій була можливість розповісти про досвід на внутрішніх і зовнішніх івентах, написати статтю на DOU.
Також мав кілька домашніх розробок, переважно для ознайомлення з новими технологіями. А ще спільні з друзями проєкти, деякі з них переросли в повноцінні комерційні проєкти.
За час роботи на одному проєкті кілька разів змінювали платформу розробки, що вимагало повністю переглянути інструменти. Також були етапи впровадження нових процесів, що давало нові знання та досвід. Професійний розвиток триває постійно.
Про підвищення зарплати та попередні проєкти. Підвищення зарплати відбувається відповідно до професійного зростання та PDP (professional development plan). Іноді до нього вносять етапи розвитку проєкту: його успішний старт або приймання від іншої команди, вирішення складної проблеми або впровадження важливого процесу. Все досить прозоро.
Раніше я залишався у проєктах сервісних компаній в середньому на рік. Однак на теперішньому проєкті, куди я прийшов за рекомендацією друзів, працюю вже чотири роки. Звісно, рекрутери постійно пропонують нові варіанти, але нинішній проєкт і досі цікавить мене найбільше — насамперед, можливістю розвиватися у сфері Automotive-розробки та працювати із «залізом».
Про тривалість роботи на одному проєкті. На одному проєкті є ризики вигоріти, втратити мотивацію чи інтерес. З часом зростає відповідальність і навантаження, тому що твій досвід стає унікальним, до тебе звертається все більше людей із різними запитами. Через те, що розпорошуєшся між активностями, стає важко розвиватися. Тому дуже важливо створити план власного розвитку і контролювати його виконання.
Але є багато чинників, які впливають на рішення залишатися — перспективи масштабування проєкту, його стабільність, план власного розвитку (кар’єрне зростання, здобуття досвіду, компенсація). Думаю, проєкт варто змінювати, якщо професійні можливості на ньому вичерпано.
Варто зважати передусім на перспективи проєкту, а вже потім на те, скільки часу ти в ньому. Тут важливими є такі моменти: цікавість проєкту (продукт і технології), можливість розвитку в компанії, прозорість компенсації.
На будь-якому проєкті є те, що треба вдосконалювати. А отже, є можливості здобути або застосувати досвід, пропонувати інновації, брати ініціативу. Якщо з’являється вільний час, можна розвивати ком’юніті всередині компанії, ділитися досвідом, брати участь в івентах, готувати пропозиції у пресейлах, проводити оцінювання та інтерв’ю.
Сергій Поднос, Senior Engineering Manager у GlobalLogic
«Проєкт варто покидати, коли його цілі перестають бути для вас зрозумілими»
У мене роль директора програми, маю понад 20 проєктів у портфоліо. Одні починаються, інші закінчуються.
Вважаю, що треба планувати свою діяльність на проєкті таким чином:
- Період адаптації. Тривалість —
1–3 місяці. Якщо не відчуваєте задоволення за цей період, то вийти з проєкту буде слушною думкою. - Період вашого внеску в проєкт (contribution). Напевно, це залежить від очікувань, які ви тим чи іншим чином сформували у команди та керівників проєкту. Має сенс закінчити те, що розпочали. Щонайменше для особистого задоволення.
- Період закінчення проєкту. Тут залежить від того, який внесок ви зробили. Проте це чудова нагода для пошуку того, на чому сфокусуватися далі.
А якщо стається так, що ясної мети немає або цілі проєкту перестають бути для вас зрозумілими, попри всі спроби їх зрозуміти, варто згортати справи та йти геть.
Як це розподілити в часі — усе дуже індивідуально. Може бути рік, а може й п’ять. Якщо проєкт не показує результатів протягом п’яти років, то треба не йти з нього, а бігти.
