Seul sur le terrain n'est pas un guerrier. La voie vers un travail d'équipe efficace

Une équipe est un groupe de personnes qui évoluent ensemble vers un objectif commun, répartissent les tâches et la responsabilité d'un résultat spécifique entre elles. Les équipes sont créées pour résoudre des tâches qu'une personne ne peut pas accomplir. Une équipe efficace atteint l'objectif dans les plus brefs délais avec un coût minimal.

Rassemblez quelques personnes et dites: «Maintenant que vous êtes une équipe, nous attendons le résultat de votre part», cela ne fonctionnera pas. Les gens doivent s'organiser, leur donner un objectif sain, la motivation et résoudre les problèmes.



À propos de ce décodage du rapport d'Evgeny Fedoreev sur TeamLead Conf . Dans le rapport, Eugene a décrit par étapes le processus d'organisation d'une équipe de développement efficace chez Banki.ru: embauche, communication, partage des connaissances et développement de développeurs et de testeurs au sein de l'équipe et du département.


À propos du conférencier : Evgeny Fedoreev ( hardj ) est engagé dans le développement Web depuis 15 ans, dont 6 en tant que chef d'équipe, et maintenant il dirige le développement de nouveaux projets chez Banki.ru.

Qu'est-ce que Banki.ru?

Le contexte de l'entreprise est de savoir quelle expérience sera discutée. Banki.ru est le plus grand portail financier indépendant du Runet avec une audience mensuelle de plus de 8 millions d'utilisateurs uniques.

Le service informatique emploie 50 à 70 personnes, réparties en 7 équipes de développement. Tout le développement est effectué en interne, il n'y a pas de développeurs distants, il n'y a donc pas besoin de processus et de métriques appropriés.

La tâche principale de l'équipe de développement

Lors de la préparation du rapport, j'ai posé une question aux gens:

- Quel est le but de l'équipe de développement?
- Développer.
- Qu'est-ce que ça veut dire? Si une personne s'assoit, refacture, n'apporte pas d'avantages, ne résout pas les problèmes commerciaux - est-ce aussi une évolution?
- ... Elle doit être développée efficacement.

Efficacité de développement

Le concept d'efficacité est une chose pour un manager et une autre pour un développeur.

Pour le gestionnaire, un développement efficace est prévisible : lorsque la date de sortie de la fonctionnalité ou la date limite pour terminer la tâche est connue afin de mener certains événements commerciaux.

Pour un développeur, c'est du travail avec une dette technique . C'est l'une des douleurs depuis que je travaille avec eux. la dette, le refactoring, les corrections et améliorations sont très peu de temps.

Le prochain critère de performance est le nombre minimum de bogues. On pourrait écrire que le critère est l'absence totale de bugs, mais nous savons que cela ne se produit pas. De plus, les testeurs seront offensés, car ils ne seront pas nécessaires.

Défis futurs . Je n'ai délibérément pas écrit «architecture réfléchie». Approfondir et réfléchir à l'avance à l'architecture est mauvais, donc le développement doit être touché pour l'avenir, mais sans fanatisme.

Tous les autres critères de chaque équipe.

Processus de développement

Nous avons commencé à construire des processus de développement chez Banki.ru après que la société a commencé à se développer et à se développer. De nouveaux partenaires et projets sont apparus, et 6-9 développeurs back-end n'étaient pas suffisants. Nous sommes arrivés à la conclusion que nous devons construire le processus de développement et le formaliser pour un travail efficace.

Au départ, nous avions 3 équipes, chacune avec 3 développeurs back-end et un manager qui était responsable de certaines parties du site. Les développeurs de backend, en plus de leur travail, continuaient de composer et de connecter des plugins jQuery, car à ce moment-là, il y avait peu de gens sur le frontend.



Nous avons pris deux développeurs front-end et deux autres testeurs pour vivre sans bugs et avons pensé que cette configuration serait suffisante.

Dans un monde idéal, le processus de développement devrait ressembler à ceci.

• Le chef de projet dépose la tâche dans l'équipe backend et l'exécute.
• Si une révision est nécessaire, ils envoient la tâche à l'équipe front-end.
• Après raffinement, le frontend le donne à QA.
• Pas de bugs? - En production.

Nous avons suggéré que le monde n'est pas parfait, et QA renverra des tâches, car des bogues sont présents dans tout développement, et a ajouté deux autres flèches.



Après avoir mis à jour le schéma, nous avons décidé que tout allait bien et nous avons commencé à travailler dessus - nous avons effectué la planification du sprint et les équipes de backend elles-mêmes ont mis les tâches dans le plan. Ils ont travaillé pendant 2 mois et ont réalisé que quelque chose n'allait pas.

