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

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

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

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

Для меня это большой красный флаг, потому что 1) Это не теория, это реальность. Вы не тот, кто будет нести ответственность, когда что-то пойдет не так. 2) Это демонстрирует плохое отношение с вашей стороны.

Ради аргумента я собираюсь принять все, что вы говорите, за абсолютную правду:

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

Учитывая все это, высококвалифицированный программист будет не активом, а пассивом.

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

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

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

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

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

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

РЕДАКТИРОВАТЬ: Ваш комментарий утешает меня в анализе того, что вы недостаточно сосредотачиваетесь на понимании, прежде чем пытаться что-то улучшить.

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

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

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

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

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

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

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

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

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

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

Нет, под «опасными» я подразумеваю вещи, которые либо непосредственно вызывают, либо могут привести к уязвимостям в нашей системе программного обеспечения. Я в Великобритании. - комментарий от Ашилта

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

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

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

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

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

Не позволяйте лучшему стать врагом хорошего.

Это не должно быть вопросом силы.

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

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

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

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

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

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

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

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

Я испытал то, что может быть похожей ситуацией в прошлом:

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

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

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

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

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

Есть интересная книга, которую вы можете прочитать, под названием « Лидер на 360 градусов » Джона К. Максвелла, в которой даны советы о том, как повлиять на людей, которые вам не подчиняются. Я бы порекомендовал прочитать ее: я пользовался ею во время службы в армии и на всех работах, которые у меня были с тех пор.

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