Expérience de développeur. Si vous fournissez des API ou des produits API-first, vous entendez probablement beaucoup ce terme. Après tout, vous avez besoin de développeurs pour qu’une API réussisse – et s’ils n’ont pas une grande expérience, ils passeront à autre chose.
Qu’est-ce que l’expérience développeur ?
Developer Experience (DevEx ou DX) est une extension de l’expérience utilisateur (UX) où l’accent est mis sur les utilisateurs impactés par l’aspect technique des choses – par exemple, les outils, les langages et les flux de travail. Mais DevEx est bien plus qu’une « UX pour les développeurs » : cela signifie s’assurer que les développeurs peuvent facilement comprendre et exploiter une API pour leurs propres applications et cas d’utilisation. Un grand DevEx se produit lorsque vous communiquez avec vos utilisateurs développeurs, en comprenant et en répondant directement à leurs besoins. Si vous parvenez à convaincre les développeurs, vous pouvez créer un vaste écosystème florissant autour de vos produits.
Quelles sont les mesures importantes ? Cela dépend de votre rôle
Le célèbre consultant en gestion Peter Drucker l’a peut-être mieux dit : « Si vous ne pouvez pas le mesurer, vous ne pouvez pas le gérer.
L’amélioration de DevEx commence par des métriques. Vous voudrez mesurer les choses qui comptent le plus pour DevEx, en évitant les métriques de vanité et en liant des transactions d’API spécifiques à la valeur commerciale. Cependant, ce qui compte le plus pour vous dépend de votre rôle dans l’amélioration de DevEx.
Il peut y avoir trois rôles distincts dans votre organisation axés sur DevEx : responsable de l’expérience des développeurs, professionnel des relations avec les développeurs et responsable des produits API. Les préoccupations de chacun de ces rôles se chevauchent, mais leur orientation diffère. Ces objectifs distincts seront représentés dans les mesures qui les intéressent le plus.
Responsable de l’expérience développeur
Les responsables DevEx se concentrent sur l’efficacité des API ou des produits API-First utilisés par les développeurs. Ils examinent également les moyens d’améliorer les processus afin que les développeurs réussissent. Le gestionnaire DevEx est responsable de l’exécution de tout ce que les développeurs accèdent et utilisent – du portail des développeurs et de la documentation aux exemples de code et aux SDK.
Les responsables DevEx s’assurent que les développeurs ont une excellente expérience avec les outils et les processus associés au produit. En tant que tels, les métriques dont ils se soucient le plus sont les suivantes.
Délai d’activation de l’utilisateur
Combien de temps faut-il à un développeur pour commencer à utiliser l’API une fois l’inscription terminée ? Des heures, des jours, des semaines ? Si un développeur n’intègre pas ou n’active pas rapidement, cela peut indiquer un problème. Peut-être que votre documentation est confuse ou que vous n’avez pas de SDK pour les langages populaires. Si un développeur ne s’intègre pas ou ne s’active pas en quelques jours, un bon responsable DevEx en prendra note.
C’est l’heure du premier Hello World
Time to First Hello World (TTFHW) mesure le temps qu’il faut à un nouveau développeur pour être opérationnel et atteindre le niveau de valeur minimal de votre API. Chaque développeur a des critères différents pour ce qui constitue ce premier succès. Il peut s’agir d’appeler l’API pour la première fois et d’obtenir une réponse. Il peut s’agir de créer une application de test simple et d’effectuer une transaction qui vérifie que l’API répond aux besoins du développeur. Mais dans tous les cas, le temps nécessaire à un développeur pour obtenir un minimum de succès avec votre API est une indication clé pour savoir s’il continuera à l’utiliser et se convertira en client payant.
Nombre de développeurs ayant besoin d’assistance
Combien de développeurs ont contacté pour obtenir de l’aide sur un problème ? De nombreux développeurs rencontrent-ils le même problème ? Les responsables DevEx doivent consigner tous les problèmes d’intégration en interne et suivre le nombre de développeurs qui ont besoin d’aide.
Il est temps de soutenir la résolution
Si vous disposez d’un système d’assistance, combien de temps faut-il à votre équipe pour résoudre les problèmes d’assistance technique ? Les développeurs ne veulent pas attendre pour résoudre leurs problèmes avec votre API ou l’intégration. Ils veulent des réponses rapides pour les aider à aller de l’avant et à atteindre leurs objectifs de développement.
Professionnel des relations avec les développeurs
Les professionnels des relations avec les développeurs (DevRel) visent à amener les développeurs à adopter une API ou une plate-forme API et à atteindre leurs objectifs avec. Les rôles typiques de DevRel incluent l’évangéliste des développeurs, l’avocat des développeurs et le gestionnaire de communauté.
Les professionnels de DevRel se concentrent sur l’établissement et le maintien de relations avec les développeurs et les communautés de développeurs desservies par le produit ou le service. Les personnes occupant des postes DevRel se soucient d’établir des liens avec les développeurs, d’écouter leurs réflexions et de déterminer comment répondre à leurs besoins. Ils aident également les développeurs à comprendre comment utiliser l’API ou le produit, en proposant des démonstrations et des événements éducatifs de premier plan, comme des hackathons et des rencontres.
Deux mesures nord-étoiles pour les professionnels de DevRel sont TTFHW et Weekly Active Tokens (WAT).
Jetons actifs hebdomadaires (WAT)
Les professionnels de DevRel veulent voir combien de traction l’API obtient et si la communauté des développeurs se développe. Pour aider à comprendre cela, ils peuvent consulter les jetons actifs hebdomadaires (WAT) pour l’API. La plupart des API limitent l’accès aux utilisateurs authentifiés, afin qu’ils puissent suivre le nombre de jetons uniques qui accèdent à la plate-forme d’API chaque semaine. S’ils réduisent cette métrique aux sociétés intégrées actives hebdomadaires, l’équipe DevRel peut déterminer où investir plus de temps et d’efforts dans la sensibilisation et le marketing des développeurs.
Autres métriques DevRel
Bien que TTFHW et WAT soient les deux principales mesures sur lesquelles les professionnels de DevRel se concentrent, ils peuvent également être intéressés par des mesures telles que :
- Dans quelle mesure l’entreprise dispose-t-elle de documents, de guides et de ressources de démarrage rapide ?
- À quelle fréquence et pendant combien de temps les développeurs interagissent-ils avec la documentation de référence ? Quelles pièces ?
- Dans quelle mesure les développeurs sont-ils satisfaits du support qu’ils reçoivent ?
- À quelle fréquence les équipes créent-elles du contenu pour aider les développeurs ?
- Les développeurs interagissent-ils avec le contenu pédagogique proposé par l’entreprise ?
Chefs de produit API
La gestion des produits API est quelque peu nouvelle, de sorte que les responsabilités de ce rôle varient en fonction de l’entreprise et des produits API qu’elle propose. En général, un chef de produit API comprend la justification commerciale de l’API ou de la plate-forme API et les objectifs de haut niveau des initiatives API de l’entreprise. Ils doivent également équilibrer les besoins des parties prenantes internes et des développeurs de produits avec les demandes des clients.
Les gestionnaires de produits API se concentrent principalement sur la croissance des utilisateurs, la rétention des utilisateurs et les modèles d’utilisation. Ils doivent savoir quelles fonctionnalités et quels points finaux les développeurs utilisent le plus (et le moins) pour prioriser le développement. Ils doivent également comprendre l’impact des changements d’API, comme les points de terminaison obsolètes et les nouvelles versions d’API, sur les clients.
Les chefs de produit API examinent une gamme de mesures, mais les deux plus courantes sont la croissance de l’utilisation des API et les consommateurs d’API uniques.
Croissance de l’utilisation des API
Les responsables de produits API doivent mesurer l’adoption des API, et ils le font en examinant la croissance de l’utilisation des API. Ils mesurent l’utilisation de l’API sur de longues périodes, comme des semaines ou des mois, pour découvrir les principales tendances de croissance.
Consommateurs d’API uniques
Parfois, une augmentation de l’utilisation de l’API se produit en raison d’un compte client unique au lieu d’une croissance d’utilisateurs unique. Les chefs de produit API doivent mesurer le nombre de consommateurs uniques mensuels ou quotidiens de leurs API. Ils doivent également surveiller ces utilisateurs quotidiennement ou mensuellement pour voir s’ils restent actifs. L’examen des utilisateurs actifs mensuels ou quotidiens (MAU/DAU) peut vous indiquer si l’utilisation accrue de l’API provient de nouveaux clients, de clients existants ou des deux.
Les autres métriques que les responsables de produits d’API examinent incluent :
- Quand, comment et combien de temps les développeurs utilisent-ils l’API ?
- Quelles fonctionnalités d’API les développeurs utilisent-ils ou n’utilisent-ils pas ?
- Quel type de commentaires les fonctionnalités spécifiques du produit reçoivent-elles ?
- Comment l’argent dépensé se compare-t-il à l’adoption globale du produit ?
Suivi des métriques DevEx
Bien que chacun des professionnels DevEx de votre équipe se soucie de choses différentes, ils ont tous besoin d’un outil qui les aidera à suivre et à mesurer efficacement les métriques pertinentes. Votre rôle actuel est-il axé sur DevEx ? Ensuite, vous avez besoin d’un outil d’analyse d’API efficace qui suivra et mesurera les métriques qui vous intéressent et les métriques qui comptent pour d’autres rôles.
L’outil que vous choisissez doit fournir une visibilité sur toutes les API – par exemple, REST, RPC, SOAP, Hypermedia – et les API s’exécutant sur des langages de requête comme GraphQL. Il devrait inclure des plug-ins et des SDK afin que vous puissiez vous intégrer aux serveurs populaires sans avoir à écrire beaucoup de code personnalisé. Enfin, il devrait inclure des tableaux de bord prédéfinis pour suivre les mesures dont chaque équipe se soucie, de l’ingénierie et de la sécurité au succès des produits et des clients.