Si vous voulez vraiment que les développeurs reviennent à leur ancien niveau de productivité, vous devez commencer à être plus sensible à leurs préoccupations. Pour le moment, vous (ou votre entreprise, peu importe, vous représentez la société à ce sujet) avez dit à un groupe de créatifs: "Nous vous enleçons vos outils préférés, aspirez-le". Au lieu d'essayer de travailler avec les développeurs, vous les rabaissez plutôt en utilisant des mots comme «désuet» et «boudeur»; même si vous n'avez pas utilisé ces mots directement, je suis à peu près sûr que votre attitude à cet égard est évidente.

En tant que gestionnaire de développeurs, vous êtes (ou devriez être) conscient qu'une décision comme celle-ci était va susciter du ressentiment chez au moins une partie de votre personnel. Expliquez-leur que vous comprenez leurs préoccupations et que vous souhaitez travailler avec eux pour minimiser la douleur que cette décision cause. Expliquez-leur les justifications commerciales de ce changement, et que vous comprenez que vous avez aggravé leur travail, mais que l'entreprise a besoin de ce changement. Travaillez avec eux plutôt que contre eux - y a-t-il un os que vous pouvez leur jeter en échange d'avoir gâché leurs environnements de développement? Décidément, arrêtez définitivement de vous disputer (comme vous le faites dans les commentaires) pour savoir si leur environnement de développement préféré est meilleur ou non.

Sinon, amenez-les à une réunion disciplinaire et donnez-leur un avertissement écrit. En même temps, vous pouvez tout aussi bien parler aux RH de votre besoin de recruter cinq nouveaux ingénieurs senior (ou peut-être plus), car personne ne voudra travailler pour une entreprise avec ce genre d'attitude désagréable envers les talents créatifs.

La ligne de commande est destinée aux experts:

• C'est plus rapide.
• Elle utilise moins de ressources système.
• Il permet d'effectuer rapidement des tâches complexes (ex: regex, scripts shell en ligne, etc.).
• C'est plus déterministe et répétable que de cliquer sur une douzaine de menus modaux de l'interface utilisateur (c'est-à-dire que je peux copier-coller un script shell d'une ligne pour effectuer une opération ésotérique, tandis que les utilisateurs de l'interface utilisateur peuvent passer plus de 30 secondes à plonger dans le menu).

En ce qui concerne les éditeurs que vous avez mentionnés, il semble que vous ayez le premier correct: vim . L'autre cependant, est probablement emacs , pas emux . Semblable à l'argument ligne de commande vs GUI que j'ai posé ci-dessus, les personnes immergées dans le monde des éditeurs en ligne de commande et modaux «désuets» ont tendance (mais ne sont pas garantis) à être beaucoup plus expérimentées que leurs homologues utilisant l'interface utilisateur Hartman, sans doute l'un des développeurs de noyau Linux les plus intelligents actuellement actifs, utilise mutt pour le courrier électronique et vim pour le développement; et les deux sont " outils d'apparence désuète). Les personnes avec lesquelles j'ai travaillé qui utilisent de telles configurations ont tendance à être des experts du noyau ou de Linux, qui écrivent leurs propres plugins pour l'achèvement du code et facilitent les tâches quotidiennes, etc. Vous avez mentionné que ce ne sont que des ingénieurs expérimentés qui sont opposés à cela : cela n'est pas une surprise.

On dirait que "les cinq" exagèrent un peu quand ils démontrent la lenteur de la frappe et de l'utilisation de la souris comme vous l'avez décrit, mais ce n'est probablement pas à 100% exagération: ils vous indiquent le problème et vous "refusez de le croire" . Vous avez un groupe d'experts, vous avez supprimé les outils d'utilisateurs avancés qu'ils utilisent pour exceller dans leur travail et leur avez donné des outils universels à la place de ce qu'ils utilisaient. Le fait que votre produit fonctionne sous Linux et que tous les développeurs doivent utiliser Windows pour le construire est déroutant: cela n'a aucun sens.

