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

Вот небольшая предыстория: мой менеджер работает в этой компании более десяти лет. Похоже, он очень малому научился за то время, что был здесь, и делает все так, как делали всегда. Он инженер/программист, поэтому работает с C++, SQL Server, .NET, JavaScript и подобными технологиями. Он также занимается разработкой внешнего интерфейса, поэтому он также занимается HTML и CSS.

Перенесемся в наши дни: я UX-аналитик, визуальный дизайнер и веб-разработчик. Я бы сказал, что мой визуальный дизайн и веб-разработка на данный момент сильнее, чем мой UX. Я давно занимаюсь веб-дизайном и разработкой. Я всегда читаю и пробую новые технологии, такие как препроцессоры CSS SASS/LESS, языки шаблонов, такие как Liquid, и инструменты для компиляции/окружения, такие как Jekyll и Vagrant. Я использую их, чтобы оптимизировать рабочий процесс, ускорить разработку и сделать мой код чистым, эффективным и простым в обслуживании.

Я рассказал об этих технологиях и инструментах своему руководителю, а он в них не разбирается. Он думает, что новые технологии похожи на Dreamweaver (думаю, у него был неудачный опыт работы с Dreamweaver, как и у ВСЕХ нас, и он считает, что инструменты, не связанные с ручным кодированием, каким-то образом загрязнят код). Он постоянно выдвигает против них аргументы, например, что они несовместимы с разными браузерами и внедряют вещи, которые раздуют код. Когда я говорю об одном, он поднимает что-то другое. Я думаю, он просто не хочет учиться? Я физически показал ему довольно надежный набор пользовательского интерфейса, который я разработал за последние несколько дней, и он не был впечатлен и серьезно подорвал работу, сказав, что, по его мнению, я использовал редактор перетаскивания, поскольку я дизайнер, а не разработчик (но я разработчик, просто не такой разработчик, как он). Когда я рассказываю ему об этих новых технологиях и о том, как они помогут нашему рабочему процессу, повысят производительность и значительно сократят время разработки, он либо отключит меня, либо придумает несколько оправданий, чтобы не использовать их. Он говорит, что я могу их использовать, но ему нужны только выведенные HTML и CSS, ему не нужны "другие вещи".

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

Босс есть босс, но странно, что они застряли на старых вещах и все еще имеют UX-специалиста.
Ну, многие инструменты добавляют смехотворное количество бесполезного лишнего кода. Пример из моей недавней работы: редактор страниц на основе браузера SharePoint имеет тенденцию случайным образом определять диапазоны и элементы div и назначать одни и те же параметры стиля элементу div, одному элементу p внутри него и двум соседним идентичным диапазонам, которые составляют весь содержание стр. Итак, я вернусь назад и уберу div и span, оставив только один тег p вокруг моего текста, что уменьшит количество байтов в среднем примерно вдвое.
«Я использую эти инструменты… чтобы упростить поддержку моего кода». - Ваш босс, вероятно, хочет, чтобы код легко поддерживали и другие члены вашей команды. Даже если это что-то простое, например, использование препроцессора LESS в процессе сборки, такого рода вещи могут складываться — если ваша команда не знакома со всеми замечательными инструментами, которые вы добавили в рабочий процесс, незнание может добавить больше затрат на обслуживание, чем затраты. пользу они приносят. Если вы хотите успешно внедрить эти изменения, вам нужно делать это постепенно — продавать каждое из них своему боссу понемногу.
Связанные, но перевернутые роли - worker.stackexchange.com/questions/33188/…
Если он говорит, что вы можете их использовать, но он не хочет, в чем проблема? Он просто хочет результат. Если вы хотите произвести на него впечатление, впечатлите его своим кодом, а не тем, как вы его создали. Если проблема в том, что ваше представление о "хорошем" коде отличается от его, то у вас есть проблема, и вам нужно решить, можете ли вы жить с его стандартами, потому что не похоже, что вы сможете их изменить.

Ответы (5)

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

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

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

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

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

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

В вашей должностной инструкции указано, какой стек технологий использует ваша компания?

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

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

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

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

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

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

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

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

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

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

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

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

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

Будьте довольны тем, что вы можете использовать инструменты, а он просто хочет HTML и CSS.

Это не он не понимает ваших навыков. Он просто не хочет узнавать что-то новое.

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

Мой менеджер отказывается принимать или изучать новые технологии
СпросиСетьПолитика конфиденциальности1y, 0v