Salut tout le monde! Je m'appelle Lyudmila Makarova, je suis responsable du développement à l'UBRD et un tiers de mon équipe sont des « généralistes ».
Avouez-le : tout Tech Lead rêve de transversalité au sein de son équipe. C’est tellement cool quand une personne est capable d’en remplacer trois, et même de le faire efficacement, sans retarder les délais. Et surtout, cela permet d’économiser des ressources !
Cela semble très tentant, mais est-ce vraiment le cas ? Essayons de le comprendre.
Qui est-il, notre précurseur des attentes ?
Le terme « généraliste » fait généralement référence aux membres d’une équipe qui cumulent plusieurs rôles, par exemple développeur-analyste.
L'interaction de l'équipe et le résultat de son travail dépendent des qualités professionnelles et personnelles des participants.
Tout est clair sur les hard skills, mais les soft skills méritent une attention particulière. Ils aident à trouver une approche à un employé et l'orientent vers la tâche où il sera le plus utile.
Il existe de nombreux articles sur toutes sortes de types de personnalité dans le secteur informatique. Sur la base de mon expérience, je diviserais les généralistes informatiques en quatre catégories :
1. « Universel – Tout-Puissant »
Ce sont partout. Ils sont toujours très actifs, veulent être au centre de l'attention, demandent constamment à leurs collègues s'ils ont besoin de leur aide et peuvent même parfois être ennuyeux. Ils ne s'intéressent qu'aux tâches significatives, dont la participation laissera place à la créativité et pourra amuser leur fierté.
En quoi sont-ils forts :
- sont capables de résoudre des problèmes complexes ;
- plonger profondément dans le problème, « creuser » et obtenir des résultats ;
- avoir un esprit curieux.
Mais:
- émotionnellement labile;
- mal géré;
- avoir son propre point de vue inébranlable, très difficile à changer ;
- Il est difficile de convaincre quelqu'un de faire une chose simple. Les tâches faciles blessent l’ego du tout-puissant.
2. « Universel – je vais le découvrir et le faire »
Ces personnes ont juste besoin d'un manuel et d'un peu de temps - et elles résoudront le problème. Ils ont généralement une solide expérience en DevOps. Ces généralistes ne se soucient pas du design et préfèrent utiliser une méthode de développement basée uniquement sur leur expérience. Ils peuvent facilement discuter avec le responsable technique de l’option choisie pour mettre en œuvre la tâche.
En quoi sont-ils forts :
- indépendant;
- résistant au stress;
- compétent dans de nombreux domaines;
- érudits - il y a toujours quelque chose à dire avec eux.
Mais:
- violer souvent les obligations ;
- ont tendance à tout compliquer : résoudre la table de multiplication en intégrant par parties ;
- la qualité du travail est faible, tout fonctionne 2 à 3 fois ;
- Ils décalent constamment les délais, car en réalité tout ne s'avère pas si simple.
3. « Universel – ok, laisse-moi le faire, puisqu’il n’y a personne d’autre »
L'employé connaît bien plusieurs domaines et possède une expérience pertinente. Mais il ne parvient à devenir un professionnel dans aucun d’entre eux, car il est souvent utilisé comme une bouée de sauvetage, bouchant les trous dans les tâches actuelles. Souple, efficace, se considère recherché, mais ne l'est pas.
Un employé idéal et pratique. Très probablement, il a une direction qu'il préfère, mais en raison du flou des compétences, le développement ne se produit pas. En conséquence, une personne risque de ne plus réclamer ses prestations et de s’épuiser émotionnellement.
En quoi sont-ils forts :
- responsable;
- axée sur les résultats;
- calmer;
- complètement maîtrisé.
Mais:
- afficher des résultats moyens en raison d'un faible niveau de compétences ;
- ne peut pas résoudre des problèmes complexes et abstraits.
4. « Un homme polyvalent est maître de son métier »
Une personne ayant une expérience sérieuse en tant que développeur a une pensée systémique. Pédant, exigeant envers lui-même et son équipe. Toute tâche qui l'implique peut s'étendre indéfiniment si les limites ne sont pas définies.
Il connaît bien l'architecture, sélectionne une méthode de mise en œuvre technique, analysant soigneusement l'impact de la solution choisie sur l'architecture actuelle. Modeste, pas ambitieux.
En quoi sont-ils forts :
- montrer une haute qualité de travail;
- capable de résoudre n'importe quel problème;
- très efficace.
Mais:
- intolérant envers les opinions des autres;
- maximalistes. Ils essaient de tout faire correctement, ce qui augmente le temps de développement.
Qu’avons-nous en pratique ?
Voyons comment les rôles et les compétences sont le plus souvent combinés. Prenons comme point de départ une équipe de développement standard : PO, responsable du développement (tech lead), analystes, programmeurs, testeurs. Nous ne prendrons pas en compte le propriétaire du produit et le responsable technique. La première est due au manque de compétences techniques. Le second, s’il y a des problèmes dans l’équipe, devrait pouvoir tout faire.
L’option la plus courante pour combiner/fusionner/combiner des compétences est celle du développeur-analyste. Les tests d'analyste et de « trois en un » sont également très courants.
En prenant mon équipe comme exemple, je vais vous montrer les avantages et les inconvénients de mes collègues généralistes. Il y en a un tiers dans mon équipe et je les aime beaucoup.
PO a reçu la tâche urgente d'introduire de nouveaux tarifs sur un produit existant. Mon équipe compte 4 analystes. À cette époque, l'un était en vacances, l'autre était malade et les autres étaient engagés dans la mise en œuvre de tâches stratégiques. Si je les retirais, cela perturberait inévitablement les délais de mise en œuvre. Il n'y avait qu'une seule issue : utiliser « l'arme secrète » : un développeur-analyste polyvalent maîtrisant le domaine requis. Appelons-le Anatoly.
Son type de personnalité est "universel – je vais le découvrir et le faire". Bien sûr, il a longtemps essayé d'expliquer qu'il « avait un retard important dans ses tâches », mais par ma décision volontaire, il a été envoyé pour résoudre un problème urgent. Et Anatoly l'a fait ! Il a réalisé la mise en scène et terminé la mise en œuvre dans les délais, et les clients ont été satisfaits.
À première vue, tout s'est bien passé. Mais après quelques semaines, des besoins d'amélioration se sont à nouveau manifestés pour ce produit. Or, la formulation de ce problème a été réalisée par un analyste « pur ». Au stade de tester le nouveau développement, nous n'avons pas pu comprendre pendant longtemps pourquoi nous avions des erreurs dans la liaison des nouveaux tarifs, et ce n'est qu'alors, après avoir démêlé tout l'enchevêtrement, que nous sommes allés au fond de la vérité. Nous avons perdu beaucoup de temps et manqué les délais.
Le problème était que de nombreux moments et pièges cachés ne restaient que dans la tête de notre break et n'étaient pas transférés sur papier. Comme Anatoly l'expliqua plus tard, il était trop pressé. Mais l'option la plus probable est qu'il a déjà rencontré des problèmes pendant le développement et les a simplement contournés sans que cela ne se reflète nulle part.
Il y avait une autre situation. Nous n’avons désormais qu’un seul testeur, donc certaines tâches doivent être testées par des analystes, y compris des généralistes. Par conséquent, j'ai confié une tâche au Fedor conditionnel - "universel – ok, laisse-moi le faire, puisqu'il n'y a personne d'autre".
Fedor est un « trois en un », mais un développeur a déjà été désigné pour cette tâche. Cela signifie que Fedya n'a dû combiner qu'un analyste et un testeur.
Les exigences ont été collectées, la spécification a été soumise au développement, il est temps de tester. Fedor sait que le système est modifié « comme sa poche » et a minutieusement élaboré les exigences actuelles. Par conséquent, il ne s'est pas soucié d'écrire des scripts de test, mais a effectué des tests sur « le fonctionnement du système », puis les a transmis aux utilisateurs.
Le test est terminé, la révision est passée en production. Il s'est avéré plus tard que le système a non seulement suspendu les paiements sur certains comptes de solde, mais a également bloqué les paiements de très rares comptes internes qui n'étaient pas censés y participer.
Cela est dû au fait que Fedor n'a pas vérifié comment "le système ne devrait pas fonctionner", n'a pas élaboré de plan de test ni de listes de contrôle. Il a décidé de gagner du temps et de se fier à son propre instinct.
Comment gérons-nous les problèmes ?
Des situations comme celles-ci ont un impact sur les performances de l’équipe, la qualité des versions et la satisfaction des clients. Par conséquent, ils ne peuvent être laissés sans attention et sans analyse des raisons.
1. Pour chaque tâche ayant posé des difficultés, je vous demande de remplir un formulaire unifié : une carte d'erreurs, qui permet d'identifier l'étape à laquelle le « retrait » s'est produit :
2. Après avoir identifié les goulots d'étranglement, une séance de brainstorming est organisée avec chaque collaborateur qui a influencé le problème : « Que changer ? (nous ne considérons pas de cas particuliers a posteriori), à la suite desquels naissent des actions spécifiques (spécifiques à chaque type de personnalité) avec des délais.
3. Nous avons introduit des règles d'interaction au sein de l'équipe. Par exemple, nous avons convenu d'enregistrer obligatoirement toutes les informations sur l'avancement d'une tâche dans le système de gestion de projet. Lorsque des artefacts sont modifiés/identifiés au cours du processus de développement, cela doit être reflété dans la base de connaissances et dans la version finale des spécifications techniques.
4. Le contrôle a commencé à être effectué à chaque étape (une attention particulière est accordée aux étapes problématiques du passé) et automatiquement en fonction des résultats de la tâche suivante.
5. Si le résultat de la tâche suivante n'a pas changé, alors je ne remets pas le généraliste en question dans le rôle dans lequel il s'en sort mal. J'essaie d'évaluer sa capacité et son désir de développer des compétences dans ce rôle. Si je ne trouve pas de réponse, je le laisse dans le rôle qui lui est le plus proche.
Quel est le résultat?
Le processus de développement est devenu plus transparent. Le facteur BUS a diminué. Les membres de l'équipe, travaillant sur leurs erreurs, deviennent plus motivés et améliorent leur karma. Nous améliorons progressivement la qualité de nos sorties.
résultats
Les salariés généralistes ont leurs avantages et leurs inconvénients.
avantages:
- vous pouvez fermer une tâche en retard à tout moment ou résoudre un bug urgent en peu de temps ;
- une approche intégrée pour résoudre un problème : l'interprète l'examine du point de vue de tous les rôles ;
- les généralistes peuvent presque tout faire aussi bien.
Inconvénients:
- Le facteur BUS augmente ;
- les compétences de base inhérentes au rôle sont érodées. De ce fait, la qualité du travail diminue ;
- la probabilité d'un décalage des délais augmente, car il n'y a aucun contrôle à chaque étape. Il y a aussi des risques à devenir une « star » : le salarié a confiance qu'il sait mieux qu'il est un pro ;
- le risque d’épuisement professionnel augmente ;
- de nombreuses informations importantes sur le projet ne peuvent rester que « dans la tête » de l'employé.
Comme vous pouvez le constater, il y a encore plus de défauts. Par conséquent, je fais appel à des généralistes uniquement s'il n'y a pas assez de ressources et que la tâche est assez urgente. Ou bien une personne possède des compétences qui font défaut aux autres, mais la qualité est en jeu.
Si la règle de répartition des rôles est respectée dans le travail en commun sur une tâche, alors la qualité du travail augmente. Nous regardons les problèmes sous différents angles, notre vision n’est pas floue, de nouvelles pensées apparaissent toujours. Dans le même temps, chaque membre de l'équipe a toutes les opportunités d'évolution professionnelle et d'expansion de ses compétences.
Je crois que le plus important est de se sentir impliqué dans le processus, de faire son travail, en augmentant progressivement l'étendue de ses compétences. Cependant, les généralistes dans une équipe apportent des avantages : l’essentiel est de s’assurer qu’ils combinent efficacement différents rôles.
Je souhaite à tous une équipe auto-organisée de « maîtres universels de leur métier » !
Source: habr.com