Як довго варто залишатися на одному проєкті. 6 кейсів досвідчених спеціалістів

Нещодавно на форумі DOU викликав жваве обговорення топік «Працювати 2+ роки на одному проєкті: норм чи деградація?». У численних коментарях під ним думки аудиторії розділилися. Одні стверджували, що для саморозвитку доцільно змінювати проєкти раз на рік-два. Інші ж переконані, що багаторічна робота на одному проєкті критично важлива для професійного зростання.

Тож ми запитали у фахівців з різним досвідом, як часто треба змінювати проєкти. Хтось працює два роки на одному проєкті, хтось — десять, а хтось змінює їх часто. Показуємо, які є підходи та думки щодо цього.

Вадим Міхневич, Application Architect у SoftServe

«Якщо проєкт приносить задоволення, то навіщо його змінювати? Якщо ж ні, то навіщо залишатися?»

На поточному проєкті працюю рівно п’ять років. У 2017-му він починався як внутрішній стартап/proof-of-concept замовника для переведення старої системи медичної документації на новіший стек технологій. Згодом проєкт визнали перспективним і розширили команду. Його зробили ядром систем документації для кількох проєктів із різних країн — тоді для кожної держави створили окрему команду. Потім були і ротації, і скорочення, і розширення... Відтак у деяких країнах продукти пішли в реліз, а в деяких закрились.

Наразі я працюю в американській команді — вони вирішили змістити фокус із лікарських практик на школи, які також ведуть медичні картки учнів. Значна частина «лікарняного» функціонала виявилася школам не потрібною, тож цей проєкт вирішили відділити від «ядра», яке залишилося для клієнтів з Європи, і прибрати все зайве.

Загалом за ці п’ять років я «пережив» 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 лет в одном проекте, занимаемся визуализацией навигационных систем в автомобильной промышленности. Огромный проект с большим количеством команд в разных локациях.

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

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

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

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

Раньше я работал в небольших компаниях, там на проектах оставался по 2–3 года. С последнего ушел из-за того, что не было четкой методологии разработки.

О частой смене проектов. На мой взгляд, менять проекты по расписанию не стоит. Все зависит от поставленных целей, зарплаты, технологии, коллектива. Если чего-то не хватает или что-то не устраивает, то стоит попытаться изменить это в текущем проекте.

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

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

Антон Мартиненко, Founder у CloudNinja AB

«Частая смена работы поможет вам вырасти профессионально и в зарплате»

Дольше всего я работал в компании YouScan — немного меньше трех лет. И я до сих пор считаю, что это была лучшая работа в моей карьере.

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

Считаю, что долго сидеть на одном месте есть смысл, если:

  • вас повышают каждый год;
  • у вас есть акции компании, и они растут;
  • вы сидите в комфорт-зоне и занимаетесь своими делами/семьей/etc.

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

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

Однако сильно часто менять проекты не стоит, это отпугивает некоторых работодателей. В Швеции отлично работает система откликов (references). Нанимающая компания звонит в прошлые компании и наводит справки о вас. Если вы уходили по-хорошему, то проблем не будет.

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

Максим Павлов, Solutions Consultant у Ciklum

«Каждый может подстраивать проект под себя»

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

Об интересных технологиях. Мне важно, чтобы были интересные технологии. Здесь используются Azure ML, Event Grid, Durable Functions. Множество паттернов и коллегиальное принятие решений по сквозным проблемам типа шины сообщений делают стек актуальным и эффективным.

Также я делаю свой пет-проект в сфере ML. Базовые знания применимы как в работе, так и в хобби. Но на удивление основной проект более интересен и полон вызовов, чем пет.

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

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

До Ciklum я работал Senior .NET в EPAM. Проект, на котором я был, уже отпраздновал 10-летие. Многие ключевые лица до сих пор работают на нем.

В рамках работы на одном проекте были повышения по зарплате, и компания легко на это шла. Кому сейчас сложно с пересмотром компенсации? Рынок диктует правило «удерживай или жди нового, обучай». На замену таланта в компаниях без пула уходит от шести месяцев. В Ciklum это уже давно «проработали», поэтому «скамейка запасных» существует, но на проектах все равно удерживают ребят в разумных пределах.

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

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

Дмитро Дундич, Automation Test Engineer в Intellias

«Проєкт варто змінити, коли на ньому вичерпано можливості професійного зростання»

