Le « polyvalent » dans l'équipe de développement : un atout ou un inconvénient ?

Bonjour à tous ! Je m'appelle Lioudmila Makarova, je suis responsable du développement chez UBRiR et un tiers de mon équipe est composé de polyvalents.

Reconnaissons-le : chaque Tech Lead rêve de la transversalité au sein de son équipe. C'est tellement génial qu'une seule personne puisse remplacer trois autres, tout en le faisant de manière qualitative et sans repousser les délais. Et, ce qui est important, cela permet d'économiser des ressources !
Cela semble très séduisant, mais est-ce vraiment le cas ? Essayons d'y voir plus clair.

Qui est notre précurseur des attentes ?

Le terme « polyvalent » désigne généralement des membres de l'équipe qui combinent plus d'un rôle, par exemple, développeur-analyste.

L'interaction de l'équipe et les résultats de son travail dépendent des compétences professionnelles et des qualités personnelles des participants.

Les hard skills sont claires, mais les soft skills méritent une attention particulière. Elles aident à trouver la bonne approche pour chaque employé et à l'orienter vers la tâche où il sera le plus utile.

Il existe de nombreux articles sur les différents types de personnalités dans l'industrie informatique. En me basant sur mon expérience, je classerais les polyvalents de l'IT en quatre catégories :

1. « Polyvalent – tout-puissant »

Il y en a partout. Ils montrent toujours une grande activité, veulent être au centre de l'attention, demandent constamment à leurs collègues s'ils ont besoin de leur aide, et peuvent parfois même être irritants. Ils s'intéressent uniquement aux tâches significatives qui leur permettront d'exprimer leur créativité et de flatter leur égo.

Dans quels domaines sont-ils forts :

• capables de résoudre des problèmes complexes ;
• plongent profondément dans le problème, « creusent » et obtiennent des résultats ;
• ont un esprit curieux.

Mais :

• émotionnellement instables ;
• difficilement gérables ;
• possèdent une opinion inébranlable, très difficile à changer ;
• difficile de les amener à accomplir des tâches simples. Les tâches légères touchent l'égo des tout-puissants.

2. « Polyvalent – je vais m'en occuper »

Ces personnes ont juste besoin d'un manuel et d'un peu de temps – et elles régleront la question. Elles ont généralement une grande expérience en tant que DevOps. Ces polyvalents ne se compliquent pas la vie avec la conception et préfèrent utiliser une méthode de développement uniquement sur la base de leur propre expérience. Ils peuvent facilement se disputer avec le Tech Lead sur la méthode choisie pour réaliser la tâche.

Dans quels domaines sont-ils forts :

• autonomes ;
• résistants au stress ;
• compétents dans de nombreux domaines ;
• érudits – il y a toujours quelque chose à discuter avec eux.

Mais :

• enfreignent souvent leurs obligations ;
• ont tendance à compliquer les choses : ils résolvent la table de multiplication par intégration par parties ;
• la qualité du travail est faible, il faut toujours 2-3 essais pour obtenir le résultat.
• décalent constamment les délais, car en réalité, tout s'avère plus compliqué que prévu.

3. « Universel – très bien, je le fais, puisque personne d'autre ne le fera »

L'employé s'y connaît plutôt bien dans plusieurs domaines et a de l'expérience dans ces domaines. Mais il ne parvient pas à devenir un professionnel dans l'un d'eux, car il est souvent utilisé comme une bouée de sauvetage, comblant les lacunes des tâches en cours. Souple, appliqué, il se croit demandé, alors qu'il ne l'est pas vraiment.

Employé presque idéal. Il a probablement une préférence, mais en raison de l'étalement de ses compétences, il ne progresse pas. Par conséquent, il risque de devenir non sollicité et émotionnellement épuisé.

Dans quels domaines sont-ils forts :

• responsables ;
• axés sur les résultats ;
• calmes ;
• totalement contrôlables.

Mais :

• produisent un résultat moyen en raison d'un faible niveau de compétence ;
• ne peuvent pas résoudre des tâches complexes et abstraites.

4. « Universel – maître de son métier »

Personne ayant un solide bagage de développeur, possédant une pensée systémique. Il est minutieux, exigeant envers lui-même et envers l'équipe. Toute tâche à laquelle il participe peut s'étendre à l'infini si les limites ne sont pas définies.

