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

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

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

Командная строка для экспертов:

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

Что касается упомянутых вами редакторов, похоже, вы правильно поняли первый: vim. А вот другой, скорее всего emacs, нет emux. Подобно аргументу командной строки против графического интерфейса, который я изложил выше, люди, погруженные в мир командной строки и модальных «устаревших» редакторов, как правило (но это не гарантируется), гораздо более опытны, чем их коллеги, использующие пользовательский интерфейс (Грег Кроа- Хартман, возможно, один из самых умных разработчиков ядра Linux в настоящее время, использует muttдля электронной почты и vimдля разработки; и оба являются «устаревшими» инструментами). Люди, с которыми я работал, которые используют такие настройки, как правило, являются экспертами по ядру или Linux, пишут свои собственные плагины для завершения кода и помощи в повседневных задачах и т. д. Вы упомянули, что против этого выступают только старшие инженеры. : это не вызывает удивления.

Похоже, что «пятеро» немного преувеличивают, когда демонстрируют медленную печать и использование мыши, как вы описали, но вряд ли это преувеличение на 100%: они говорят вам о проблеме, а вы «отказываетесь верить» в нее . . У вас есть группа экспертов, вы убрали инструменты опытных пользователей, которые они используют, чтобы преуспеть в своей работе, и дали им универсальные инструменты вместо того, что они использовали. Тот факт, что ваш продукт работает на Linux, и все разработчики должны использовать Windows для его создания, вызывает недоумение: это просто не имеет смысла.

Решение 1 (практичное, неоптимальное)

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

Решение 2 (Практичное, оптимальное)

Просто дайте им новые ноутбуки и дайте им двойную загрузку Linux и Windows.

Говорю как опытный пользователь с БОЛЬШИМ опытом работы с Linux и Windows...

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

2) Удивительно, как часто ИТ-специалисты думают, что они должны контролировать инструменты НИОКР. Это плохая идея, потому что у этих двух групп очень разные приоритеты.

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

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

Решения:

1) Пусть возвращаются на линукс.

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

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

Судя по тому, что вы представили, пути назад нет. Разработка будет вестись в новой среде. Как менеджер, вы должны смотреть правде в глаза. Независимо от того, что вы думаете, «они» были более продуктивны в старой среде. Это просто факт.

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

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

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

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

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

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

Если вы не проводили обучение работе с новыми инструментами, сделайте это немедленно.

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

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

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

Ваша компания только что пережила тектонический сдвиг.

Краткий ответ: Позвольте мне рассказать вам, каково это для них: представьте, что вы всю жизнь правша, а затем вас попросили нарисовать Мону Лизу левой. Да, вот и все.

Длинный ответ:

Позвольте мне дать вам перспективу с точки зрения программиста.

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

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

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

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

Теперь подробно о падении производительности: ваши старшие сотрудники будут серьезно ограничены из-за ограничений новой среды разработки.

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

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

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

Visual Studio — это интегрированная среда разработки (IDE), и в этом она великолепна, вы можете сообщить им, что для них доступны плагины vim и emacs, которые улучшат моральный дух и производительность (на некоторое время).

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

cmd означает командную строку и является основным терминалом для Windows, это ужасно (самый лучший способ выразить это). Однако Microsoft проделала большую работу и улучшила свой cmd для Windows10. В Windows 10 также есть функция WSL, которая позволяет параллельно запускать дистрибутив Linux и позволяет устанавливать множество важных инструментов Linux, недоступных в Windows. Может быть, вы можете использовать Windows 10?

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

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

Почему перед таким тектоническим сдвигом не посоветовались со старшими сотрудниками? Именно они должны были помочь решить, какие инструменты использовать в производстве.

В этом суть вопроса...

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

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

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

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

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

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

Итак, у вас есть несколько вариантов:

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

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