.png)
.png)
Les équipes Produit sont des groupes transverses qui réunissent un mélange de product managers, designers, data scientists, rédacteurs... et développeurs. Alors les OKR Ingénierie doivent-ils exister si nous avons déjà des OKR Produit ?
Oui. Les OKR Ingénierie se concentrent sur la qualité du travail, tandis que les OKR Produit se concentrent sur la livraison de la bonne valeur. C'est une vision un peu simplifiée, mais elle met en lumière les deux faces de la médaille. Dans de nombreux cas, vous aurez besoin d'un excellent travail de développement pour améliorer l'expérience utilisateur. Mais il existe aussi de nombreux aspects propres à l'Ingénierie que les objectifs Produit ne couvriront pas.
Axes prioritaires :
Questions clés :
Notre processus de développement est-il efficace ?
Quelle est la qualité de nos livraisons ?
Générons-nous trop de dette technique ?
Notre équipe de développement peut-elle donner le meilleur d'elle-même ?
Comment rédiger des OKR pour les équipes d'ingénierie
Étape 1. Comprendre la différence entre OKR et projets
Avant de vous lancer dans le processus des OKR, il est essentiel de comprendre la différence entre les Objectifs, les Résultats clés et les projets :
- Objectifs : que voulons-nous accomplir le trimestre prochain ?
- Résultats clés : comment allons-nous mesurer les progrès ?
- Projets/Initiatives : quels sont nos meilleurs paris pour y arriver ?
Les projets sont mentionnés ici car une erreur courante consiste à les lister comme des Résultats clés. Mais un projet est un livrable (Output), plutôt qu'un objectif (Outcome).
Un bon Objectif doit être inspirant et facile à comprendre par n'importe qui dans votre organisation. Vous pouvez être plus précis dans les Résultats clés, mais les Objectifs doivent donner une idée claire de l'impact attendu à la fin du trimestre.
Un bon Résultat clé doit vous aider à mesurer les progrès vers votre Objectif. Un bon test consiste à se demander : « agirions-nous différemment si ce Résultat clé déraillait ? ». Si la réponse est non, alors vous devez affiner votre OKR.
Enfin, vos projets sont des paris que vous faites pour atteindre vos OKR. Certains fonctionneront — misez davantage sur ceux-là. D'autres échoueront, et il doit être normal de s'arrêter et de passer à l'idée suivante.
Étape 2. Choisissez 2 à 3 axes de priorité
L'étape suivante consiste à choisir le bon axe de priorité. Une équipe d'Ingénierie aura plusieurs options parmi lesquelles choisir :
- Fiabilité : s'assurer que le service fonctionne toujours comme prévu.
- Utilisabilité : améliorer les fonctionnalités existantes pour rendre la plateforme intuitive.
- Fonctionnalités : livrer de nouvelles capacités.
- Sécurité : améliorer la protection existante, et ajouter de nouvelles mesures de protection pour protéger les clients.
- Performance : s'assurer que votre application est réactive et évolutive.
- Vitesse de développement : investir dans votre cycle de développement pour des livraisons plus rapides.
N'essayez toutefois pas de tout traiter en même temps. Vous devrez isoler 2 ou 3 thèmes pour le trimestre, et les utiliser comme point de départ pour vos OKR.
Étape 3. Rédigez votre plan
Une fois que vous avez affiné votre priorité, vous pouvez commencer à rédiger vos OKR.
Accordez-vous sur 2 à 3 Objectifs avant de vous plonger dans les Résultats clés. Vous trouverez quelques exemples ci-dessous, et voici un guide sur la rédaction des OKR si vous débutez
Exemple d'OKR pour l'Ingénierie
OKR pour réduire la dette technique
S'attaquer à la dette technique générée par la course aux nouvelles fonctionnalités
Réduire de 30 % le pourcentage de tickets identifiés comme dette technique
Migrer 80 % des projets vers la nouvelle bibliothèque UI pour réduire la dette d'interface
Réduire de 50 % le taux de contacts liés à la dette technique
OKR pour améliorer la vitesse de développement
Accélérer le développement grâce à l'automatisation
100 % des dépôts disposent d'un pipeline de livraison continue
Augmenter la couverture de code de 30 % à 60 %
Réduire le temps de build de 20 à 5 minutes
Réduire le temps de cycle de 8 jours à 24 heures
Tous les développeurs ont accès à une bibliothèque QA d'exemples de tests automatisés
OKR pour une meilleure performance et fiabilité
Construire une infrastructure de classe mondiale
Augmenter l'Apdex de 0,7 à 0,98
Réduire de 40 % le nombre d'incidents ayant déclenché une alerte
Améliorer le taux de sessions sans crash de 75 % à 95 %
Réduire le temps de chargement des pages principales à moins de 3 secondes
OKR pour améliorer la qualité du code
Démontrer des standards exceptionnels en matière de qualité de code
100 % des pull requests sont relues par 2 développeurs
75 % des développeurs ont suivi une formation QA
100 % des dépôts utilisent le linting et l'analyse statique de code
Réduire de 60 % le pourcentage de builds cassés liés à la QA
OKR pour offrir une excellente expérience utilisateur
Améliorer significativement l'expérience utilisateur grâce à de meilleures performances
Réduire de 45 % le nombre d'exceptions en production
Réduire le temps de démarrage à froid des instances clients de 2 minutes à 10 secondes
Réduire le temps de réponse de l'API de 900 ms à 450 ms
Améliorer le NPS de 15 à 35
Suivre vos OKR
Savoir écrire de bons OKR est essentiel, mais sans un bon suivi, les OKR s'estomperont et la concentration se perdra.
Nous ne sommes pas les seuls à le dire :
- Peter Kappus écrit que « les check-ins sont la partie la plus importante des OKR ».
- Felipe Castro met en garde contre le fait de laisser ses OKR se transformer en résolutions de nouvel an.
- Christina Wodtke nous dit que « la cadence est probablement l'élément le plus important ».
Plus il est facile pour une équipe d'avoir des discussions hebdomadaires autour des OKR, mieux elle les exécutera. Voici quelques bonnes pratiques pour suivre vos OKR.
1. Faites des check-ins hebdomadaires
Les OKR trimestriels doivent être suivis chaque semaine pour être efficaces. Sans une réflexion continue sur la progression, vos OKR ne seront pas très différents des KPI.
Le processus de check-in peut être automatisé grâce à une plateforme comme Tability, qui se charge des rappels et distribue les mises à jour aux équipes.
2. Suivez votre niveau de confiance
De bonnes mises à jour de progression devraient permettre à chacun de comprendre où l'on en est par rapport à l'objectif, mais aussi le niveau de confiance dans sa réussite. Vous pouvez utiliser un simple code couleur rouge/jaune/vert pour indiquer votre confiance.
3. Rendez les tendances faciles à voir
Enfin, il est important d'observer les tendances pour éviter les faux positifs. Il n'est pas rare qu'une équipe démarre en trombe puis ralentisse en milieu de trimestre. Cela sera difficile à voir à moins de pouvoir observer les tendances de progression pour chaque Résultat clé.
Quelles autres métriques Ingénierie pouvez-vous utiliser ?
Maintenant que vous avez de bons objectifs, il est temps de choisir de bons résultats clés, et trouver de bonnes métriques adaptées à votre équipe peut s'avérer délicat. Heureusement, nous avons répertorié toutes les à utiliser.
En voici quelques-unes pour commencer :
Temps de cycle
Le temps qu'il faut pour passer du code commité au code livré aux clients.
Volume de déploiements
Le nombre de déploiements effectués chaque jour/semaine/mois.
Taux d'ouverture/fermeture
Le nombre de tickets ouverts divisé par le nombre de tickets fermés.
Nombre d'incidents
Le nombre d'incidents survenus en production, idéalement classés par gravité.
Couverture de code
Le pourcentage de code couvert par des tests automatisés.
Temps de build
Le temps moyen nécessaire pour terminer un build. Indique combien de temps un développeur doit attendre pour savoir si ses modifications ont cassé l'application.
Temps de revue jusqu'à la fusion (RTMT)
Le temps nécessaire pour qu'une revue de code soit terminée et fusionnée.
Vous avez un objectif en tête, mais ne savez pas comment l'atteindre ?
L'IA gratuite de Tability peut créer une stratégie détaillée avec toutes les étapes à suivre pour atteindre vos objectifs.
Générer votre stratégie avec l'IA
