Votre produit est-il prêt pour le succès ?

Vous n’aurez jamais une deuxième chance de faire une première impression. Alors, comment s’assurer qu’il est bon ? Cette question est constamment à l’esprit des responsables de publication et des propriétaires de produits, car ils savent qu’une fois qu’un produit est lancé dans le monde, tous les paris sont ouverts.

Bien que la sortie d’un produit ou d’une nouvelle fonctionnalité puisse être tentante dès qu’elle est fonctionnelle, les utilisateurs attendent (et méritent) de la qualité et du polissage. Par conséquent, avant même d’atteindre l’étape du test bêta, beaucoup de travail non technique doit être fait : la documentation doit être écrite, la sécurité doit être évaluée et les objectifs commerciaux doivent être établis. Voici certaines choses que nous avons apprises sur les versions logicielles de Semaphore.

Étapes du projet

De l’idée à la sortie, nous pouvons décomposer un projet logiciel en trois étapes environ :

1. Conception et développement

Comprend tout, de l’idée au MVP ou à la fonctionnalité de travail. Nous avons discuté des modèles de conception dans d’autres articles de blog, de sorte que je ne passerai pas trop de temps là-dessus maintenant. Cependant, les pratiques ne manquent pas pour nous aider à découvrir de bonnes conceptions, comme la rédaction de critères d’acceptation et le suivi des méthodologies de développement piloté par les tests, de développement piloté par le comportement ou de développement piloté par le domaine.

2. Aperçu technique

La lame tranchante du contrôle de la réalité. Nous invitons quelques utilisateurs à obtenir leurs premiers commentaires afin que nous puissions apporter des améliorations et réduire l’incertitude lors de la sortie.

3. Relâchez

Également connu sous le nom de disponibilité générale (GA). Dans cette dernière étape, nous mettons la version à la disposition de tous les utilisateurs.

Les étapes sont séparées par des points de contrôle. Nous avons deux types de définitions de Ready et de Definition of Done :

Définition de Ready (DoR) : ces tâches sont requises avant que les utilisateurs puissent accéder au système ou faire l’expérience de la fonctionnalité.
Definition of Done (DoD) : consiste en toutes les tâches de suivi clôturant une étape, comme recueillir les commentaires des utilisateurs, terminer les tickets en suspens ou faire une rétrospective.

Nous ne pouvons pas entrer dans une nouvelle étape de projet ou la considérer comme terminée tant que toutes les tâches du DoR et du DoD ne sont pas cochées.

Le point de contrôle prêt (DoR) dicte si les utilisateurs peuvent être autorisés dans notre système. Ainsi, l’aperçu technique ne peut commencer qu’une fois que nous rencontrons le DoR. Cela ne se termine pas tant que nous n’avons pas terminé toutes les tâches du DoD. La même chose se produit lors de la version GA.

L’aperçu technique

L’avant-première technique est l’occasion d’obtenir les commentaires des utilisateurs avant la version finale. Avant d’évaluer si une fonctionnalité ou un produit fonctionne, nous devons les intégrer dans le mix. Au cours de la phase de prévisualisation, nous déployons la dernière version en production et utilisons des indicateurs de fonctionnalité pour contrôler qui peut voir la fonctionnalité prévisualisée.

Nous pouvons déployer la dernière version en production et utiliser des indicateurs de fonctionnalité pour sélectionner les utilisateurs qui accèdent à la fonctionnalité prévisualisée.

La plupart des utilisateurs comprennent qu’ils peuvent trouver des problèmes et seront heureux de nous aider à les résoudre. Par conséquent, nous pouvons lancer l’aperçu technique même si l’application n’est pas parfaite (indice : elle ne le sera jamais).

Cela étant dit, nous devons prendre certaines précautions avant qu’un utilisateur ne soit autorisé à accéder à nos systèmes. C’est là que le DoR pour la version technique entre en scène.

Définition de Prêt pour l’Aperçu Technique