Працюю в Intellias на проєкті HERE Technologies уже чотири роки. Це проєкт з Automotive Domain. Ми розробляємо й інтегруємо навігаційну систему в інформаційну систему авто. Мені подобається специфіка автомотів-розробки, робота із «залізом», продукти й технології на проєкті, а ще можливість професійного зростання, компенсація.

За цей час стартували підпроєкти, змінювалися клієнти, вендори, сама система, тому не було відчуття, що стоїш на місці. Також я беру участь у внутрішніх процесах компанії: проводжу інтерв’ю, оцінювання, готую документи для пресейлів, ділюся досвідом, виступаю на вебінарах і конференціях.

Про технології та власні пет-проєкти. Загалом на нинішньому проєкті цікаві технології, деякі я обирав і впроваджував самостійно, беручи до уваги також їхню новизну і попит на ринку. Менеджмент вітав такі інновації. Після успішних інтеграцій була можливість розповісти про досвід на внутрішніх і зовнішніх івентах, написати статтю на DOU.

Також мав кілька домашніх розробок, переважно для ознайомлення з новими технологіями. А ще спільні з друзями проєкти, деякі з них переросли в повноцінні комерційні проєкти.

За час роботи на одному проєкті кілька разів змінювали платформу розробки, що вимагало повністю переглянути інструменти. Також були етапи впровадження нових процесів, що давало нові знання та досвід. Професійний розвиток триває постійно.

Про підвищення зарплати та попередні проєкти. Підвищення зарплати відбувається відповідно до професійного зростання та PDP (professional development plan). Іноді до нього вносять етапи розвитку проєкту: його успішний старт або приймання від іншої команди, вирішення складної проблеми або впровадження важливого процесу. Все досить прозоро.

Раніше я залишався у проєктах сервісних компаній в середньому на рік. Однак на теперішньому проєкті, куди я прийшов за рекомендацією друзів, працюю вже чотири роки. Звісно, рекрутери постійно пропонують нові варіанти, але нинішній проєкт і досі цікавить мене найбільше — насамперед, можливістю розвиватися у сфері Automotive-розробки та працювати із «залізом».

Про тривалість роботи на одному проєкті. На одному проєкті є ризики вигоріти, втратити мотивацію чи інтерес. З часом зростає відповідальність і навантаження, тому що твій досвід стає унікальним, до тебе звертається все більше людей із різними запитами. Через те, що розпорошуєшся між активностями, стає важко розвиватися. Тому дуже важливо створити план власного розвитку і контролювати його виконання.

Але є багато чинників, які впливають на рішення залишатися — перспективи масштабування проєкту, його стабільність, план власного розвитку (кар’єрне зростання, здобуття досвіду, компенсація). Думаю, проєкт варто змінювати, якщо професійні можливості на ньому вичерпано.

Варто зважати передусім на перспективи проєкту, а вже потім на те, скільки часу ти в ньому. Тут важливими є такі моменти: цікавість проєкту (продукт і технології), можливість розвитку в компанії, прозорість компенсації.

На будь-якому проєкті є те, що треба вдосконалювати. А отже, є можливості здобути або застосувати досвід, пропонувати інновації, брати ініціативу. Якщо з’являється вільний час, можна розвивати ком’юніті всередині компанії, ділитися досвідом, брати участь в івентах, готувати пропозиції у пресейлах, проводити оцінювання та інтерв’ю.

Сергій Поднос, Senior Engineering Manager у GlobalLogic

«Проєкт варто покидати, коли його цілі перестають бути для вас зрозумілими»

У мене роль директора програми, маю понад 20 проєктів у портфоліо. Одні починаються, інші закінчуються.

Вважаю, що треба планувати свою діяльність на проєкті таким чином:

  • Період адаптації. Тривалість — 1–3 місяці. Якщо не відчуваєте задоволення за цей період, то вийти з проєкту буде слушною думкою.
  • Період вашого внеску в проєкт (contribution). Напевно, це залежить від очікувань, які ви тим чи іншим чином сформували у команди та керівників проєкту. Має сенс закінчити те, що розпочали. Щонайменше для особистого задоволення.
  • Період закінчення проєкту. Тут залежить від того, який внесок ви зробили. Проте це чудова нагода для пошуку того, на чому сфокусуватися далі.

