Bonjour à tous! Je m'appelle Lyudmila Makarova, je suis responsable du développement à l'UBRD et un tiers de mon équipe est universel.
Reconnaître: Chaque Tech Lead rêve d'une fonctionnalité croisée au sein de son équipe. Après tout, c'est tellement cool quand une personne est en mesure d'en remplacer trois, et même de le faire qualitativement, sans changer le délai. Et, surtout, cela économise des ressources!
Cela semble très tentant, mais est-ce vraiment le cas? Essayons de le comprendre.
Qui est-il, notre anticipateur des attentes?
Le terme «généraliste» désigne généralement les membres de l'équipe qui combinent plus d'un rôle, par exemple, un analyste de développement.
L'interaction de l'équipe et le résultat de son travail dépendent des qualités professionnelles et personnelles des participants.
Par les compétences dures, tout est clair, mais les compétences générales méritent une attention particulière. Ils aident à trouver une approche pour un employé et le dirigent précisément vers la tâche dans laquelle il sera le plus utile.
Il existe de nombreux articles sur toutes sortes de types de personnalité des représentants de l'industrie informatique. Sur la base de mon expérience, je diviserais les universels informatiques en quatre catégories:
1. "Universel - Tout-Puissant"
Il y en a partout. Ils montrent toujours une grande activité, veulent être sous les projecteurs, demandent constamment à leurs collègues si leur aide est nécessaire, parfois même agaçante. Ils ne sont intéressés que par des tâches importantes dont la participation laissera place à la créativité et pourra amuser la fierté.
Quels sont forts:
- capable de résoudre des problèmes complexes;
- profondément immergé dans le problème, "creuser" et obtenir le résultat;
- posséder un esprit curieux.
Mais:
- émotionnellement labile;
- mal géré;
- ont leur propre point de vue inébranlable, qui est très difficile à changer;
- difficile de faire une chose simple. Les tâches faciles nuisent à la toute-puissance de la fierté.
2. "Station wagon - je vais le découvrir et le faire"
Ces personnes ont suffisamment de manuel et un peu de temps - et elles résoudront le problème. Habituellement, ils ont une grande expérience derrière eux en tant que DevOps. Ces généralistes ne se soucient pas de la conception et préfèrent utiliser la méthode de développement uniquement sur la base de leur propre expérience. Ils peuvent facilement prendre une collation avec techlide sur l'option choisie pour la mise en œuvre de la tâche.
Quels sont forts:
- indépendant;
- résistant au stress;
- compétent dans de nombreux domaines;
- érudit - il y a toujours quelque chose à discuter avec eux.
Mais:
- violent souvent des obligations;
- ont tendance à compliquer les choses: ils résolvent la table de multiplication en s'intégrant en parties;
- la qualité du travail est faible, tout se passe 2-3 fois;
- ils repoussent sans cesse les délais, car en réalité tout se révèle moins simple.
3. "Universel - d'accord, laissez-moi, car 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 bouée de sauvetage, bouchant les trous pour les tâches courantes. Malléable, efficace, se considère en demande, mais ne l'est pas.
Employé idéal pratique. Très probablement, il a une direction qu'il aime plus, mais en raison du flou des compétences, le développement ne se produit pas. En conséquence, une personne court le risque de devenir non réclamée et de s'épuiser émotionnellement.
Quels sont forts:
- sont responsables;
- concentré sur le résultat;
- calme;
- entièrement contrôlé.
Mais:
- montrer un résultat moyen en raison d'un faible niveau de compétences;
- ne peut pas résoudre des problèmes complexes et abstraits.
4. «Universal est maître de son métier»
Une personne ayant une expérience sérieuse en développement a une pensée systémique. Pédant, exigeant de lui-même et de l'équipe. Toute tâche avec sa participation peut atteindre l'infini, si vous ne définissez pas de limites.
Il connaît bien l'architecture, choisit la méthode de mise en œuvre technique, analyse soigneusement l'influence de la solution choisie sur l'architecture actuelle. Modeste, pas ambitieux.
Quels sont forts:
- montrer un travail de haute qualité;
- capable de résoudre tout problème;
- très efficace.
Mais:
- intolérants aux opinions d'autrui;
- 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. Comme point de départ, prenons l'équipe de développement standard: PO, responsable du développement (expert technique), analystes, programmeurs, testeurs. Nous ne considérerons pas le propriétaire du produit et le responsable technique. Le premier - en raison du manque de compétences techniques. Deuxièmement, s'il y a des problèmes dans l'équipe, il devrait pouvoir tout faire.
L'option la plus courante pour combiner / fusionner / combiner des compétences est un développeur analytique. En outre, un analyste testeur et un trois-en-un sont très courants.
Par l'exemple de mon équipe, je vais vous montrer les avantages et les inconvénients de nos collègues universalistes. Il y en a un tiers dans mon équipe et je les aime beaucoup.
L'OP a reçu d'urgence la tâche d'introduire de nouveaux tarifs dans un produit existant. Mon équipe compte 4 analystes. À cette époque, l'un était en vacances, l'autre tombait 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» - l'universel du développeur-analyste, qui possédait le domaine nécessaire. Appelons-le Anatoly.
Son type de personnalité est
«chariot - je vais le découvrir
et le faire» . Bien sûr, il a longtemps essayé d'expliquer qu'il avait «un arriéré complet de ses tâches», mais par ma décision volontaire, il a été envoyé pour résoudre une tâche urgente. Et Anatoly l'a fait! Il a organisé et terminé la mise en œuvre à temps, et les clients ont été satisfaits.
À première vue, tout a fonctionné. Mais après quelques semaines, des exigences de révision ont de nouveau surgi sur ce produit. Maintenant, le cadre de cette tâche était géré par un «pur» analyste. Au stade des tests du nouveau développement, pendant longtemps, nous ne pouvions pas comprendre pourquoi nous avions des erreurs dans la fixation de nouveaux tarifs, et ce n'est qu'après avoir dénoué tout l'enchevêtrement que nous avons découvert la vérité. Nous avons passé 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'a expliqué plus tard, il était pressé. Mais l'option la plus probable est qu'il a trébuché sur des problèmes déjà pendant le développement et les a simplement contournés, sans y réfléchir nulle part.
Il y avait une autre situation. Maintenant, nous n'avons qu'un seul testeur, donc certaines tâches que les analystes doivent tester, y compris les généralistes. Par conséquent, j'ai confié une tâche au Fedor conditionnel -
«universel - d'accord, laissez-moi, car il n'y a personne d'autre» .
Fedor - «trois en un», mais le développeur a déjà été choisi pour cette tâche. Ainsi, Feda n'avait besoin de combiner qu'un analyste et un testeur.
Les exigences sont collectées, les spécifications sont transmises au développement, il est temps de tester. Fedor connaît le système en cours de développement «comme le fond de sa main» et a parfaitement étudié les exigences actuelles. Par conséquent, il n'a pas pris la peine d'écrire des scripts de test, mais a testé «comment le système devrait fonctionner», puis l'a transmis aux utilisateurs.
Le test a été terminé, la révision est allée au bal. Plus tard, il s'est avéré que le système suspend non seulement les paiements sur certains comptes de solde, mais bloque également les paiements de très rares comptes internes qui n'auraient pas dû être impliqués dans cela.
Cela est dû au fait que Fedor n'a pas vérifié comment "le système ne devrait pas fonctionner", n'a pas établi de plan de test, ni de listes de contrôle. Il a décidé de gagner du temps et s'est appuyé sur son propre instinct.
Comment travaillons-nous avec les problèmes?
De telles situations affectent l'efficacité de l'équipe, la qualité des sorties et la satisfaction client. Par conséquent, ils ne peuvent être ignorés et l'analyse des raisons.
1. Pour chaque problème qui a causé des difficultés, je vous demande de remplir un formulaire unifié: une carte d'erreurs qui vous permet d'identifier le stade auquel s'est produit le "drawdown":
2. Après avoir identifié les goulots d'étranglement, avec chaque employé qui a influencé le problème, une session de remue-méninges «Que changer?» (nous ne considérons pas les cas particuliers en rétro), à la suite de quoi des actions spécifiques (pour chaque type de personnalité) naissent avec des délais.
3. Nous avons introduit les règles d'interaction au sein de l'équipe. Par exemple, nous avons convenu d'enregistrer nécessairement toutes les informations sur l'avancement de la tâche dans le système de gestion de projet. Lorsque vous modifiez / identifiez des artefacts au cours du processus de développement, vous devez les afficher dans la base de connaissances et la version finale du mandat.
4. Le contrôle a commencé à être effectué à chaque étape (une attention particulière a été accordée aux étapes problématiques dans le 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 wagon en question dans ce rôle avec lequel il se débrouille 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 les erreurs, deviennent plus motivés, améliorent leur karma. Nous améliorons progressivement la qualité de nos sorties.
Conclusions
Les employés universels ont leurs avantages et leurs inconvénients.
Avantages:- Vous pouvez fermer la tâche d'affaissement à tout moment ou résoudre un bug urgent en peu de temps;
- une approche intégrée pour résoudre le problème: l'interprète le regarde du côté de tous les rôles;
- les généralistes peuvent presque tout faire aussi bien.
Inconvénients:- Le facteur BUS augmente;
- les compétences essentielles inhérentes au rôle sont érodées. De ce fait, la qualité du travail est réduite;
- la probabilité d'un changement de termes augmente, car il n'y a aucun contrôle à chaque étape. Il y a aussi des risques de devenir une «star»: l'employé est sûr qu'il sait mieux qu'il est un pro;
- le risque d'épuisement professionnel augmente;
- Beaucoup d'informations importantes sur le projet ne peuvent que rester «dans la tête» de l'employé.
Comme vous pouvez le voir, il y a plus de défauts. Par conséquent, je n'utilise les universaux que s'il n'y a pas suffisamment de ressources et que la tâche est suffisamment urgente. Ou une personne a des compétences que d'autres n'ont pas et la qualité est en jeu.
Si dans le travail conjoint sur une tâche la règle de répartition des rôles est observée, la qualité du travail augmente. Nous regardons les problèmes sous différents angles, nos yeux ne sont pas flous, de nouvelles pensées apparaissent toujours. De plus, chaque membre de l'équipe dispose de 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 s'engager dans son travail, d'augmenter progressivement l'étendue de ses compétences. Néanmoins, les wagons dans une équipe sont bénéfiques: 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»!