Как быть с начальником, потерявшим связь с современной разработкой программного обеспечения?

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

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

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

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

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

Каковы наши/мои варианты? Ему не интересно ни читать наш код, ни слушать рассуждения нас, крестьян-разработчиков.

В духе SO, что вы пробовали до сих пор? Делали ли вы какую-либо легкую для понимания документацию или презентацию, которая ясно показывает, почему текущая система несовершенна и почему она не расширяема? Можете ли вы показать ему, как текущая система не сможет реализовать ожидаемые функции?
Разве (не был) ваш босс разработчик? --- "По его мнению, на это потребуется максимум несколько дней" --- Скажите ему, чтобы он взял клавиатуру и написал это максимум за несколько дней.
В нем не рассматривается, как вести себя с боссом, но для начала вы должны убедиться , что применяете рекомендации из книги « Рефакторинг — это особенности» .
Я не знаю, в каком именно секторе вы работаете, и на самом деле я не знаю точно о 90-х, потому что моя первая работа началась в 2000 году . в 90-х, чем сейчас. Насколько я знаю, как раз наоборот. Итак, почему босс (с его мышлением 90-х) недооценивает это время? Похоже, что, хотя у вашего босса действительно могут быть проблемы с современными методологиями, существенная проблема заключается в том, что босс сильно недооценивает, насколько сложной и непостижимой стала кодовая база с течением времени.
@ user128738, я слишком опоздал на эту вечеринку, но мне бы очень хотелось узнать, что это за «язык программирования 90-х». Я имею в виду, что VB из 90-х, но Java тоже из 90-х.

Ответы (16)

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

Если бы вы работали в транспортной компании и рекламировали грузовики 30-летней давности, вас бы сочли сумасшедшим (может быть?), но в компании-разработчике программного обеспечения все не так, в основном потому, что никто не может «видеть» код — они увидеть веб-сайт или интерфейс приложения.

У многих известных компаний были проблемы с отказом от устаревших систем, Microsoft — первая, кто приходит на ум со своим Windows Phone 6.0. Я думаю, что во многих случаях компания в конечном итоге становится жертвой собственной «дойной коровы» или «устоявшейся экосистемы», которую в конечном итоге заменяет инновационная система какого-либо конкурента.

Мой опыт показал, что несвежая среда способствует саморекламе: босс выбирает лейтенантов, которые с ним согласны, они вынашивают и продвигают схожие идеи, а менеджеры среднего звена и прогрессивные мыслители оттесняются, превращаясь в кодовых обезьян. Это стоит бизнесу миллионы, но потому, что все руководящие должности остаются за людьми, которые боятся изменить курс из-за страха потерять свою власть. Порочный круг, который не прерывается до тех пор, пока компания в конце концов неминуемо терпит неудачу (Yahoo? Blackberry). Я работал в крупной климатической компании и точно знаю, что один из проектов, над которым они работали за последние 2 года, обошелся им более чем в 5 млн (моя оценка), когда его можно было сделать в 10 раз дешевле и в 3 раза быстрее. .

Если среда, в которой вы работаете, слишком устарела, вам следует подумать, в каком направлении вы строите свою карьеру. Вы младший разработчик, изучаете Fortran/Cobol/VAX...? Вы убеждены, что если вы разовьете какие-то устаревшие навыки, то сможете найти другую работу?

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