Solution 1 ( Pratique, sous-optimal)

Si vous pouvez supprimer l'exigence "vous devez coder dans Visual Studio" et les laisser utiliser des machines virtuelles, vous vous rencontrerez probablement quelque part au milieu et leur productivité se rétablira (bien que vous ayez probablement de nouveaux problèmes tels que Les machines virtuelles tombent en panne, les fichiers du disque virtuel deviennent corrompus) qui entrent maintenant dans leur routine.

Solution 2 (pratique, optimale)

Donnez-leur simplement les nouveaux ordinateurs portables et laissez-les Linux et Windows à double démarrage.

Parlant en tant qu'utilisateur expérimenté avec BEAUCOUP d'expérience avec Linux et Windows ...

1) Vous venez de prendre les outils dont vos ingénieurs vous ont dit qu'ils avaient besoin pour faire leur travail. C'est comme s'ils vous disaient qu'ils avaient besoin de tournevis et que vous insistiez sur le fait qu'ils peuvent utiliser des marteaux. Il existe de nombreuses tâches et niches où Linux est la meilleure solution.

2) C'est incroyable de voir à quelle fréquence le service informatique pense qu'il devrait contrôler les outils de R&D. C'est une mauvaise idée car les deux groupes ont des priorités très différentes.

3) Très probablement l'ensemble " devoir utiliser un éditeur de texte" rookie "" ou " en parcourant des pages de dialogues / menus avec la souris "n'est que la pointe de l'iceberg et ce qu'ils peuvent facilement vous montrer. Il y a des outils qu'ils n'ont tout simplement plus.

4) Une nouvelle saveur de fenêtres apparaît toutes les quelques années et détruit l'expérience acquise par les gens en utilisant l'ancienne . Linux, et en particulier la ligne de commande, ne fait pas cela. Ainsi, une personne expérimentée qui est habituée à la ligne de commande peut avoir des décennies d'expérience dans la réalisation de tâches, maintenant elle apprend tout à partir de zéro avec une interface graphique. Ils ne sont donc plus "expérimentés".

Solutions:

1) Laissons-les retourner sous Linux.

2) Attendez. Finalement, ils iront mieux ... mais ce n'est pas la même chose qu'ils reviennent totalement là où ils étaient en termes d'efficacité .

Quoi que vous fassiez, vous devez être prêt à ce qu’un ou plusieurs d’entre eux quittent . Ce genre de chose crée des employés mécontents. Les développeurs seniors ayant une expérience Linux sont facilement employables.

D'après ce que vous avez présenté, il n'y a pas de retour en arrière. Le développement se fera dans le nouvel environnement. En tant que manager, vous devez faire face à la réalité. Indépendamment de ce que vous pensez, «ils» étaient plus productifs dans l'ancien environnement. C'est juste un fait.

Comme il n'y a pas de retour en arrière, vous devez vous assurer qu'ils maîtrisent le nouvel environnement. Demandez-leur de travailler avec d'autres qui semblent exceller dans Windows. Établissez un niveau acceptable de performances et de conséquences pour ceux qui ne peuvent pas les atteindre dans un certain laps de temps.

J'espère qu'ils vous prendront au sérieux et s'amélioreront. Ce que vous voulez ou pouvez faire s'ils ne le font pas, c'est à vous de le déterminer en tant que gestionnaire. Après tout, c'est votre travail.

En particulier, les travailleurs de niveau supérieur ont une mémoire "musculaire" importante lorsqu'il s'agit de travailler avec leurs outils et vous avez pratiquement perdu tout cet avantage.

De plus, ils ne sont apparemment même pas familiers avec le de nouveaux outils qu'ils utilisent maintenant, ce qui vous fait perdre plus de productivité.

Cette perte significative de productivité et de climat de travail aigre est votre faute / celle de votre entreprise en imposant à vos employés un environnement de travail et un ensemble d'outils complètement nouveaux.

