Traiter avec des programmeurs inflexibles

Parfois, les programmeurs qui travaillent sur un projet pendant longtemps deviennent inflexibles et il devient difficile de les raisonner. Même si nous parvenons à les convaincre, il est peu probable qu'ils mettent en œuvre nos suggestions.

Par exemple, j'ai récemment rejoint un projet où le processus de génération et de publication est trop compliqué et comporte des obstacles inutiles.

J'ai suggéré que nous nous débarrassions de certains des frais généraux de développement (comme remplir quelques feuilles de calcul) simplement en intégrant des outils de gestion des défauts et de contrôle de version (les deux sont des outils IBM-Rational, donc l'intégration peut être un effort ponctuel très facile). De plus, si nous utilisons des outils comme Maven & Ant (le projet implique Java et certains produits COTS), la construction et la publication peuvent être simplifiées, ce qui devrait réduire les erreurs manuelles et l'intervention.

J'ai réussi à convaincre les autres et je suis prêt à faire l'effort de développer une preuve de concept. Mais le développeur «senior» n'est pas disposé, peut-être parce que le processus actuel le rend plus précieux.

Comment gérer cette situation sans développer de friction dans l'équipe?

Vous êtes le nouveau membre de l'équipe et vous souhaitez modifier certains aspects fondamentaux du fonctionnement de l'équipe. Bonne chance, je sens une équipe heureuse dans votre avenir.

Ok, quelques conseils pratiques:

Prouvez-vous à l'équipe. Vous devrez le faire d'un point de vue technique et de fiabilité. Si vous voulez que les gens vous suivent, vous devez leur donner une raison de le faire.

Comprendre l'historique de la méthodologie. Pourquoi existe-t-il? Quel problème résolvait-il à l'époque? Assurez-vous que votre solution est vraiment un avantage pour l'équipe. Peut-être que vos changements sont meilleurs, mais ils ne résoudront peut-être pas réellement un problème rencontré par l'équipe.

Apprenez à connaître vos barrages routiers. Découvrez les raisons de leur résistance et travaillez sur ces éléments.

Si vous voulez être un agent de changement, apprenez comment être un agent de changement réussi . Des dizaines de livres et d'autres sources disponibles pour vous fournir bien plus d'informations que vous n'en obtiendrez ici.

Et, oui, je vous souhaite bonne chance. Mais s'il vous plaît, pour votre bonheur et le bonheur de votre équipe, soyez intelligent à ce sujet. Votre désir de faire évoluer un processus, sans investir l'énergie pour tracer la bonne voie, pourrait faire bien plus de mal que de bien.

J'ai été dans la position que vous avez mentionnée. J'ai passé des années en tant que développeur Java et j'ai finalement trouvé un emploi où ils utilisaient tous Smalltalk. Ma première réaction a été "OMG, ils utilisent cette technologie désuète" et j'ai commencé à essayer de résoudre des problèmes spécifiques à Smalltalk avec des solutions Java. Je peux seulement imaginer quel mal de tête j'ai dû être pour les autres développeurs et ils détestaient Java avec passion.

Ce n'est que lorsque j'ai reçu un projet de taille moyenne sur lequel travailler, alors que deux développeurs principaux m'ont encadré au cours de quelques mois, que j'ai commencé à me familiariser avec le langage Smalltalk et à apprendre à l'aimer. Depuis que j'ai quitté ce travail et que j'ai recommencé à faire du développement Java, je me sens beaucoup plus flexible dans la mesure où je peux prendre un projet et le mettre en œuvre quel que soit le langage utilisé par l'entreprise. L'essentiel pour faire comprendre à ces gens est que la langue n'est rien d'autre que le médium. J'ai aussi pris le temps de m'apprendre Lisp et Erlang, mais cela pourrait ne pas fonctionner avec tout le monde.

En tant que stratégie de consolidation d'équipe, je recommanderais Seven Languages ​​in Seven Weeks aux personnes avec lesquelles vous rencontrez des problèmes.