На самом деле это очень хорошо описывает окружающую среду. Это не так плохо, как Fortran/Cobol, но все же слишком ограничено, чтобы соответствовать современным требованиям, таким как сенсорные возможности, интегрированный внешний вид ОС и даже совместимость с современными ОС.
«Если бы вы работали в транспортной компании и рекламировали грузовики 30-летней давности, вас бы сочли сумасшедшим (может быть?)» — Вы никогда не арендовали у U-Haul, не так ли?
+1. Я сделал именно это в прошлом году, и моя новая среда продвигает современное мышление, новейшие инструменты и лучшие практики. Это делает меня лучшим инженером и гораздо более счастливым сотрудником.
Я так и не понял, что так много программистов всегда хотят заниматься рефакторингом кода. Серьезно, я ненавижу писать код, который абсолютно ничего не добавляет, просто чтобы иметь более чистый стиль кодирования или что-то в этом роде. Конечно, бывают ситуации, когда вам нужно полностью заменить код, но в большинстве случаев я бы сказал, что достаточно заменить части кода или добавить новый функционал с использованием новой технологии и некоторых интерфейсов.
И на самом деле - знание Кобола или Фортрана было бы большим плюсом, если вам нравятся эти языки (или, по крайней мере, вы можете их понимать). Такие программисты пользуются большим спросом и очень хорошо оплачиваются, особенно в среде мэйнфреймов или крупного бизнеса.
thursdaysgeek уже связал эту статью . Прочтите это. Также это . Не путайте инновации с неспособностью распознать ценность уже проделанной работы. Или, конечно, вы не ошибаетесь (за исключением Кобола, вы действительно очень ошибаетесь в этом, я имею в виду вообще), но это не так просто, как старое скучное и устаревшее, мешающее свежему и новому.
@dirkk: рефакторинг ради рефакторинга - ужасная идея. Не стоит нарушать работающую систему только для того, чтобы сделать код красивее. Но рефакторинг определенно имеет место быть. Я видел старую систему bacnet com, которая была разработана для модемов со скоростью 1200 Кбит/с, что делало ее чрезвычайно загадочной и понятной только для нескольких DLL, написанных давным-давно на C, вызывающих всевозможные проблемы, когда вы пытаетесь использовать их во внешнем интерфейсе C# MVC. . Есть время и место для рефакторинга, не игнорируйте его, иначе пострадают ваши будущие проекты.
@NathanCooper: Проблема возникает, когда исходный пул разработчиков для конкретной технологии иссякает. Если вы не поспеваете за современными технологиями хотя бы в скромном темпе, вы можете проиграть ловкому конкуренту. В статье перечислены неудачные попытки перезаписи. Но можно только представить, как бы выглядела мобильная среда, если бы Microsoft осознала необходимость переписать WinMo, как только увидела iPhone, подобно тому, как это произошло с Android tech.fortune.cnn.com/2013/12. /20/…
Простое замечание: COBOL действительно хорош для 1) перемещения блоков данных и 2) добавления чисел. Удивительно, но многие задачи сводятся к этому. Тот факт, что код устарел, не означает автоматически, что он устарел.
@ ThorbjørnRavnAndersen, если бы вы только что основали компанию, которая будет заниматься «Следующей великой вещью в Интернете», вы бы использовали Cobol? Не только с технологической точки зрения, но и с точки зрения бизнеса: найти квалифицированную и дешевую рабочую силу. Да, это устарело.
@user19202 Вот отличная история о том, как выбор правильного языка программирования помог автору добиться успеха и заработать много денег: paulgraham.com/avg.html - в его случае это был Lisp (который, кстати, тоже старый). Также стартапам не нужно искать квалифицированную и дешевую рабочую силу — им нужен свободный электрон ( randsinrepose.com/archives/free-electron ), чтобы действительно сиять.
@ ThorbjørnRavnAndersen, чтобы стрелять в цель на поле боя, вы все еще можете использовать арбалет, и вы можете утверждать, что он лучше, потому что он скрытен и т. Д. И все же он все еще устарел в современном бою, независимо от того, используется ли он в очень редких случаях .
@ user19202 Я проработал девять лет в компании, где основной продукт был написан на языке COBOL, а скорость языка при перемещении данных и добавлении чисел в сочетании с гибкостью базовой операционной системы позволила нам зарабатывать на жизнь, просто будучи возможность настроить продукт по вкусу каждого клиента и при этом снизить сложность. Поскольку я программист на Java, пишущий программы, дополняющие программы на языке COBOL, я полностью понимаю сильные и слабые стороны обоих.
Обратите внимание, что если вы не возражаете против поддержки древнего кода, это доходит до того, что люди, свободно владеющие COBOL, редки и ценны...
@keshlam сравните это с тегом «ручная работа» на различных товарах, которые вы можете купить. Скорее всего, художник, который своими руками изготовил, скажем, обеденный стол, хорошо на этом заработал. Тем не менее, большая часть денег на обеденных столах в целом зарабатывается не мастерами, а промышленными предприятиями, которые поддерживают свою производственную цепочку, по крайней мере, достаточно современной. Кроме того, существуют сложные товары, такие как компьютерные чипы, которые невозможно изготовить даже с помощью устаревших инструментов. То же самое и с программным обеспечением — устаревшие технологии могут приносить прибыль, и есть вещи, которые вы не можете создать с их помощью (разумно).
Я не защищаю старые технологии — далеко не — но лучшей аналогией были бы ребята, которые делают музейный ремонт антикварной мебели. Современная мебель прекрасно работает и намного дешевле. Но если у вас есть старая часть, и она все еще делает то, что вам нужно от нее, вы можете продолжать использовать ее, потому что вам удобно с ней, и поиск замены, которая согласуется с остальной частью набора, будет более неприятным, чем Вы можете оправдаться прямо сейчас.
Мои деньги на Visual Basic.
Давайте также не будем забывать о том, что если вы очень опытны в обращении с молотком, внезапно все начинает выглядеть как гвоздь...
@keshlam мы, древние, те из нас, кто говорит о ленточных накопителях, перфокартах и ​​дискетах, сохранили много мудрости
@user19202 user19202 , если бы вы только что основали компанию, которая будет заниматься «Следующей великой вещью в Интернете», вы бы использовали Cobol? Надеюсь, нет, да и зачем это вообще? Откуда вы взяли, что они будут делать The Next Great вообще? Большинство специалистов в этой области знают, что не существует абсолютно лучшего или худшего языка, он всегда зависит от конкретной цели, которую необходимо достичь в конкретном сценарии, и, конечно же, существует множество контекстов, в которых наиболее подходящим является более старый язык. один. Вы действительно находите это странным?
@SantiBailors сначала говорите «надеюсь, нет», а затем «почему это имеет значение» - чтобы вы четко понимали, почему это важно. Не из-за того, что язык лучше или хуже, а из-за рыночного контекста. Использование современного языка часто имеет технические преимущества - инструменты, библиотеки и т. д. - поэтому, вероятно, это было бы полезно. Возможность нанимать людей для участия в проекте — еще полезнее.
@ user19202 Надеюсь, нет , потому что в ситуации, которую вы описали, это было бы ошибкой, и почему это имеет значение , потому что эта ситуация отличается от обсуждаемой ситуации, поэтому все, что вы делаете в этой ситуации, не имеет отношения к обсуждаемой теме.
@ ThorbjørnRavnAndersen Это самосбывающееся пророчество, как и индустрия, полная гвоздоколов, говорящих, что «на удивление многие задачи сводятся к тому, чтобы просто забивать гвозди в вещи». Да потому, что эти задачи определялись в первую очередь забивщиками гвоздей, новые задачи интерпретируются в терминах гвоздей и молотков, а задачи, которые нельзя было решить с помощью гвоздей и молотков, просто не брались.
@JounceCracklePop Не совсем так. Удивительно, но многие из тех вещей, за которые кто-то готов платить за использование компьютера, — это добавление чисел и перемещение данных. Я не призываю выбирать какой-либо конкретный язык или платформу в целом, но, как всегда, использую лучший инструмент для работы - для этого COBOL очень хорош. Просто как тот. По моему опыту, это то, что обычно означает «предприятие» - то, в чем вы не будете использовать тригонометрию ... Что бы вы посоветовали, было бы лучшим выбором?
@ ThorbjørnRavnAndersen Удивительно, но многие вещи, которые люди готовы покупать в супермаркетах, уже лежат на полке . Прежде чем говорить о том, на что похожи «корпоративные» системы, спросите: кому- нибудь нравится нынешнее состояние корпоративного программного обеспечения? Неужели люди просто хотят более быстрых лошадей? Мы делаем это неправильно. Последние 12 лет своей карьеры я с успехом бросал вызов общепринятому мнению о том, что означает «система предприятия». Лучшие инструменты поддерживают множество разновидностей абстракций, и это не похоже на COBOL.