Disons que nous expédions une nouvelle fonctionnalité dans notre produit. Les premiers retours d’utilisateurs réels sont essentiels à son succès. Nous pouvons contacter les utilisateurs susceptibles de bénéficier de la fonctionnalité ou intéressés à la tester.

Comment savons-nous quand nous pouvons inviter les utilisateurs à le consulter ? Tout d’abord, nous définissons une liste de tâches et de conditions qui doivent se produire avant de pouvoir définir notre système comme prêt. Ce sont des tâches qui doivent être accomplies pour chaque fonctionnalité avant qu’elle puisse être montrée aux utilisateurs :

Indicateurs de performance: chaque nouveau composant expédié doit être suivi et ajouté au tableau de bord de surveillance pour observer ses performances et sa stabilité. Semaphore, par exemple, surveille les quatre signaux d’or (latence, trafic, erreurs et saturation).
Métriques d’utilisation: nous devons nous assurer que les nouvelles fonctionnalités sont utilisées et comment.
Journaux d’audit: l’envoi en production de tout ce qui n’est pas couvert par les journaux d’audit est un problème de sécurité. Chaque événement doit être enregistré pour une conformité totale à l’audit.
Évaluation de sécurité: nous devons nous assurer que les nouveaux composants ne présentent pas de vulnérabilités critiques. Ceci est important pour deux raisons. Premièrement, pour protéger les utilisateurs contre les exploits de sécurité. Et deuxièmement, pour se conformer à toutes les normes de sécurité suivies par l’entreprise, telles que la norme ISO 27001.
Déploiement en production: la version doit être déployée en production. Il peut s’agir de l’environnement de production principal ou d’une copie intermédiaire aussi proche que possible de la réalité.
Documentation préliminaire: les utilisateurs auront besoin d’instructions sur ce qui a changé et comment l’utiliser. Il n’a pas encore besoin d’être une documentation complète.

La liste peut être étendue pour inclure plus d’éléments selon les besoins.

Une fois que nous avons défini et rempli notre DoR, nous sommes prêts à commencer l’aperçu technique. Après cela, la fonctionnalité passe à l’état « en cours de révision », et nous pouvons commencer le processus de collecte de commentaires qui peut durer des semaines ou des mois.

Note: Au lieu d’aperçus techniques, l’équipe d’ingénierie de Semaphore avait l’habitude d’avoir deux types de versions bêta : publiques et privées, qui avaient des processus et des exigences différents. Avoir deux ensembles de DoR et de DoD similaires mais pas tout à fait identiques a fini par être inutilement compliqué. Ainsi, les processus ont été rationalisés en un seul. Les utilisateurs sont invités à l’aperçu technique en fonction des besoins et de l’intérêt pour une fonctionnalité donnée.

Définition de terminé pour l’aperçu technique

L’aperçu technique se termine lorsque nous avons recueilli suffisamment de commentaires et affiné le système au point que nous le considérons prêt à être publié.

Avant de pouvoir fermer l’aperçu technique, il y a quelques tâches à accomplir, qui dépendront du DoD pour notre projet.

Les éléments du bucket DoD varient, car ils changent d’une équipe à l’autre ou d’une entreprise à l’autre. Pour Sémaphore, la liste comprend :

Recueillir des commentaires: tout l’intérêt de cet exercice est de recueillir des commentaires exploitables de la part des utilisateurs. Les commentaires nous permettent de mieux intégrer la voix du client dans le système. De plus, cela nous permet de trouver des bogues et d’améliorer la convivialité.
Ils nettoyaient toutes les tâches restantes: adressage et clôture des tickets en circulation. Assurez-vous que tous les problèmes et commentaires obtenus lors de l’aperçu technique ont été résolus ou que des plans d’atténuation sont en cours.
Communiquer en interne: toutes les personnes impliquées dans le support de la production doivent être informées de tout problème rencontré lors de l’aperçu technique (et de leurs solutions).
Configuration des alertes: nous devons être conscients d’un problème de production dès qu’il se produit. Cela inclut la configuration des alertes Slack/Teams, la configuration des téléavertisseurs et la garantie que le personnel de garde est sur la même page.