Notre schéma s'est transformé. Les tâches sautent comme une balle dans un ping-pong: du QA à l'avant et à l'arrière aux développeurs, et même aux managers.



Les flèches prennent beaucoup de temps - le processus de livraison d'une tâche pour combattre les serveurs est trop long. Cela ne nous convenait pas. Nous voulions minimiser le nombre de flèches afin d'accélérer les tâches.

Comment réduire les délais de livraison?

La première chose qui m'est venue à l'esprit était de poser une question sur la raison pour laquelle nous retournons des tâches ? Pourquoi le backend, le frontend et le QA comprennent-ils le problème différemment? Pourquoi les vues sont-elles différentes? Nous sommes arrivés à la conclusion que nous avons trouvé le coupable dans le chef de projet, qu'il n'a pas décrit les tâches dans son intégralité et que nous avons dit à PM de décrire les tâches plus complètement, afin que tout le monde puisse comprendre ce que cela signifiait.

Nous avions trois équipes back-end de planification. Nous avons impliqué des testeurs et des développeurs frontaux dans la planification , mais pour 3 équipes, il n'y avait que 2 développeurs frontaux et 2 testeurs. Souvent, ils ne réussissaient pas à les appeler, car quelqu'un devait travailler.

Nous avons divisé les tâches séparément en frontend et backend afin de les soumettre au développement en parallèle, de tester plus rapidement et de ne pas attendre toute la chaîne.

Nous avons essayé toutes les solutions. En conséquence, le temps a été réduit, mais nous n'étions toujours pas satisfaits.

Nous avons pensé quoi faire ensuite. Il existe de nombreuses entreprises et pratiques sur le marché, et nous avons commencé à étudier, regarder, creuser et rejoindre l'équipe de fonctionnalités.

Équipe-fonctionnalité

C'est à ce moment-là que l'équipe a tout le groupe complet de personnes pour terminer la tâche:

• développeurs backend.
• développeurs front-end.
• Développeurs QA.

Il y a aussi des connexions entre eux, les tâches sautent et jouent au ping-pong, mais les connexions sont beaucoup plus courtes et prennent moins de temps. Toute l'équipe participe à la planification, elle s'intéresse au résultat et crée une image unique: que faire et comment livrer la tâche en mode combat en peu de temps.

À ce moment-là, nous sommes passés à Agile et Scrum: nous avons invité des entraîneurs et des entraîneurs, organisé des master classes dans l'entreprise et commencé le Scrum classique - sprints de deux semaines, évaluation, planification et préparation. Maintenant, les tâches passent plus rapidement en mode combat, mais beaucoup de problèmes sont sortis.

Problèmes avec l'équipe de fonctionnalités

A cette époque, nous avons eu 6 problèmes.

• Facteur de bus .
• Longue planification . Pour la planification, nous avons mis de côté une demi-journée ou plus: nous avons trié les tâches, nous sommes partis pour le déjeuner, puis à nouveau nous avons trié. Une fois la planification terminée, personne ne pouvait travailler et ne voulait pas - la journée était perdue.
• Sprints non fermés . C'est une douleur grave - la plupart des tâches dans les sprints n'ont pas atteint la colonne «Terminé».
• La nature différente des tâches des équipes .
• L'émergence de nouvelles équipes .
• Échange d'expérience entre équipes .

Il y a des problèmes, nous allons les résoudre.

Facteur de bus

Initialement, chaque équipe était composée d'un développeur frontal, d'un testeur et de trois développeurs principaux. Nous avons embauché des développeurs frontaux supplémentaires - dupliqué les rôles .

Introduit des réunions hebdomadaires dans les directions . Les développeurs front-end se sont réunis séparément chaque semaine et ont discuté des nouvelles technologies, de la résolution de problèmes et se sont mis d'accord sur des pratiques et des approches communes. Les testeurs se sont également réunis, ont conféré, décidé comment tester, discuté des autotests.

Les développeurs frontaux ont introduit une révision de code inter-commandes , lorsqu'un développeur résout un problème dans une équipe et le soumet à la révision d'autres équipes, et après au moins deux déclarations, la tâche passe en test.

Des autotests ont été ajoutés . Il y avait un testeur dans l'équipe et il n'était pas possible de le dupliquer, car il n'y avait pas de tâches pour une telle quantité. Nous nous sommes mis d' accord sur l'aide d'un testeur d'une autre équipe : il s'occupera des tâches de l'équipe voisine et remplacera l'employé qui part en vacances. Cela a légèrement augmenté le temps, mais les tâches ont été testées.

Planification longue