Vous devriez avoir instauré une période de transition (idéalement entre les projets) où ils auraient pu apprendre à se familiariser avec le nouveau logiciel et se familiariser avec la production.

Si vous n’avez pas organisé de sessions de formation pour les nouveaux outils, vous devez le faire immédiatement.

Vous pouvez approcher vos travailleurs mécontents en leur offrant une formation et en leur laissant un peu de temps jusqu'à ce qu'ils soient au courant du nouveau système. Cela prendra un certain temps, vous aurait dû prévoir cela.

Vous devez avoir des raisons très importantes pour lesquelles vous avez décidé d'utiliser ce pa logiciel spécifique, communiquez-les clairement à vos employés et montrez-leur non seulement les avantages pour l'entreprise, mais aussi toutes les études qui mettent en évidence les avantages pour vos ingénieurs.

Assurez-vous qu'ils apprennent à les utiliser en premier pour récupérer la productivité et, espérons-le, leur faire voir le bien dans le changement extrême auquel ils doivent maintenant faire face.

La meilleure chose à faire ici serait de travailler avec l'équipe de développement, les opérations, les responsables de la sécurité, etc. pour trouver un moyen de permettre aux développeurs d'utiliser les outils qu'ils souhaitent utiliser afin de résoudre les problèmes de sécurité et d'audibilité. Cela peut impliquer plus de dépenses et des compromis de la part des développeurs et certains acceptant des risques de sécurité plus importants.