Version de disponibilité générale

Le moment de vérité auquel nous nous sommes préparés si durement est proche. Les utilisateurs ne seront pas aussi indulgents lors d’une version de disponibilité générale (GA) que lors d’un aperçu technologique. Des problèmes peuvent perturber leur travail. C’est pourquoi nous nous sommes donné tant de mal pour minimiser les risques de problèmes dans la version. Cependant, aucune quantité de préparation ne garantira une sortie réussie. Nous devons donc nous préparer aux problèmes qui pourraient survenir.

Définition de prêt pour la publication

Le logiciel est peut-être prêt à être publié, mais cela ne signifie pas nous sont préparés pour la sortie. Nous devons donc définir et remplir la liste de contrôle DoR de la version GA avant de passer à l’étape suivante.

Comme toujours, chaque projet a des besoins différents. Cependant, à titre indicatif, voici quelques-unes des tâches considérées comme nécessaires chez Semaphore :

Rédaction des documents publics: les documents publics doivent être mis à jour avec les détails de la nouvelle fonctionnalité. De plus, il devrait être clair quels plans ont un soutien pour cela.
Se perfectionner en interne: tout le monde dans l’entreprise, en particulier le personnel d’assistance et en contact avec les clients, doit être informé des changements à venir.
Définition des KPI: en fonction de l’utilisation de l’aperçu technique, nous pouvons définir des objectifs commerciaux et des indicateurs de performance clés (KPI) pour la fonctionnalité en question. Cela peut inclure de nouveaux revenus attendus, des mesures d’utilisation ou l’adoption de fonctionnalités.
Rédaction d’un journal des modifications: le journal des modifications doit inclure tout ce qui a changé depuis la dernière version.
Configuration des alertes: nous devons être conscients de tout problème avec les nouvelles fonctionnalités livrées dès qu’il se produit. Cela inclut les alertes Slack/Teams et les notifications par téléavertisseur pour le personnel de garde.
Planification d’une stratégie marketing: la stratégie marketing communique les changements et suscite l’intérêt des utilisateurs. Une bonne campagne peut attirer de nouveaux clients ou convertir des utilisateurs gratuits en utilisateurs payants.

Définition de Terminé pour GA

Avec un peu de chance, la sortie s’est bien déroulée et les utilisateurs sont satisfaits des nouvelles fonctionnalités. Et maintenant? Pouvons-nous passer au projet suivant ? Pas encore. Ce projet n’est pas terminé tant que tous les éléments du DoD ne sont pas cochés.

Ce qu’il reste généralement à ce stade, c’est faire du travail de nettoyage et ranger les détails :

Nettoyez les billets restants: après l’envoi des nouvelles fonctionnalités à GA, il peut rester des tâches de faible priorité. Ils doivent être traités ou programmés pour être travaillés plus tard.
Prise en charge de la CLI et de l’API: fournir un support à la nouvelle fonctionnalité via des API publiques ou les outils CLI car cela permet aux utilisateurs d’accéder plus facilement aux ressources depuis le terminal et de les intégrer dans leurs outils personnalisés. Si cette prise en charge fait partie intégrante de la nouvelle fonctionnalité, nous pouvons déplacer cet élément vers la liste de contrôle DoR.
Faire la rétrospective du projet: La rétrospective est l’une des phases les plus critiques d’un projet. C’est un espace où l’équipe peut discuter de ce qui s’est bien passé et de ce qui peut être amélioré pour le prochain projet. En outre, cela permet à l’équipe d’identifier rapidement les pièges potentiels et de résoudre les zones de conflit.

Conclusion

C’est une erreur de penser que le codage est la partie la plus difficile du développement logiciel. Le véritable défi survient lorsque vous ouvrez les vannes et que les utilisateurs affluent. À moins que tout ne soit préparé, les problèmes peuvent aggraver et dépasser n’importe quelle équipe d’ingénierie. Une définition formelle de ce qui constitue être prêt et fait nous permet d’éviter de précipiter une version.

Merci d’avoir lu et bonne publication !