Nous avons analysé les tâches de planification. Au moment des sprints, tout le monde travaillait et codait, et sur la planification presque la première fois qu'ils ouvraient des tâches et trouvaient quoi faire, les testeurs ont clarifié la «définition du fait» afin de comprendre comment tester la tâche.

Le processus prenait du temps. Nous avons décidé de désassembler les tâches avant de planifier : nous avons suggéré que les développeurs regardent la tâche pendant leur temps libre, posent des questions afin qu'ils puissent être préparés pour la planification.

Nous avons invité les gestionnaires à décrire les tâches plus en détail , mais pas trop pour ne pas fouiller dans une tonne de documentation.

Nous avons délibérément réservé une heure de toilettage supplémentaire et non du temps libre. Ils se sont réunis en équipe, ont discuté des tâches et se sont préparés pour la planification.

Sprints non fermés

C'est une douleur. Peut-être que quelqu'un les ferme, mais avec nous à ce moment-là - non.

Nous avons décidé de réduire la capacité de sprint de 10 jours ouvrables à 8 . Nous pensions que nous allions planifier 8 jours et laisser les testeurs 2 jours.

En réalité, il s'est avéré que lorsqu'un développeur voit moins de tâches, il les exécute lentement. 20% de tâches en moins dans le sprint n'ont rien donné.

Au début du sprint, alors qu'il reste du temps, le testeur a réalisé des cas de test. En théorie, au début du sprint, pendant que les développeurs travaillent, le testeur n'a pas de tâches. Nous avons convenu qu'à ce stade, le testeur peut effectuer toutes les tâches, établir des cas de test et, lorsque la tâche arrive pour le test, il l'exécute sur les cas de test préparés et réduire le temps de test. Globalement, cela n'a pas aidé, même si le temps a été légèrement réduit.

Réduire la capacité du sprint et charger le testeur n'a pas aidé, et nous avons pensé comment résoudre le problème. À ce moment, un livre sur le but et plusieurs pratiques de Maxim Dorofeev a attiré notre attention. Nous avons réalisé que pousser le "non-poussable" ne fonctionnerait pas et avons commencé à planifier un sprint à partir d'un goulot d'étranglement - à partir de tests . Lors de la planification, le testeur a fait une évaluation, la capacité de sprint a été calculée à partir de lui et la tâche a été sprintée pour le testeur.

Classe! Nous sommes allés voir les managers pour vendre cette idée:

- Nous avons décidé de planifier des testeurs. Les sprints se fermeront, ce sera cool!
- Attendez, que feront les développeurs libres en ce moment? Il y aura moins de tâches, ils auront du temps libre!
- Voulez-vous que les sprints soient fermés, que le développement soit prévisible ou que l'objectif principal des gens soit de prendre?
- Non, c'est toujours un développement prévisible. Clôturons les sprints.

Après le dialogue, une équipe a commencé à travailler d'une nouvelle manière. Le schéma a montré sa capacité de survie, nous y avons travaillé, des sprints fermés et les développeurs ont eu le temps.

Il s'est avéré que les développeurs peuvent faire beaucoup de choses lorsqu'ils sont gratuits.

A savoir: travailler avec ceux-ci. la dette . L'équipe a toujours une technologie commune. dette au ministère. Ces tâches peuvent être utilisées et testées. En règle générale, ceux-ci. la dette est une refactorisation du système. Des tests de régression sont nécessaires pour ces tâches, et le testeur d'équipe ne doit pas toujours le faire. Le département des tests a identifié des testeurs spéciaux qui ont effectué la régression, y compris le chef du département des tests. Tâches pour ceux-là. la dette a été remise à d'autres employés pour des tests et nos testeurs n'ont pas souffert.

Analyser les tâches du backlog et clarifier les exigences . Lorsque le développeur n'avait aucune tâche, il a examiné l'arriéré, clarifié les exigences. Au moment de la planification, les tâches sont entièrement décrites, toutes les questions sont posées et les décisions sont prises. Il reste à clarifier les détails et c'est tout - le testeur évalue et la tâche est terminée.

Aidez les autres équipes . À ce moment-là, nous nous sommes encore exercés à aider d'autres équipes, dans lesquelles j'étais en difficulté, quelqu'un en vacances ou tombé malade, et le projet était en feu. Des tâches privées distinctes peuvent être prises et assistées par d'autres équipes.

De plus, il y a toujours des congés, des formations, des participations à des conférences, qui demandent aussi du temps pour se préparer. Lorsqu'un employé a la possibilité d'étudier quelque chose, de lire Habr, de regarder une vidéo sur le travail pendant les heures de travail, la fidélité augmente. Nous avons résolu ce problème et tout le monde est devenu à l'aise.

