Comme cela arrive souvent dans la vie: un nouveau manager arrive et définit la tâche d'augmenter le nombre de fonctionnalités réalisées de 2 fois pour le prochain sprint. Les développeurs, bien sûr, essaient, travaillent, restent pour le week-end, respectent le plan, mais pour une raison quelconque, tout le monde quitte.
La plupart des gens voient la productivité basée sur un paradigme:
plus vous produisez, plus vous en faites, plus votre productivité est élevée . Mais la vraie productivité est fonction de deux éléments: le résultat obtenu et les ressources dépensées. Il est souvent assez difficile de maintenir un équilibre entre les résultats et les ressources. Cependant, cet équilibre est le point essentiel. Elle conduit à un équilibre de court et long terme.
Tout leader, qu'il soit à la tête d'une équipe de développement ou à la tête d'un département, doit veiller à augmenter la productivité de son équipe. Mais comment le faire judicieusement? Est-il possible d'augmenter la productivité d'une équipe, par exemple, de 10 fois?
Aujourd'hui, je vais essayer d'exprimer mon point de vue sur cette question. Si vous êtes intéressé, bienvenue au chat!
Vous devez d'abord comprendre ce qu'est la productivité et comment elle est mesurée dans votre équipe. Dans ce cas, vous pouvez utiliser des indicateurs complètement différents. Ils peuvent être quantitatifs et qualitatifs.
À titre d'exemple d'indicateurs quantitatifs, vous pouvez prendre, par exemple, le nombre de fonctionnalités livrées au client par unité de temps. Quelqu'un évalue encore le travail des programmeurs dans les lignes de code (oui, oui, cela arrive à ce jour), quelqu'un s'intéresse au nombre d'erreurs corrigées, au nombre d'autotests, etc.
Pour établir des indicateurs de qualité, vous devez trouver des normes d'attitude. Par exemple, les performances actuelles du complexe et les besoins en fer N. Ensuite, la métrique sera une augmentation de la productivité du produit de 25% ou une accélération de l'exécution des tâches à long terme du même 25%.
Une bonne métrique est le coût par unité. Une unité de produit est tout ce qui a au moins une certaine valeur pour l'utilisateur (fonctionnalité, correction d'erreurs, amélioration des performances, etc.). Elle peut être mesurée en termes de personne, de produit, de projet, etc. Ce sont toutes les métriques décrites ci-dessus, mais exprimées en argent.
Pour beaucoup, une métrique importante est le temps de cycle (le moment où le changement est livré au client). C'est une chose lorsque vous déployez de nouvelles fonctionnalités et des modifications chaque jour, une autre chose - une fois par mois ou même moins.
Vous ne pouvez pas parler de productivité d'équipe indépendamment de la qualité du produit livré. Bien sûr, vous devez disposer d'un ensemble complet de métriques qui évaluent la qualité de votre produit. Donnons quelques exemples de telles mesures:
- le nombre d'erreurs détectées par les clients sur la période suivant la livraison d'une nouvelle version (exemple d'une métrique externe)
- le nombre d'erreurs trouvées dans le service de test après le transfert de fonctionnalité ou la correction à la vérification (exemple d'une métrique interne).
Alors, comment augmentez-vous la productivité de votre équipe?
Regardons le
produit grâce à l'équipe. Tout le monde connaît le principe de Pareto, d'où il résulte que 20% des fonctionnalités du produit couvrent 80% des besoins des utilisateurs. Le reste de la fonctionnalité est rarement utilisé ou pas du tout utilisé. Il est très important de passer du temps d'équipe précisément sur les fonctionnalités nécessaires et importantes, alors débarrassez-vous du code ancien et inutile, refactorisez, simplifiez le code et son support. À l'avenir, cela augmentera considérablement l'efficacité de l'équipe.
Il est incroyablement facile de tomber dans le piège de l'activité, dans le cycle des affaires et des événements, en dépensant de plus en plus d'efforts pour créer de nouvelles fonctionnalités inutiles, changer la conception, etc., afin de réaliser à un moment donné que personne n'en a besoin . Vous pouvez être une personne très occupée sans être efficace.
Traitons l'
équipe . Ce n'est un secret pour personne que certains développeurs sont plusieurs fois, 10 fois plus productifs que leurs collègues. Votre tâche en tant que leader est de construire une équipe solide et de ne sélectionner que les meilleurs candidats. Cela implique le fait que vous devez dire au revoir aux participants franchement faibles qui réduisent la productivité de toute l'équipe. Posez-vous constamment la question: embaucheriez-vous cette personne à ce poste, sachant ce que vous savez maintenant? Sinon, il ne devrait pas l'occuper.
Cependant, ne coupez pas l'épaule. Il y a des cas où la productivité d'un membre individuel de l'équipe est faible, mais quand il / elle est dans une équipe, la productivité de toute l'équipe augmente! Il est important dans l'équipe d'avoir une personne qui élèverait le moral général de l'équipe. Même s'il fait moins que les autres, il rallie l'équipe et améliore le résultat global.
Tenez compte des
problèmes d'organisation et de processus . En tant que leader, vous devez suivre le processus suivant:
- éliminer le «goulot d'étranglement» dans vos processus et votre équipe actuels,
- établir une rétroaction sur le changement,
- répétez ce processus un nombre infini de fois.
Après avoir éliminé le goulot d'étranglement une fois, il sortira dans un autre endroit. En supprimant le nouveau goulot d'étranglement, vous l'obtiendrez à nouveau, probablement à plus petite échelle. À un moment donné, vous vous rendrez compte que la recherche d'un cou est devenue trop compliquée pour vous et que son retrait est plus cher que le bonus du résultat. Le moment est venu pour vous d'expérimenter les processus! Recherchez les meilleures pratiques, essayez de les appliquer à votre équipe, adaptez-vous! Pas besoin d'avoir peur des échecs, toutes les meilleures pratiques ne prennent pas racine dans des équipes spécifiques. Tirez des conclusions et continuez.
Vous devez essayer d'automatiser tout ce pour quoi l'automatisation dans votre équipe est raisonnable. Personne ne prétendra que la grande majorité des projets devraient utiliser CI / CD pour déployer rapidement et livrer une nouvelle version du produit au client. Les autotests ne sont actuellement pas utilisés uniquement par un leader paresseux. Vous-même pouvez et devez trouver le moyen le plus raisonnable d'automatiser spécifiquement pour votre équipe.
Eh bien, la règle finale pour les managers et tous ceux qui veulent se développer!
Sortez de votre zone de confort! Méfiez-vous de la grenouille dans le syndrome de l'eau bouillante. Ils disent que si vous jetez une grenouille dans l'eau chaude, elle sautera immédiatement. Mais si vous mettez la même grenouille dans de l'eau à température ambiante et que vous chauffez progressivement l'eau à ébullition, la grenouille n'essaiera pas de sortir et à la fin elle bouillira. Je ne sais pas à quel point ce vélo est vrai en ce qui concerne les grenouilles, mais quelque chose comme ça, j'observe périodiquement avec les gestionnaires et les employés. Les gens ont tendance à s'habituer progressivement à des choses inacceptables qui pourraient les choquer s'ils les voyaient avec un regard neuf.
Développer, grandir, réussir!