А якщо стається так, що ясної мети немає або цілі проєкту перестають бути для вас зрозумілими, попри всі спроби їх зрозуміти, варто згортати справи та йти геть.

Як це розподілити в часі — усе дуже індивідуально. Може бути рік, а може й п’ять. Якщо проєкт не показує результатів протягом п’яти років, то треба не йти з нього, а бігти.

Маєте важливу новину про українське ІТ? Розкажіть спільноті. Це анонімно.І підписуйтеся на Telegram-канал редакції DOU

👍ПодобаєтьсяСподобалось14
До обраногоВ обраному4
Підписатись на автора
LinkedIn



40 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

На Blind був невеликий срач десь місяць назад по цьому питанню.
Перемогла концепція «earn or learn».
Якщо хоча б один з двох пунктів присутній на проекті — то можна залишатися.
Якщо обидва присутні — то взагалі супер, гребем далі.
Якщо обидва відсутні — міняти проект без роздумів.

Коротко, ёмко и похоже на правду)

Главное что не нашлось среди ребят в статье, которые говорят, что работать в Легаси — хорошо. Потому что в ЕПАМ-е есть такая статья на полном серьезе. И каждый здесь делает свои pet-проекты, наверняка, чтобы отвлекнуться от заросших мхом Энтерпразных Легаси, просто кто об этом честно от имени Галеры признается?

Любой проект через пол года легаси)

Я говорил за те проекты, которые существуют как минимум десяток лет. Увы их апдейт к новому чему-то — очень долгий процесс, и десяток команд на разных сторонах — это не показатель. В их мире появляются синьеры, которые говорят одно и тоже по смыслу: «Все эти технологии, фреймворки — г...» Вот на .NET вполне ты еще встретишь проекты с NHibernate, хотя его давно заменил EF и EF Core, а порой лучше вообще напрямую посылать запросы в БД.

если платят адекватно то почему бы и не работать на легаси.
а то платят гребцам с 10 летним опытом 2-3$К на легаси, в то время когда в стартапах можно иметь 8-10$K + опционы...

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

Я не могу не согласиться, но если на проекте мне нужно проводить больше половины времени на Легаси (то бишь на старых библиотеках/фреймворках), то буду думать менять, хоть и люди хорошие. Понятное дело, что если с командой и менеджментом не лады, то никакой стек не спасет, например, если проект с ограниченным бюджетом, а значит урезание по полной во времени имеет место быть и т.д и т.п. В том примере я как раз радость от «всего нового» и потерял, лезть в проекты где урезают бюджет по полной и заказчик сам не знает чего хочет — 100% умрет такой «стартап».

Лично я там привел пример с NHibernate. Боже упаси с ним связаться как с knockout.js в мире фронтэнда. То, что давно устарело изучать ну никакого желания нет.

один інженер щотижня добирався «блаблакаром» із Вінниці до Чернівців

то про мене, дякую за згадку, цікавий був досвід, тисячі людей у дорозі, які діляться своєю радістю та біллю, спостереженнями та досвідом, і кожного доля невидимою рукою веде уперед із нажитого місця у невідоме, із часом питання безпеки на дорозі стало більш приоритетним, змінився проект і не один, але Чернівці усередині мене так і залишилися теплою згадкою

оставаться в одной компании есть смысл если ты ее владелец=)) и то не факт.. лет через 5 собственники в 90% случаев думают как бы так выйти из операционки..

оставаться в одной компании есть смысл если ты ее владелец=))

это не совсем так первое правило бизнеса это знать сколько твой бизнес стоит в каждый любой момент вот ночью подняли по тревоге вылетать на казахстан и спрашивают «сколько» ты говоришь сколько

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

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

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

палка о двух концах. оставаться долго в одной компании есть смысл , если у тебя вертикальный рост — ты идешь или планируешь идти по пути из девелопмента в менеджеры, потом в менеджеры менеджеров и так далее. если тебе хочется оставаться конкретно в программировании, оставаться на одном проекте долго смысла нет . стагнация скиллов, ничего не меняется (особенно в кровавом ентерпрайзе где жизненный цикл приложений по 10 лет). В этом случае смена дает разнообразный опыт, разные бизнес-домены, разные технологии, расширяется кругозор. Я общался с американцами на эту тему, особенно с «возрастными» которым по 50 лет, у них нормально сидеть в одной фирме по 20-30 лет. Но в мире нашего восточног-европейского не очень стабильного рынка , где инфляция зарплат довольно велика, и большинство сотрудников довольно молодые (возраст играет роль в акцептации перемен) , никто не назовет «джоб хоппером» человека который меняет работу каждые 3-4 года