Деньги.

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

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

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

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

редактировать:

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

+1 «он, вероятно, получил много знаний о том, как вести успешный бизнес, несмотря на эту практику», и ваши замечания о ежедневных обновлениях тоже хороши ... Отличный ответ.
На самом деле мы внедрили Scrum в нашу команду, но наши менеджеры сказали нам, чтобы мы не были слишком открытыми для него, поскольку наш босс считает это «пустой тратой времени», в течение которого мы «на самом деле могли бы немного написать код».
@ user128738 Так что я не вижу проблемы. Вы, как команда инженеров, можете внедрить модернизацию так, чтобы это не воспринималось как влияющее на его цели. Почему вы не можете продолжать в том же духе и в то же время демонстрировать ценность для него?
Я ставлю -1 этому ответу, так как не верю, что это самый эффективный ответ. Да, оформление вещей с точки зрения денег — это хороший способ представить вещи вашему боссу. Однако для изменения этой конкретной ситуации это будет далеко не так эффективно, как, скажем, уход.
@geekrunner - каким образом уход отвечает на вопрос? Это может быть лучше всего для здравомыслия ОП, но это не правильный ответ на заданный вопрос, как поступить с боссом.
Если вопрос звучал так: «Моя машина загорелась и теперь превратилась в расплавленный кусок щебня, как мне заставить ее снова работать?» - вы могли бы дать подробный ответ о том, как его собрать и заставить работать, или вы могли бы сказать: «Купи новую машину».
«Вероятно, он получил много знаний о том, как вести успешный бизнес, несмотря на эту практику». Я бы даже сказал, что это не имеет значения. Вы можете сойти с рук с плохими практиками / мелочами, когда вы только начинаете, но по мере того, как компания становится все более успешной, программное обеспечение неизменно становится более сложным, и общие лучшие практики призваны помочь справиться с этим. Думать, что вы можете работать как стартап вечно, опасно и вызовет серьезные проблемы. Я на самом деле имею дело с этим в настоящее время в некоторой степени.
@ Энди - я не говорю, что его путь лучше всего подходит для продвижения вперед. Я говорю, что он чувствует, что его проблемы не решаются командой инженеров. Он думает, что ориентируется на клиента, но, возможно, ему нужно понять, как его нынешняя деятельность должна быть улучшена, но на языке, который решает эти проблемы — его итоговая прибыль в будущем, а также демонстративный код, с которым сталкивается клиент.
Я понимаю угол уважения, но ежедневные обновления звучат для меня не как SCRUM, а скорее как микроменеджмент. Я работал со множеством людей, которые создавали небольшие компании из ничего и уважали их знания, но — и я должен быть на 100% уверен — микроменеджмент никогда не бывает хорошим признаком.

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

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