Différentes natures de tâches pour les équipes

Nous avons des équipes de produits qui font quelque chose de nouveau. Ils ont une planification de deux semaines, des sprints, de longs projets et ils viennent de sortir dans 1-2 mois ou plus.

Nous avons des équipes marketing plus réactives: la tâche est terminée, la tâche est terminée. Disons que le service des ventes a vendu le palier - vous devez le faire rapidement. Au départ, ces équipes ont également travaillé sur Scrum et des sprints de deux semaines, mais il s'est avéré qu'à la fin du sprint, les tâches étaient complètement différentes de celles du début. L'insatisfaction de l'équipe, la ruée constante, les sprints ne s'arrêtent pas - la situation est désagréable.

Nous avons décidé de parler avec le PM et les entreprises:

- Les gars, nous avons Agile, Scrum, sprints, processus - ne jetons pas de nouvelles tâches, mais nous nous développerons de manière prévisible.
- Regardez, nous vendons un palier, cela doit être fait en 3 jours. Nous sommes payés un million pour cela. Quels processus? Il faut aussi gagner de l'argent!

Un million nous a convaincus. Nous avons commencé à réfléchir davantage.

Nous avons décidé de réduire les sprints à une semaine - afin de pouvoir réagir plus rapidement. Cela n'a pas fonctionné non plus, car planifier à ce moment pour cette équipe n'a pas fonctionné du tout.
Ensuite, nous avons décidé de ne pas planifier de sprints, mais de travailler sur Kanban au lieu de Scrum : la tâche est venue, a commencé à fonctionner, libérée. Ça a marché. L'équipe a travaillé de manière plus productive, car elle avait d'abord compris qu'il n'y avait pas de planification, mais qu'il n'y avait que des tâches à effectuer.

Afin d'améliorer les processus dans l'équipe et de recevoir des commentaires, nous avons commencé à effectuer des rétrospectives toutes les 2 semaines : l'équipe s'est réunie, a discuté de ce qui s'est bien passé, de ce qui n'a pas fonctionné, des avantages et des inconvénients et a travaillé avec.

L'émergence de nouvelles équipes

À ce moment, nous avons commencé à grandir, de nouvelles équipes sont apparues: nous avons eu le chef d'équipe, les développeurs, l'équipe grandissait et les gens ne s'étaient pas encore habitués les uns aux autres. Nous ne parlons pas de planification pendant cette période - les gens voient notre code pour la première fois, et cela peut être mauvais, par exemple, nous avons un peu de bitrix. Il fallait faire quelque chose avec ça.

Il était possible de prendre le même Kanban pour que les développeurs effectuent les tâches comme ils peuvent, mais c'est une équipe produit, il faut l'enseigner. Nous avons décidé - laissez-les apprendre à planifier et à évaluer les tâches, mais avons réduit le sprint à 1 semaine .

Nous augmenterons le délai à 2 semaines en 1 à 2 mois, lorsque l'équipe s'y habituera, entrera dans le travail général sur le produit, établira des processus et les développeurs pourront évaluer les tâches normalement.

Échange d'expérience entre équipes

Au sein de l'équipe, les développeurs et les testeurs communiquent entre eux et échangent leurs expériences, mais cette expérience n'est pas mise à jour, car l'équipe "cuisine en soi". Aucune nouvelle expérience ne vient d’où.

Nous avons commencé à penser quoi en faire et avons introduit des réunions d'équipe hebdomadaires. Le but des réunions est de transférer l'expérience d'une équipe à une autre par le biais de chefs d'équipe.

Les premières réunions ont été les suivantes:

- Bonjour, je m'appelle Eugene, nous coupons maintenant les nouvelles.
- Cool!

Prochaine réunion:

- Bonjour, mon nom est toujours Eugène, nous continuons de couper les nouvelles.
- D'accord.

Rien d'extraordinaire ne se produit.

Troisième rencontre: Bonjour ... Et tout de même.

Nous avons réalisé que nous devions changer le format. Lisez des livres sur les réunions et
introduit un ordre du jour fixe.

Nous avons maintenant une page wiki avec les dates des réunions Timlid, dans laquelle nous décrivons les problèmes et les tâches à discuter pendant la semaine.

Les avantages de cette décision

• Les timlids se préparent pour la réunion, car ils connaissent l'ordre du jour et comprennent ce qui sera discuté.
• La page wiki est accessible à tous les développeurs. Chaque employé peut apprendre le sujet de discussion, participer au processus et poser ses questions. Après la réunion, nous fixons la décision dans les commentaires, qui sont également disponibles.
• Si un problème n'a pas été résolu après 1-2 mois, vous pouvez voir dans les archives de la réunion comment la discussion du problème a été décidée et donner un coup de pied à l'équipe ou au chef d'équipe en cas d'échec.