Я общался с американцами на эту тему, особенно с «возрастными» которым по 50 лет, у них нормально сидеть в одной фирме по 20-30 лет.

справедливости ради «технологии и подходы 20-30 лет» в таких случаях тоже «у них это нормально»

нашли у кого спросить,
задайте этот вопрос «пересiчному обитателю доу» 23х летнему синьеру с о.р. 3 года и с зп $5-6K
что он думает об этом ;-)

синьеру с о.р. 3 года и с зп $5-6K

не_бомбит.жпг.

Как только предложили достаточно лучше условия => бай бай)

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

Все так)
Но надо ж было целую статью запилить

Все зависит от проекта и от вас. Последние 8 лет на одном проекте. Не помню, чтобы было скучно :-)

Трудно писать отзыв о компании, в которой я работаю уже почти 15 лет.
dou.ua/...​myr-mishchenko/feedbacks

От туда — сразу на пенсию)

Растет быстрее, пока не упрется в потолок. Опять же, можно быть очень полезным на проекте, а можно там просто просиживать, и ничему новому не учиться. Я видел и такое и такое.

Понятно, что когда тебе 20 лет и ты джун, то надо менять проекты почаще
Но что если ты лид/синиор и тебе 40? Всё ещё надо прыгать по проектам?

Смотря какая цель)
У одного из авторов — проект это то место где нет проблем)

Ані позиція, ані вік майже ніяк не впливають на особистість людини та її приоритети.

Я, наприклад, до з 35 до 45 всього один раз роботу поміняв, коли вирішив, що з мене досить і треба повертатись на ядро :)

А ось з 45 до 50 вже тричі поміняв проекти, бо ж нова область і треба активно шукати колектив- проект-умови, щоб було найбільш цікаво і комфортно.

Т.е. пилить продукт это уже деградация?)))

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

На продукті більша ймовірність «перейти» в іншу команду.
E.g. ви займаєтесь навігаційною системою, але вирішили попрацювати над оплатами.
В аутсорсі ж висока ймовірність, що на субпідряд захочуть віддати лиш окрему частину проекту і нікуди більше не пустять.
Ну але знову ж таки — ніхто не забороняє знайти більш вдікритого клієнта на тому ж аутсорсі.

Никогда проблем с переходом в соседнюю команду не было, наоборот — бывало работала в 4х командах в течении недели 😂

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

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

Бывает особенность аутсорса более мелкого — разрабы «прыгают» между проектами, плавали, знаем. Разнообразия хотели? Получайте. Только решение нормально продумать не получится ни на одном из проектов и 100% останется нечитаемый толком говнокод.

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

Влиять на результат можно везде, зависит от того, что человек может предложить. Не обязательно какие-то новые фичи в продукт (это обычно работа маркетологов). Можно улучшать сам процесс разработки, причем нет предела совершенства. Я не встречал еще ни одного менеджера который был бы против внедрения новых методов обеспечения QA (например — разработать и внедрить новый фреймворк или методику для интеграционного тестирования)

Я не встречал еще ни одного менеджера который был бы против внедрения новых методов обеспечения QA (например — разработать и внедрить новый фреймворк или методику для интеграционного тестирования)

Могу легко привести контрпример. На твою идею внедрить новый фреймворк ты получишь ответ в стиле «над проектом работает ещё 10 других команд и ни одна из них не заинтересована в этом нововведении». Или даже так " Интеграция этого солюшена в общий тестовый фреймворк займёт 100 часов. Заказчик не готов это оплатить. Можно заняться в своё нерабочее время".

к счастью у нас все проще, мы сами владеем проектом(технической частью) , «заказчик» у нас внутренний — наш БА, и он формулирует только функциональные требования. а как мы это сделаем — тут много свободы

Деградаци — когда это не ваш продукт, когда нету роста или опционов)

С ростом проекта должны расти сотрудники
Если они переросли проект или отстают — то как правило уходят
Все должно быть гармонично и доставлять удовлетворение

Вангую, справді корисна інформація буде в коментарях )

Підписатись на коментарі