Я не согласен с @Preet Sanga, если бы владелец заботился о каких-либо показателях, он бы заботился о них в 2010 или 2005 году, не позволяя ситуации ускользнуть в первую очередь.

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

«Люди, которым не все равно, переедут куда-нибудь еще»... да, похоже, что у компании есть « Эффект Мертвого моря »
+1 за «цепочку предательских событий». Иногда раскачивание лодки заканчивается тем, что вы оказываетесь в воде. И тогда вы найдете гораздо лучшую лодку.
Комментарии лучше подходят: Был хороший разговор (ссылка потеряна) от отличного парня, который руководил консалтинговой компанией где-то в США. У него были вопросы-ловушки, такие как: «Для меня важны современные методы разработки программного обеспечения» и тому подобные, чтобы отфильтровывать людей, которые не были связаны с его бизнесом (в основном он поддерживал старое-старое программное обеспечение). HR (или HR-специалист) обязан сообщить об этом заранее и проинформировать кандидата.

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

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

Это хороший момент. Составление списка того, что требуется для выполнения работы, может быть проверкой здравомыслия для обеих сторон. Иногда я обнаруживаю, что то, что я изначально считал серьезным изменением, может быть выполнено относительно легко, а иногда то, что кажется незначительным изменением, требует полной перестройки текущего процесса.
При условии, что первый пункт в списке не «перепишите все, к чему мы прикасаемся, на правильном языке 2010-х годов вместо более низкого языка 90-х, который вы решили использовать, потому что нельзя ожидать, что мы будем работать над этой чепухой». Босс не признает, что это действительно необходимо, и начнет бормотать о современной молодежи, которая не знает, что она рождена.