Bien familiarisé avec l'architecture, il choisit la méthode de mise en œuvre technique, en analysant soigneusement l'impact de la solution choisie sur l'architecture actuelle. Modeste, il n'est pas ambitieux.

Dans quels domaines sont-ils forts :

• produisent un travail de haute qualité ;
• capables de résoudre n'importe quelle tâche ;
• très travailleurs.

Mais :

• intolérants envers l'avis des autres ;
• maximalistes. Ils cherchent à tout faire correctement, ce qui rallonge les délais de développement.

Que constatons-nous en pratique ?

Voyons comment les rôles et les compétences se regroupent le plus souvent. Prenons comme point de départ une équipe de développement standard : PO, chef de développement (tech lead), analystes, programmeurs, testeurs. Nous ne considérerons pas le propriétaire du produit et le tech lead. Le premier, en raison de l'absence de compétences techniques. Le second, s'il y a des problèmes dans l'équipe, doit justement être capable de tout faire.

La combinaison la plus courante des compétences est le développeur-analyste. On trouve également souvent l'analyste-testeur et le « trois en un ».

À titre d'exemple avec ma propre équipe, je vais montrer les avantages et inconvénients des collègues polyvalents. Un tiers de mon équipe en fait partie, et je les apprécie énormément.

Le PO a donné une tâche urgente pour l'implémentation de nouveaux tarifs dans un produit existant. Dans mon équipe, il y a 4 analystes. À ce moment-là, l'un était en congé, un autre était malade, et les autres étaient occupés à réaliser des tâches stratégiques. Si je les avais sollicités, cela aurait inévitablement retardé la mise en œuvre. Il ne restait qu'une seule solution: utiliser une « arme secrète » – un développeur-analyste polyvalent qui maîtrisait le domaine concerné. Appelons-le Anatoli.

Son type de personnalité est « polyvalent – je m'en charge et je le fais ». Bien sûr, il a longtemps essayé d'expliquer qu'il avait « un back log complet de ses tâches », mais ma décision ferme a été de l'envoyer résoudre la tâche urgente. Et Anatoli a réussi ! Il a formulé la tâche et a effectué la mise en œuvre à temps, et les clients étaient satisfaits.

À première vue, tout s'est bien passé. Mais quelques semaines plus tard, de nouvelles exigences de modification sont apparues pour ce produit. C'était maintenant un « pur » analyste qui s'occupait de cette tâche. Au stade de test du nouveau développement, nous n'avons pas pu comprendre pourquoi nous rencontrions des erreurs avec l'affectation des nouveaux tarifs et ce n'est qu'après avoir démêlé tout le fouillis que nous avons découvert la vérité. Nous avons perdu beaucoup de temps et avons raté les délais.

Le problème était que beaucoup de moments cachés et d'écueils restaient uniquement dans l'esprit de notre polyvalent et n'avaient pas été mis sur papier. Comme Anatoli l'a expliqué plus tard, il était trop pressé. Mais il est plus probable qu'il ait rencontré des problèmes lors du développement et les ait simplement contournés, sans le réfléchir.

Il y avait une autre situation. Actuellement, nous n'avons qu'un testeur, donc certaines tâches doivent être testées par des analystes, y compris les polyvalents. J'ai donc confié une tâche à un certain Fiodor – « polyvalent – bon, je vais le faire, puisque personne d'autre ne peut ».
Fiodor est un « trois en un », mais un développeur a déjà été attribué à cette tâche. Cela signifie que Fiodor devait combiner uniquement les rôles d'analyste et de testeur.

Les exigences ont été rassemblées, la spécification a été transmise au développement, il est temps de tester. Fiodor connaît le système en cours d'amélioration « comme sa poche » et a étudié les exigences actuelles en détail. Il n'a donc pas voulu se donner la peine d'écrire des scénarios de test et a effectué des tests sur « la façon dont le système doit fonctionner », puis a transmis aux utilisateurs.
Le test est terminé, les améliorations sont passées en production. Il a été constaté plus tard que le système ne suspend pas seulement les paiements sur certains comptes de solde, mais bloque également les paiements à partir de très rares comptes internes qui ne devaient pas être impliqués dans cela.