En supposant que ce n'est pas possible, vous devez expliquer à l'équipe de développement pourquoi vous apportez ces changements. Préparez une présentation et un document expliquant pourquoi vous devez effectuer ces changements. Je peux comprendre pourquoi il est plus facile de sécuriser et de vérifier lors de l'utilisation d'un système d'exploitation que deux. Personnellement, j'ai du mal à imaginer pourquoi le choix des outils de développement de logiciels (à l'exception des débogueurs et des renifleurs de réseau) serait important. Expliquez-leur pourquoi les outils qu'ils souhaitent utiliser ne répondent pas à vos besoins. Expliquez pourquoi Visual Studio doit être utilisé. Soyez ouvert aux questions des gens.

Votre équipe de développement sera également plus encline à résister à ces changements si elle pense qu'il y a une chance qu'ils soient annulés. Indiquez clairement que pour les raisons que vous avez données, la décision ne sera pas annulée.

Vous devez arrêter de penser que les développeurs ne sont pas professionnels. Ils font simplement ce qu'ils pensent pouvoir faire pour annuler un changement qui, selon eux, est une erreur et rend plus difficile l'exécution de leurs tâches. Ils peuvent penser que vous êtes dogmatique et inflexible. Cela ne sert à rien en supposant que les autres ne font pas la bonne chose. C'est pourquoi l'ouverture est importante.

L'entreprise a décidé d'un équilibre particulier entre les problèmes de sécurité et la productivité des développeurs. Vous devez maintenant accepter que les deleopers seront moins productifs. Pour de nombreux développeurs, vous leur demandez d'investir beaucoup de temps et d'énergie dans l'apprentissage de nouveaux outils. Certains décideront que ce n'est pas un bon investissement et partiront. Pire encore, ils peuvent décider de ne pas apprendre les outils et de rester. Vous devez prévoir quoi faire lorsque ces deux choses se produisent.

Votre entreprise vient de passer par un changement tectonique.

Réponse courte: laissez-moi vous dire ce que ça fait pour eux: imaginez que vous soyez droitier toute votre vie, puis qu'on vous demande de dessiner la Joconde avec votre gauche.

Réponse longue:

Permettez-moi de vous donner une perspective du point de vue d'un programmeur.

Ce n'est pas une surprise que vos employés expérimentés s'opposent au changement .

Ils ont acquis de l'expérience en utilisant les outils standard utilisés dans la communauté de programmation et de développement de logiciels.

Ce sont des outils anciens et encore largement utilisés. Cela ne les rend pas désuets. Ils démontrent le fait qu'ils sont aptes au développement de logiciels, et ont donc un grand soutien pour les utilisateurs. Et les gens les adorent.

Maintenant, s'ils ne sont pas autorisés à utiliser ces outils incroyables, alors préparez-vous à une productivité réduite et peut-être à manquer des délais.

Maintenant, nous allons parler de la baisse de productivité : Vos collaborateurs seniors seront gravement handicapés en raison des restrictions d'un nouvel environnement de développement.

En tant que personne qui utilise Vim et Linux, permettez-moi de vous dire que la fatigue mentale ressentie par l'employé sera plus que ce à quoi vous êtes confronté, en raison de sa réduction de productivité.

Ils veulent être productifs et ce n'est pas seulement faire la moue. Imaginez avoir une voiture de course de Formule 1 mais seulement autorisée à rouler à 20 miles par heure.

Je suppose qu'ils ne sont pas payés à l'heure et s'ils ne respectent pas leurs délais, ils risquent d'être licenciés, peut-être pas immédiatement, mais peut-être encore à l'avenir.

Visual Studio est un environnement de développement intégré (IDE) et un excellent à cela, vous pouvez leur faire savoir que les plugins vim et emacs sont disponibles pour eux, ce qui améliorerait le moral et la productivité (pour un peu temps).

Mais voici la raison la plus importante pour laquelle vos employés peuvent être insatisfaits: cmd.

cmd signifie invite de commande et est le terminal principal de Windows, c'est horrible (la meilleure façon de le dire). Microsoft a cependant fait un excellent travail et amélioré sa cmd pour Windows10. Windows 10 dispose également d'une fonctionnalité WSL qui permet d'exécuter une distribution Linux côte à côte et permet d'installer de nombreux outils Linux importants qui ne sont pas disponibles sous Windows. Peut-être pouvez-vous utiliser Windows 10?

Je ne peux rien dire sur l'aspect gestion car je n'ai pas cette expérience. Mais je recommande gentiment qu'avant de modifier l'environnement de travail, veuillez consulter les membres de l'équipe.

La plupart des griefs proviennent d'employés juniors, mais comme les employés seniors sont en deuil, cela montre un sérieux manque de communication.

Pourquoi les employés seniors n'ont-ils pas été consultés avant un tel changement tectonique? Ce sont eux qui auraient dû aider à décider quels outils utiliser en production.

C'est le cœur du problème ...

Chaque fois que vous posez la question aux développeurs, en particulier ceux qui se trouvent dans leurs habitudes (jeunes ou vieux n'ont vraiment pas d'importance), vous allez avoir de la résistance lorsque vous «standardisez». Du point de vue de l'entreprise, les normes ont du sens, et une fois établies et que la poussière retombe, on obtient généralement un code plus propre et une meilleure productivité.

Vous avez donc plusieurs choix ici:

1. Vous pouvez continuer à laisser ce groupe traîner les pieds et résister au changement, en sapant votre autorité et en mettant en péril le développement futur de votre produit.
2. Vous pouvez être le gestionnaire et licencier l'un d'entre eux ou tous. Vous ne perdez pas ici BTW, ils vont quitter dès que leur curriculum vitae arrivera dans la rue, ce qui ne prendra pas longtemps.

Ce qui précède dit. Votre entreprise est un idiot. Ils ont fait ce changement sans consulter le plus ancien de l'équipe. Au lieu de formuler une norme autour de ce qui fonctionne et de ce qui est la norme de l'industrie pour ce que vous développez, vous avez choisi quelque chose que quelqu'un dans l'informatique pensait être le plus rentable et vous l'avez accepté. Cependant, vous avez maintenant une excellente sécurité d'entreprise standard, donc vous l'avez pour vous, maintenant si vous pouvez simplement trouver des développeurs expérimentés prêts à travailler avec cette merde, vous êtes prêt.