Компания делает каждого инженера-программиста временным сотрудником на 1 год без каких-либо льгот. Это приводит к краткосрочности в коде.

В комментарии вы уточнили свой вопрос как

какие варианты могут существовать, чтобы исправить краткосрочную перспективу разработчиков, которая проникает в код?

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

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

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

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

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

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

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

Это важно, потому что это может привести к одному из двух результатов:

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

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

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

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

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

Поведение ваших коллег основано на их стимулах. Их стимулы установлены на очень высоком уровне.

Я не знаю, какой у вас опыт или какое место вы занимаете в организации, но, поскольку вы даже не имеете права голоса в процессах, используемых для разработки, я не думаю, что вы занимаете место со значительной организационной властью. (Кстати, вы, ребята, используете самую темную форму Dark Scrum, о которой я когда-либо слышал). Ты супер новенький. У тебя нет союзников. Ваш менеджер либо фаталист по этому поводу, либо ему все равно. Ваша организация настолько дисфункционально устроена, что именно HR (т.е. административный персонал) решают, как относиться к разработчикам.

Так что, действительно, у вас есть один вариант:

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

Это именно то, что сказал ваш "звездный временный разработчик", потому что это умная реакция на среду, в которой они находятся.

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

Как предложил @AndreiROM (я не привык к этикету тегов StackOverflow), лучшей альтернативой было бы «предоставить этим людям управлять своим цирком так, как они хотят».

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

Или:

Получите хороший проект, чтобы добавить его в свое портфолио, и выйти из него в краткосрочной перспективе

или...

Попробуйте внести существенные изменения в масштабах всей компании.

Вариант A, вероятно, лучший вариант в целом, и он освободит вас от поиска других вариантов.

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

Мне кажется, что вы разыгрываете проигрышную руку:

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

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

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

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

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

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

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

У разработчиков нет никаких преимуществ, чтобы делать все правильно. Однако есть и преимущество в том, чтобы делать что-то быстро — бонус. Я не видел никаких штрафов за некачественную работу и добавил тот факт, что их контракт может быть продлен или не продлен через x месяцев, и вы фактически лишили разработчиков стимула делать все правильно.

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