Cela s'est produit parce que Fiodor n'a pas vérifié « comment le système ne doit pas fonctionner », n'a pas établi de plan de test ni de check-lists. Il a essayé de gagner du temps et s'est fié à son instinct.

Comment traitons-nous les problèmes ?

De telles situations affectent l'efficacité du travail de l'équipe, la qualité des versions publiées et la satisfaction des clients. Par conséquent, elles ne doivent pas être ignorées et nécessitent une analyse des causes.

1. Pour chaque tâche ayant posé des difficultés, je demande de remplir un formulaire unifié : la carte des erreurs, qui permet d'identifier l'étape à laquelle il y a eu « un fléchissement » :

2. Après avoir identifié les goulets d'étranglement, des séances de brainstorming « Que changer ? » sont menées avec chaque membre du personnel ayant eu un impact sur le problème (nous ne considérons pas les cas particuliers lors des rétro), à l'issue desquelles des actions concrètes naissent (chaque type de personnalité a ses propres actions) avec des délais.

3. Nous avons établi des règles d'interaction au sein de l'équipe. Par exemple, nous avons convenu de consigner obligatoirement toutes les informations concernant l'avancement de la tâche dans le système de gestion de projets. Lorsqu'il y a un changement ou une découverte d'artefacts dans le processus de développement, cela doit être reflété dans la base de connaissances et dans la version finale du cahier des charges.

4. Le contrôle est désormais effectué à chaque étape (une attention particulière est portée sur les étapes problématiques dans le passé) et automatiquement sur la base des résultats de la tâche suivante.

5. Si le résultat de la tâche suivante n'a pas changé, je ne confie pas au généraliste considéré le rôle dans lequel il éprouve des difficultés. J'essaie d'évaluer sa capacité et son envie de développer des compétences dans ce rôle. Si je ne trouve pas d'écho, je le laisse dans le rôle qui lui correspond le mieux.

Quel a été le résultat final ?

Le processus de développement est devenu plus transparent. Le facteur BUS a diminué. Les membres de l'équipe, en travaillant sur les erreurs, deviennent plus motivés et améliorent leur karma. Nous augmentons progressivement la qualité de nos versions.

Conclusions

Les employés polyvalents ont leurs avantages et leurs inconvénients.

Avantages :

• il est possible de fermer une tâche en retard à tout moment ou de résoudre un bogue urgent rapidement ;
• une approche globale pour résoudre le problème : l'exécutant l'examine sous tous les angles des rôles ;
• les polyvalents peuvent pratiquement tout faire avec un bon niveau.

Inconvénients :

• le facteur BUS augmente ;
• les compétences clés propres à chaque rôle se diluent. Cela entraîne une diminution de la qualité du travail ;
• la probabilité de retard augmente, car il n'y a pas de contrôle à chaque étape. Il existe aussi des risques de développer une « étoile » : l'employé est convaincu qu'il sait mieux, qu'il est un pro ;
• le risque d'épuisement professionnel augmente ;
• beaucoup d'informations importantes sur le projet peuvent rester uniquement « dans la tête » de l'employé.

Comme vous pouvez le voir, il y a plus d'inconvénients. C'est pourquoi je n'utilise des polyvalents que lorsque les ressources manquent et que la tâche est suffisamment urgente. Ou si la personne possède des compétences qui font défaut aux autres, et que la qualité est en jeu.

Si la règle de répartition des rôles est respectée lors du travail collaboratif sur une tâche, la qualité du travail augmente. Nous regardons les problèmes sous différents angles, la perspective ne se réduit pas, des idées nouvelles apparaissent toujours. De plus, chaque membre de l'équipe a toutes les possibilités de croissance professionnelle et d'élargissement de ses compétences.

Je pense que le plus important est de ressentir son implication dans le processus, de s'occuper de son travail en élargissant progressivement la portée de ses compétences. Néanmoins, les polyvalents dans l'équipe apportent des avantages : l'essentiel est de faire en sorte qu'ils combinent efficacement différents rôles.

Je souhaite à toutes les équipes autogérées d'avoir des 'polyvalents-maîtres de leur domaine' !

Source : habr.com