Nous avons aimé le format des réunions et nous avons commencé à les organiser régulièrement.

Nous avons introduit une révision de code entre commandes . C'est une sorte d'échange d'expérience que les développeurs front-end, et plus tard les gars du back-end, ont déjà pratiqué. Il n'est pas nécessaire de donner tout le code à une révision de code entre commandes, seules des choses importantes suffisent, par exemple, des bibliothèques partagées ou des morceaux de code communs. Pour la révision du code, nous avons sélectionné uniquement les équipes intéressées, il n'y avait pas d'approbation obligatoire.
Il y a des situations où une équipe voisine qui traite avec des banques demande à affiner la fonctionnalité - ajoutez des champs et nous traitons des prêts. Vous pouvez demander à une autre équipe, mais elle a son propre plan et il n'est pas clair quand elle répondra à la demande, mais vous ne pouvez pas attendre. Dans cette situation, nous aidons l'équipe voisine, mais lors de la révision du code, nous en donnons une autre.

Il se trouve que les développeurs sont invités à passer à une autre direction ou à changer de technologie. Par exemple, nous avons un employé qui s'occupe des cartes de crédit depuis un an et demande de changer de zone, tandis qu'un autre souhaite changer la technologie de l'interface utilisateur à Symfony. Par accord, nous organiserons la transition des développeurs entre les équipes .

Certaines entreprises pratiquent des réunions le vendredi: les gens se réunissent pour échanger leurs expériences, discuter de quelque chose et parler. Nous avons également décidé d'organiser des rassemblements vendredi - nous avons commencé une page dans le Wiki, où tous ceux qui veulent parler écrivent le sujet de son rapport.

Tout était cool. Lors des rassemblements, les équipes ont parlé de ce qu'elles faisaient, des nouveautés. Par exemple, avec l'une des équipes, nous avons eu un malentendu, personne ne savait ce qu'elle faisait. Lors d'une réunion de vendredi, l'équipe a parlé de leur travail, a montré des analyses et tout le monde a compris le sens de leur travail. Les développeurs frontaux ont expliqué comment l'assemblage se déroule, discuté de sujets techniques généraux, par exemple, comment utiliser le débogueur dans PHPStorm, comment le déploiement se produit.

Et puis les sujets de développement ont pris fin, nous sommes passés à des sujets psychologiques et l'histoire a commencé à s'estomper. Comment inciter davantage les développeurs à dire quelque chose?

Et puis nous nous sommes souvenus de KPI ! Apprenons à chaque développeur à parler et à inclure dans ses rapports KPI 2 pendant six mois les rassemblements du vendredi. Nous pensions que l'idée était cool et que tout le monde se présenterait.

Il s'est avéré qu'après l'introduction de KPI, les développeurs ont cessé de faire des rapports. Des apparitions négatives sont apparues pour les représentations obligatoires. Les programmeurs ont décidé de sacrifier la mise en œuvre à 100% des KPI, juste pour ne pas faire de rapports volontaires obligatoires.

Conclusions

Pendant que nous résolvions des problèmes d'efficacité, l'entreprise se développait et de nouveaux projets sont apparus et nous avons dû nous adapter. C'est ce que nous avons compris de cela.

• Adaptez-vous aux changements et ne vous concentrez pas sur ce qui est accepté, examinez les changements et choisissez les meilleures pratiques pour travailler avec l'équipe. Si les développeurs ne peuvent pas travailler sur Scrum - travaillez sur Kanban pour que tout le monde soit heureux et heureux.
• Surveillez et modifiez constamment les processus . En tant que chefs d'équipe, vous devez contrôler les processus au sein de l'équipe. , . , , . , .

— .

. , , , : , PM, .

— , .

, :
— . — , PM.
PM .
— , ? — PM , .

, , .

. .

, . Jira Slack, , , . Scrum-, .

, .

.

. , . , . , - , — , — - . , . :

— ?
— !
— !
— , iMessage!

, - : , .

, : , , , 2 , .

« » .

— , , .

. , «», — , , . , , , . , , .
Soyez des filtres entre l'environnement et l'équipe. Toutes les informations doivent être dosées afin de ne pas démotiver les développeurs.

La collecte du programme TeamLead Conf , qui se tiendra les 25 et 26 février à Moscou, est au stade le plus chaud. Je vais vous parler des résultats ici, quand tout sera lié au calendrier, et les collections thématiques régulières viendront dans la liste de diffusion .