Оставлять.

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

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

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

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

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

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

Он не использует гибкую модель и только «предложил» ее, потому что мы не готовились к его графику. У него действительно есть хорошие идеи. То, над чем мы работаем, довольно хорошо, поскольку оно решает некоторые возможные будущие проблемы с целостностью, однако его просто не так просто реализовать, как кажется, что он, в свою очередь, отказывается признать.
Мне всегда нравились менеджеры, которые думают, что agile означает «та же работа, но быстрее». Борьба с менеджерами в рамках реалистичных сроков — довольно распространенная проблема в этой отрасли, от которой большинство из нас не может избавиться. В вашем случае это звучит так, как будто ваш босс уже укоренился в своих привычках, и единственный способ, которым он изменится, — это когда это заметно повлияет на его прибыль. (Не деньги, потерянные из-за слишком долгой разработки, а когда какой-то конкурент проносится мимо вас и начинает сокращать свою клиентскую базу)
@RualStorge, это верная точка зрения, но его страх может быть противоположным и также верным. Поэтому вам нужно лучше общаться, чтобы понять, откуда он исходит, и использовать инструменты, которые он понимает, чтобы донести свою точку зрения.
+1: Многие менеджеры не знают о синдроме второй системы. en.m.wikipedia.org/wiki/Второй-системный_эффект

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

Теперь, если вашему начальнику нужны ежедневные цели и ежедневные результаты, поставьте ему ежедневные цели и ежедневные результаты. Уделите полчаса первым делом утром, чтобы определить, что вы хотите сделать в этот день. Это полчаса, в течение которых вы могли бы программировать, но этого хочет ваш босс. За полчаса до того, как пойти домой, прекратите писать код и определите и запишите, что вы сделали за день. Теперь важно (особенно для младшего разработчика): отслеживайте, какую часть своего плана вы выполнили каждый день. После того, как вы сделаете это в течение недели, вы узнаете, что на самом деле достижимо за день, и измените свои планы на день, чтобы они соответствовали тому, что на самом деле произойдет. Ваш план на день должен заключаться не в том, «что бы вы хотели, чтобы произошло» или «что бы хотел сделать ваш босс», а в том, «что произойдет».

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

Это не ваша работа, чтобы изменить то, как работает бизнес, это работа вашего босса.

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

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

Признайте, что даже разработчики с 20-летним опытом все еще вписываются в континуум талантов — не все из них являются «программистами-рок-звездами».

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

It isn't your job to reform how the business works, that's your bosses job. You job is to fit in and perform the role as defined by the businessЭто тип мышления, который душит инновации и нестандартные идеи, что приводит к устаревшим ситуациям, описанным OP. Если вам не нравится то, где вы находитесь, либо попытайтесь изменить его, либо, если это не удастся, уходите.

Если есть кто-то еще выше, с кем вы можете поговорить, чтобы объяснить ситуацию, то я бы посоветовал это сделать.

Старайтесь не играть в игру с обвинением, когда говорите о своем руководителе, вместо этого старайтесь смотреть на это в более позитивном свете. Что-то вроде этого может быть достаточно:

«Я обеспокоен тем, что человек X может быть не в курсе текущих методов разработки программного обеспечения, я считаю, что это может негативно повлиять на проект в будущем. Можно ли дать человеку X дополнительное обучение современным методам разработки программного обеспечения?»

Если это не вариант, то я действительно предлагаю вам начать работать в другом месте. Не стоит тратить время на работу в компании, которая вас утомляет. Вы также должны спросить себя, если компания работает так сейчас, насколько вероятно, что они будут такими же через 5-10 лет? По сути, безопасна ли ваша работа, или ее бросит конкурент?

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

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

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

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

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

