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

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

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

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

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

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

Позвольте мне на мгновение взглянуть на это с точки зрения Защитника дьявола:

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

• Оборот означает, что каждый раз кто-то начинает с нуля, а не сохраняет все идеи и мысли, которые были у предыдущего разработчика при создании программного обеспечения, для чего бы оно ни было предназначено. Иногда несколько голов могут помочь. В конце концов, сколько людей разработали Windows 7? ;)

• Плохо построенная точка - это когда кто-то может подумать: «О, я могу сиять здесь, исправив некоторые из этих вещей», и иногда это может работать какое-то время. Ка-цзин!

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

• Возникает вопрос, в чем основная причина текучести кадров для разработчиков? Просто проект убивает разработчиков или зарплата такая плохая, почти везде было бы лучше или что-то еще? Здесь есть над чем задуматься, поскольку существует множество способов избавиться от разработчика, как в прямом, так и в переносном смысле.

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

Я обращусь к каждому из ваших трех пунктов по очереди. Высокая текучесть кадров в любой отрасли считается плохим фактором для бизнеса и проблемой управления. Тем не менее, я прочитал несколько книг о корпоративной политике и культуре, а также о том, как они влияют на прибыль компании. В одной книге, которую я прочитал, за 20 лет было изучено несколько крупных корпораций. Было обнаружено, что ядовитые культуры растут медленно и, как правило, являются «запаздывающими индикаторами» проблем с производительностью. Также выяснилось, что когда некоторые компании смогли нанять нового генерального директора, который в конечном итоге «перевернул корабль», потребовалось 10-15 ЛЕТ, чтобы остановить кровотечение. Итак, с ОЧЕНЬ большой картины, да, текучесть кадров ядовита, хотя на самом деле это симптом более серьезной проблемы. Симптом, который нельзя игнорировать. (Хотя обычно это игнорируется в течение длительного периода времени. Вы когда-нибудь замечали, что HR требуется очень много времени, чтобы понять, что текучесть кадров в отделе может быть связана с плохим менеджером?)

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

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

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

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

Все эти три вещи не очень хороши, позвольте мне сосредоточиться на текучести кадров. Я наблюдаю, как это происходит прямо сейчас. Руководство/компания ведут себя дешево, поэтому их мало волнует команда, технология или процесс, только нижняя планка. В свою очередь (со временем) члены команды не заботятся о проекте, только о своей прибыли. Через несколько месяцев они решают, что не стоит напрягаться, и уходят. У нас небольшая команда из 6 разработчиков, в этом году 3 человека хотят уйти, и это только июль. Два человека пришли, еще один на подходе. Кажется, все, что мы делаем, это переход и смена проектов. Команда не развивается и неэффективна. Наш заказчик чувствует это, и вместо того, чтобы дать команде больше проектов (больше денег для компании), они ограничивают ее определенными приложениями. Интересно, когда руководство поймет, что быть дешевым - это дорого!