Vous gérez la meilleure équipe de l'entreprise : le temps de cycle le plus rapide, la plus grande précision de planification et le moins de retouches. Votre équipe a le temps de révision le plus court, le plus de déploiements hebdomadaires et le meilleur rapport bogues/KLOC. Et puis quelqu'un de haut placé arrête votre projet - que vient-il de se passer ?

Le paradoxe de la sortie

En tant que développeur junior, on m'a appris que la fusion fréquente de petites modifications est essentielle pour générer rapidement de la valeur. En tant que responsable junior de l'ingénierie, on m'a dit que le suivi et l'optimisation des mesures étaient essentiels au travail du responsable. Le premier résultat Google m'a indiqué un tas de termes et d'acronymes, et ce sont mes premières introductions aux métriques de développement.

Les métriques de développement sont essentiellement un ensemble de métriques qui aident les équipes d'ingénierie à suivre leur vitesse (mouvement rapide) et leur qualité (sans casser les choses). Différentes métriques peuvent être utilisées pour mesurer ces attributs. Le temps de cycle, le nombre de PR ou les problèmes résolus suivent la vitesse. Pour suivre la qualité, surveillez le nombre de défauts, le temps moyen de résolution ou le nombre de déploiements à l'origine de l'échec. Chacune de ces mesures fournira des informations différentes sur l'attribut que vous inspectez. Certaines métriques aident également à analyser les attributs de proxy. Suivez les retouches pour analyser l'efficacité, ce qui a un impact sur la vélocité. La précision de la planification est un bon indicateur de prévisibilité, qui permet à la fois la rapidité et la qualité et a une valeur en soi.

Le problème avec toutes les mesures ci-dessus est que, bien qu'elles fassent un excellent travail de mesure de l'efficacité, elles ne suffisent généralement pas à mesurer le succès. La raison principale est qu'ils sont totalement déconnectés des KPI (indicateurs clés de performance, encore un autre nom fantaisiste pour les métriques) de l'entreprise. Cette déconnexion conduit souvent à une communication inefficace entre les organisations de l'entreprise, principalement les produits et l'ingénierie. Après tout, l'organisation du produit (et le reste de l'entreprise) ne se soucie pas uniquement de la vitesse ou de la qualité, car celles-ci suivent la sortie . L'organisation du produit se soucie généralement du résultat : quels revenus notre nouvelle fonctionnalité a-t-elle généré ? Combien de nouveaux utilisateurs avons-nous attiré ?

En tant que nouveau responsable de l'ingénierie, cela me déconcertait. D'une part, il était clair que continuer à mesurer mon équipe en se basant sur des métriques de développement plutôt que sur des métriques commerciales conduirait à un désalignement avec l'équipe produit. D'autre part, il semblait injuste de mesurer mon équipe sur la base de métriques commerciales : comment peuvent-elles les impacter ? Est-ce notre métier ? Vais-je marcher sur les pieds de l'organisation du produit ?

Mesurez ce qui compte

J'ai fait un acte de foi et j'ai essayé d'utiliser des mesures commerciales comme étoile du nord. Au fil du temps, cela a conduit à de meilleurs résultats.