Не можете сменить компанию - смените компанию.

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

Редактировать: люди проголосовали за это, утверждая, что это 3 предложения, говорящие «брось свою работу».

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

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

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

Людям здесь не нравятся простые ответы «выйти», что, по моему мнению, немного нереалистично, поскольку часто «бросить» — лучший совет в такой ситуации.
@geekrunner - Действительно, иногда уход является правильным ответом, но, учитывая постоянные финансовые и карьерные последствия этого, многие члены сообщества считают, что очень сильное объяснение, даже подкрепленное профессиональными исследованиями или цитатами, заключается в том, чтобы не просто говорить люди бросить и сдаться. Питер, ознакомьтесь с метапостом Workplace SE , чтобы узнать больше об этом обсуждении. Надеюсь это поможет.
@ jmort253 jmort253 Да, и в мета-посте четко указано, что фраза «Увольняйтесь с работы» является приемлемым ответом в некоторых ситуациях.
@geekrunner - конечно, но в этом ответе есть ощущение «я тоже».
@geekrunner Я думаю, что «Увольняйтесь с работы» может быть приемлемым ответом, но, вероятно, вызовет отрицательные голоса, если в нем всего три предложения, в которых говорится «Увольняйтесь с работы».
Но я не сказал просто «брось свою работу». Я сказал: «Если ваша компания настолько отстой, и вы не можете ничего улучшить, и вы не приобретаете рыночные навыки , лучше бросить свою работу, когда она вам подходит, чем ждать, пока вас уволят из-за некомпетентности других».

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

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

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

Итак, вам нужно сделать две вещи:

  • Точно запишите все различные части программного обеспечения, переписанные для внесения его изменений, и сколько времени, по вашему мнению, это займет. Это должно быть разбито на достаточно маленькие кусочки, чтобы он не подумал, что вы просто придумываете цифры, но не настолько маленькие, чтобы это превратилось в tl;dr. Это потребует совсем немного усилий, чтобы найти правильный баланс.
  • Затем разработайте план постепенного перемещения системы в будущее. Это нужно делать постепенно, потому что они не могут просто закрыть все на год.
    • Скорее всего, первым шагом будет разделение существующего программного обеспечения на модули, взаимодействующие друг с другом; задача не из легких! Тем не менее, это хорошо сделать в любом случае, просто чтобы упростить разработку и разделить проблемы.
    • Как только это будет сделано, вы можете начать работать над переносом каждого компонента в более новую версию.
    • Крайне важно, чтобы в этой части было достаточно деталей, чтобы он мог видеть временной горизонт! Вы не можете принести ему дым и зеркала, потому что он достаточно долго в индустрии, чтобы быть в состоянии идентифицировать их.
    • Также крайне важно, чтобы у него было достаточно подробностей, чтобы он чувствовал, что может обобщить работу, которую вы проделали, чтобы продать идею высшему руководству (он не захочет, чтобы вы написали резюме действительно высокого уровня, поэтому не сделай это).

Когда вы, наконец, будете готовы встретиться со своим боссом, вот что нужно иметь в виду:

  • Делайте это наедине. Убедитесь, что ваш начальник не думает, что вы активно пытаетесь выставить его в плохом свете. Одна из идей состоит в том, чтобы пригласить его выпить с вами за пределами работы, чтобы все выглядело менее серьезно и с меньшими ставками, чем на самом деле.
  • Делайте все возможное, чтобы он чувствовал себя вовлеченным. Подумайте о его идеях и не забудьте отдать ему должное за все, что он сделал или сказал, что вдохновило вас на какую-то часть вашей статьи. Встреча с ним в таком состоянии будет очень похожа на наступление ему на горло, поэтому вам лучше быть готовым помассировать его эго с обратной стороны. Кроме того, продемонстрируйте понимание того, что решение о реализации вашего плана будет приниматься не только им, и позвольте ему быть тем, кто представит его высшему руководству, если он согласен с вами. Не ищите здесь кредит.
  • Вы должны войти в это представление с как можно меньшим эго. Убедитесь, что ясно, что вы делаете это, потому что вы чувствуете, что это самое лучшее использование вашего времени, времени команды и, в конечном счете (как предлагается в ответе @PreetSangha) денег компании.
  • Вы также должны объяснить, насколько вы несчастны, но не в духе «горе мне», а в том, что эти проблемы оказывают конкретное влияние на моральный дух и, как следствие, на производительность. Постарайтесь быть беспристрастным здесь.
  • И, наконец, вы должны быть готовы потерять работу из-за этого. Многие боссы не хотят, чтобы их так тщательно разоблачали, и будут искать первый предлог, чтобы вышвырнуть вас за дверь. Если это ваш начальник, то все вышеперечисленное не имеет значения, и самое главное, что нужно сделать на самом деле, это уйти.