Je suppose que cela dépend aussi du temps que ces personnes sont prêtes à investir pour devenir plus flexibles. Le problème avec la plupart des universités (du moins celles que j'ai vues) est qu'elles sont biaisées vers une langue spécifique et ses étudiants sont «institutionnalisés» comme vous l'avez mentionné. Je pense qu'une partie de votre stratégie devrait être de cultiver la flexibilité dans votre équipe. Cela pourrait être complété par un développement piloté par domaine .

(1) Modélisez un domaine (un simple) (2) Implémentez-le en utilisant deux langages différents (c'est-à-dire Java et Lisp)

Encore une fois, cela repose sur l'hypothèse qu'ils sont motivés à faire ce qui précède et sont prêts à investir leur propre temps pour y parvenir.

J'espère que cela t'aides

Je suis peut-être sur une voie totalement erronée ici, mais il me semble que les mêmes problèmes sont communs à plus grande échelle et se rapportent au conservatisme humain. Les gens refusent souvent de modifier les schémas de comportement bien connus, pour des raisons trop nombreuses pour être mentionnées.

En tant que développeur russe (et donc voyant moins un pragmatisme occidental rationnel), je considère que le raisonnement pratique est beaucoup moins convaincant que d'essayer de marcher dans la peau de quelqu'un d'autre.

En d'autres termes, vous avez mentionné que le programmeur senior apprécie sa propre position par rapport au schéma de travail actuel. Vous devriez peut-être le convaincre que la nouvelle façon de faire rendra sa position encore plus précieuse, et il existe de nombreuses façons de le faire. Par exemple, vous pouvez lui faire prononcer votre idée et en obtenir le crédit, ou vous pouvez trouver un endroit spécifique dans le processus qu'il peut contrôler exclusivement, etc.

Je crois qu'être flexible en dehors des avantages apparents de votre idée, pourrait être votre sort magique ici.

J'ai réussi à convaincre les autres et je suis prêt à faire l'effort de développer une preuve de concept. Mais le développeur «senior» n'est pas disposé, peut-être parce que le processus actuel le rend plus précieux.

Plutôt que de jeter des vexations sur le personnage du développeur senior (mauvais coup), vous devriez peut-être essayer de comprendre pourquoi il est peu enthousiaste:

• Peut-être pense-t-il que vous faites partie de ces gens qui vendent leurs idées. Il doute peut-être que vous puissiez les respecter.

• Peut-être qu'il pense que vous exagérez les problèmes. (Ils ne peuvent pas être si mauvais ...)

• Il pense peut-être que vous ne comprenez pas complètement les risques techniques.

• Peut-être qu'il pense (sait) qu'il y a des choses plus importantes à faire en ce moment.

• Peut-être que vous le frottez juste dans le mauvais sens.

Mon conseil serait de vous prouver à lui. Comme en réalisant les projets qui vous ont été réellement donnés. Quand il fait davantage confiance à votre capacité et à votre jugement, revenez sur cette question.

Si vous souhaitez poursuivre la ligne "amélioration des processus" dès maintenant, mon conseil serait de le faire lentement, par petites étapes.

Gardez à l'esprit qu'il existe sans aucun doute un risque que vos modifications proposées aient un impact massif sur la productivité de votre groupe, et même sur leur capacité à maintenir les logiciels existants. Si cela se produit, le responsable est susceptible de tirer le meilleur parti de la direction.

Institutionnalisé sur quoi en particulier? Technologies, modèles, pratiques?

S'ils font partie de l'organisation / du projet depuis longtemps, il y a de fortes chances qu'ils soient des développeurs seniors et qu'ils aient la responsabilité / l'expérience de faire ces appels, et qu'ils aient eu des expériences dans le projet plutôt que d'être simplement conditionnés comme l' expérience des 5 singes .

La solution pour les convaincre dépendra du sujet, car si un modèle / une technologie est déjà choisi, il y aura une bonne raison, et il devra y avoir une meilleure raison de changer pour justifier le rejet du travail et la refamiliarisation, etc. Si oui, une solution consiste pour un architecte / développeur senior à organiser une réunion pour décider démocratiquement de la meilleure solution.

Si l'équipe a vraiment des barrages routiers inutiles, elle sera probablement très heureuse de vous aider à les réparer. Notez cependant qu'il peut y avoir de très bonnes raisons pour qu'ils soient là, et vous aurez l'air stupide si vous devez dire "oh, eh bien, mon idée fantastique ne fonctionne pas alors" après l'avoir survendu à tout le monde pendant longtemps.

Enquêter d'abord, puis s'avancer. Notez également que le fait de pouvoir montrer comment vous suggérez l'amélioration est bien meilleur que l'ondulation à la main.

Je suis enclin à dire que c'est vous qui êtes le "programmeur inflexible". Vous êtes nouveau dans le projet, mais vous insistez sur le fait que votre idée est la meilleure et que le gars qui dirige le projet, qui a été leur plus longtemps et qui connaît le système à l'intérieur comme à l'extérieur, est juste à côté de son rocker.

Je suis assez expérimenté et assez bien considéré et je suis souvent affecté à réparer des projets en difficulté en tant que membre de l'équipe de tigre. Même dans ce cas, je prends toujours le temps d'apprendre le comment, le pourquoi, la dynamique de l'équipe, le projet et leurs pratiques et de ne pas entrer sauvagement et de leur dire en quoi ceci ou cela ne va pas. En fait, je ne dis jamais que ce qu'ils font est mal parce que cela n'obtient pas la réponse que je veux et généralement ce qu'ils font n'est pas faux, il a juste besoin d'être peaufiné.

Chaque projet est unique. Chaque équipe est unique. Votre solution peut être meilleure pour vous et les développeurs, mais elle peut ne pas être meilleure pour le responsable, le client, l'entreprise ou le projet, mais comme vous n'avez pas l'expérience du projet pour mieux connaître, vous ne le sauriez pas la réponse à cela.

La meilleure façon d'amener les gens à faire ce que vous voulez est de leur faire croire que tout est leur idée. Donc, au lieu de faire directement des suggestions, présentez les options. Si vos idées sont clairement meilleures que les alternatives, donnez au développeur senior une chance de les choisir et de les faire siennes. Ne vous inquiétez pas d'obtenir du crédit. Les gens qui comptent sauront ce qui se passe.