Tout d'abord, cela a simplifié la communication. il est plus facile pour votre homologue de produit de comprendre pourquoi il est essentiel de prioriser la mise à niveau de la base de données lorsque vous la mettez en termes de KPI partagé qui sera lésé. Tout simplement parce qu'il est clair pour vous que si vous ne donnez pas la priorité à la mise à niveau de la base de données, les quelques histoires d'utilisateurs suivantes prendront deux fois plus de temps et vous devrez consacrer du temps à la maintenance, ce qui retardera la publication de la fonctionnalité à un point où vous avez gagné Vous n'avez pas assez de temps pour atteindre l'objectif d'utilisation que vous avez défini comme KPI, cela ne signifie pas qu'il est clair pour votre homologue produit. Je veux dire, c'est beaucoup de sauts; pourquoi ne pas commencer par celui qui compte ? (non, ce n'est pas celui de la mise à jour de la base de données)

Deuxièmement, mesurer mon équipe sur la base de métriques commerciales m'a fait voir que nous pouvons les impacter un peu :

• Nous pouvons identifier les fonctionnalités pour lesquelles nous pouvons créer 80 % de la valeur utilisateur pour 20 % de l'effort. Cela peut libérer des ressources pour aider à déplacer nos KPI encore plus rapidement. Pour ce faire, l'équipe doit clairement comprendre les objectifs commerciaux, les besoins des utilisateurs et la volonté de les améliorer.
• Nous pouvons utiliser les KPI pour guider la dette technologique que nous devrions accumuler : essayons-nous d'obtenir nos premiers utilisateurs de fonctionnalités, et l'échec des fonctionnalités est une option ? Libérons aussi vite que possible et inquiétons-nous de la dette technologique plus tard. Essayons-nous d'améliorer la fidélisation d'une large clientèle ? Assurons une haute qualité pour celui-ci.
• Nous pouvons suggérer des solutions aux problèmes que le produit ne savait même pas résoudre, sur la base d'une nouvelle avancée technologique ou d'un angle d'ingénierie innovant.
• Nous pouvons (aussi ennuyeux que cela puisse être) utiliser les KPI pour comprendre qu'il ne sert à rien de poursuivre une solution technologique cool spécifique que nous voulons mettre en œuvre car le problème lui-même n'est pas crucial pour l'entreprise.

Comment mesurer le succès ?

Après être passé à des métriques importantes pour l'entreprise, mon homologue produit et moi avons dû choisir un cadre pour les mesurer. Chez Epsagon, nous avons utilisé le framework OKR . Je n'entrerai pas dans les détails car il existe de nombreuses ressources intéressantes pour la mise en œuvre des OKR disponibles en ligne. L'essentiel est qu'il s'agit d'un excellent cadre pour les moyennes et grandes organisations, généralement dans la phase post-produit-marché. Il aide à aligner différentes équipes, groupes et organisations au sein de l'entreprise vers les mêmes objectifs axés sur les résultats.

Chez Epsagon, nous avions des OKR pour chaque équipe produit, et c'étaient les objectifs des ingénieurs, des personnes chargées du produit et de la conception qui composaient l'équipe produit. Une fois implémenté, nous avons eu une meilleure collaboration entre le produit et l'ingénierie. Moins de disputes sur les exigences et plus de coopération pour résoudre les problèmes. Nous avons également remarqué que l'augmentation de l'autonomie causée par la fixation d'objectifs plutôt que de tâches a accru l'innovation et l'appropriation des résultats. Les équipes ont défini la feuille de route et les solutions sont venues de l'ingénierie ainsi que du produit.

L'inconvénient de cette méthodologie est qu'elle nécessite un certain effort de mise en œuvre et vous oblige également à être en mesure d'énoncer vos objectifs sur des périodes de plusieurs mois. C'est généralement difficile pour les petites start-ups, surtout avant l'adéquation du produit au marché. Pour les étapes précédentes, il est acceptable de travailler avec une métrique principale tout en étant guidé par un objectif commercial tout en restant suffisamment agile pour modifier vos objectifs et vous concentrer sur la granularité des semaines ou des jours.

Que votre équipe soit grande ou petite, qu'elle ait une mission ou des priorités concurrentes, tant que vous mesurez ce qui compte, vous avez plus de chances de réussir. Le "comment" n'est qu'une optimisation.

La communication est la clé

Une fois que nous avons établi des KPI commerciaux, la prochaine étape consiste à suivre. D'après mon expérience, il y a deux aspects essentiels à la communication et à la mise en œuvre de ce changement. Le premier est la cohérence : il ne suffit pas de définir ces paramètres et de les revoir trois mois plus tard pour découvrir que nous avons raté nos marques. En tant que leaders, il est de notre devoir de surveiller en permanence ces mesures et de nous assurer que leur état et leur feuille de route pour les améliorer sont toujours communiqués à toute notre équipe.

Le deuxième aspect est l'engagement : il est tentant de revenir aux anciennes habitudes consistant à mesurer les individus à l'aide de métriques de développement pour les optimiser. Cela enverra le mauvais message à votre équipe, laissant entendre que même si vous dites que vous vous souciez des KPI de l'entreprise, ce qui vous intéresse vraiment , ce sont les métriques de développement. Assurez-vous de changer vos habitudes pour refléter vos priorités : célébrez les résultats commerciaux, supprimez les fonctionnalités non indispensables au lieu de respecter les délais et signalez lorsque les indicateurs de performance clés de l'entreprise sont en baisse. Vous pouvez toujours utiliser les métriques de développement comme indicateurs ; n'oubliez pas de les lier à leur effet sur les KPI de l'entreprise.

Les mesures de développement sont-elles obsolètes ?

Malgré le titre click-baiting de cet article, la réponse est non - ils doivent simplement être utilisés correctement. D'une part, les métriques de développement sont des outils puissants pour dépanner les métriques de votre entreprise. Par exemple, une baisse de la rétention des utilisateurs peut s'expliquer par une augmentation du nombre de défauts. Dans ce cas, vous pouvez utiliser la métrique de développement comme indicateur avancé : au lieu d'attendre que la rétention diminue, vous devez surveiller le nombre de défauts pour l'empêcher de chuter (de la même manière que vous surveilleriez l'utilisation du processeur pour éviter le nombre d'erreurs d'API 5xx d'augmenter et de causer un préjudice réel à vos utilisateurs). Un autre cas d'utilisation est celui des métriques de développement en tant qu'indicateur principal de l'expérience et de la satisfaction des développeurs (ce qui, à son tour, a un impact sur la rétention des développeurs).

Cependant, la chose essentielle à retenir est que vous ne devez jamais optimiser les métriques de développement. Vous devez toujours optimiser les métriques commerciales et utiliser l'optimisation des métriques de développement uniquement comme un outil pour atteindre cet objectif. Et, bien sûr, vous ne devez définir, suivre ou optimiser les objectifs de métriques de développement qu'après avoir une idée claire du résultat commercial que vous essayez d'atteindre et des KPI commerciaux que vous essayez d'atteindre. De bonnes statistiques d'ingénierie ne sauveront pas votre projet s'il n'a aucune valeur.

Et après?

Si vous dirigez une organisation d'ingénierie, passer à l'optimisation des résultats commerciaux plutôt qu'aux métriques de développement améliorera les chances de votre équipe de créer un impact réel sur l'entreprise. Si vous vous engagez à devenir un leader axé sur les résultats, je vous exhorte à vous poser ces questions :

• Est-ce que je sais quels résultats commerciaux on attend de moi ?
• Est-ce que je fais tout ce que je peux pour optimiser ces résultats ?
• Comment suivre le succès ? Quels sont les critères pour lever un drapeau ou changer mes plans ?
• Mon équipe est-elle au courant des objectifs commerciaux et de la feuille de route pour les atteindre ? Quelle est leur contribution là-dessus ?
• Lequel de mes KPI commerciaux peut être amélioré en améliorant quelles métriques de développement ?