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

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

Меня озадачивает реакция владельцев (менеджера, компании среднего человека или клиента). Кажется, они думают: "Хорошо, если ты уйдешь, я найду другого разработчика, потому что ты расходуешься". Или они думают: "О, это стоит столько денег, чтобы реорганизовать систему? Я знаю другого разработчика, который может сделать это за половину цены. Я нанял его, если я не могу позволить себе". Я предполагаю, что высокая скорость развития разработчика связана с менталитетом владельца: "Мои идеи всегда отличные, и если вы не согласны, я найду другого (возможно, более дешевого) разработчика, который согласен со мной и сделает что я хочу". Для владельцев подход, похоже, работает, потому что их бизнес процветает. К сожалению, это не забавно для разработчиков, потому что они проходят AWOL через 3-4 месяца работы с плохим кодом, строгими сроками и недостаточной обратной связью с клиентом.

Итак, мой вопрос следующий:

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

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

Я видел, как многие компании процветают с симптомами выше. Итак, как программист, хотя мои инстинкты говорят мне, что приведенные выше пункты ужасны, мне нужно сделать шаг назад и спросить: "Неужели это так плохо в великой схеме вещей?" Если нет, Я буду переоценивать свой подход к этим проектам. Я занимаюсь разработкой долгосрочных решений или решений для групповой поддержки?

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

Ответ 1

Все три симптома плохие. Они действительно плохо для бизнеса. Это сказано:

Для создания инструментов существует разработка программного обеспечения. Это. Это не конец, сам по себе - вы производитель инструментов.

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

Ответ 2

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

Ответ 3

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

Ответ 4

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

Ответ 5

Если я могу на минутку взглянуть на Адвокат дьявола:

Некоторые люди любят вызов. Для некоторых людей очень интересные вещи очень интересны, и есть некоторые разработчики, которым нравится находить эти сложные проблемы и работать над ними. С чем-то трудно сделать призывы к некоторым людям.
Оборот означает, что каждый раз, когда кто-то начинает с нуля, а не сохраняет все идеи и мысли, которые предыдущий разработчик разрабатывал для программного обеспечения, что бы он ни планировал делать. Иногда несколько головок могут сделать что-то хорошее. В конце концов, сколько людей разработало Windows 7?;)
Плохо построенный момент - это то, где кто-то может подумать: "О, я могу сиять здесь, исправляя некоторые из этих вещей", и время от времени он может работать некоторое время. Ка-цин!
Отсутствие дорожной карты и почти защита стиля "Ковбойский стиль" может понравиться тем, кто хочет большую автономию и просто двигаться к собственному ритму. В конце концов, кому нужны методологии и лучшие практики, когда у вас есть сверхъестественные способности использовать этот удивительный материал, который не займет времени вообще?
Возникает вопрос о том, что является основной причиной повышения скорости для разработчиков? Это просто, что проект убивает разработчиков или плата настолько плоха, что в любом другом месте лучше или что-то еще? Просто подумайте, как может быть много способов избавиться от разработчика, как в прямом, так и в переносном смысле.

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

Ответ 6

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

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

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

Ответ 7

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

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

Ответ 8

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

Ответ 9

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

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