Вы предписали очень разумный план действий, но, как вы сказали, это большие усилия для неопределенной отдачи.

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

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

Лучшее, что вы можете сделать, — это смириться с этим, плыть по течению, завоевать доверие и уважение людей, которые старше вас и знают больше, чем вы, и, возможно, только возможно, найти способы внести крошечные постепенные изменения в образ жизни. дело делается в конце концов. Просто сделайте свой личный рабочий процесс более эффективным, таким образом, чтобы не мешать команде проекта в целом, но создавать у людей впечатление, что «эй, этот новенький работает быстро и эффективно». Может быть, люди посмотрят, как вы что-то делаете, и сами начнут пробовать. Это лучшее, на что вы можете надеяться, а не ворваться в офис вашего босса с головой, полной идей и отношением типа «ты все делаешь неправильно, и я собираюсь рассказать тебе здесь и сейчас, как все должно быть сделано с этого момента». on", так как это только сделает вас врагами.

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

Я не видел этой идеи в текущих ответах, но, пожалуйста, дайте мне знать, если я что-то пропустил.

Показать свою работу:

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

Часто совершайте:

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

Делайте чаще:

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

Предостережение:

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

Я могу добавить еще одну мысль: цепочка создания стоимости (см . http://en.wikipedia.org/wiki/Value_chain и оригинальную книгу Портера).

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

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

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

Это настолько распространено, что вы более или менее описываете........

сама природа индустрии программного обеспечения !!!

По сути, если вы не можете справиться с этим или работать с этим, вы не можете работать в отрасли! (Отстой, но правда.)

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

Абсолютный итог таков: просто объясните четко и как можно вежливее — и повторяйте:

«Хорошо, но это будет стоить X евро . При использовании этой более современной системы это будет стоить Y евро ».

Например, огромным нововведением на мобильной сцене в настоящее время являются «bAA» (например, Parse и т. д., а также огромные новшества, такие как google play и т. д.). Мы беремся за большие проекты и просто полностью исключаем всю серверную часть доткома и просто используем Parse или что-то в этом роде. Это буквально приводит к тому, что 3, 4, 5 серверных людей теряют работу (и переходят к лучшей, более интересной карьере!)

Вы должны помнить, что «отказ от посредников» — это продолжающаяся, месяц за месяцем история софтверного бизнеса. Оглядываясь назад на 20 лет, мы все заработали бы огромное состояние, выкуп принца, делая что-то вроде «добавления обработки кредитных карт !! в интернет-магазин !!»

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

Еще один невероятно важный момент лично для вас...

Вы должны очень тщательно спросить себя - ради финансов вашей семьи и так далее -

Вы хотите провести следующий год, работая над мертвой технологией?

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

«О, так вы провели последний год, работая над технологией 10-летней давности, которая теперь стала еще более бесполезной?»

Это не выглядит хорошо.

Подумайте о том, чтобы просто покинуть компанию . Просто очень вежливо объясните, слушайте, я люблю вас, ребята, но если я буду работать над технологией 10-летней давности в течение следующих 12-18 месяцев, я просто потеряю 1-2 года из своей карьеры, а у программистов может быть 15 лет максимальной мощности. в лучшем случае в своей карьере, так что это невозможно.

Тогда уходи и найди новую работу во второй половине дня.

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