Évaluation d'un système de notifications
Comment évaluer un système de notification : canaux, préférences, déduplication et garanties de livraison. Pourquoi « envoyer un e-mail » se transforme insidieusement en un projet de six semaines.
Cette histoire, qui commence par un simple e-mail, se termine par le seul projet sur lequel l’équipe a travaillé pendant six semaines.
La première notification est simple : choisissez un événement, générez un modèle, envoyez-le. La deuxième l’est tout autant. La dixième, c’est lorsque l’équipe se rend compte qu’elle passe depuis deux mois à développer un système de notifications sans l’avoir admis. Préférences, résumés, déduplication, plages horaires « ne pas déranger », règles de remplacement par canal (aucun de ces éléments ne figurait dans le ticket initial) : tout cela devient incontournable dès qu’un utilisateur reçoit une alerte à 3 heures du matin.
Évaluez le système dans son ensemble, et non pas le simple e-mail. L’équipe qui vote en faveur de la proposition « envoyer un message Slack lorsque X se produit » sous-estime l’ampleur du projet d’un ordre de grandeur, car elle évalue une seule ligne d’un tableau qui en comptera finalement trente.
Ce qui se dit dans la salle
Backend : « L’envoi de l’e-mail correspond à une tâche d’une journée. »
PM : « Les utilisateurs peuvent-ils désactiver cette fonctionnalité ? »
Backend : « Par événement ou de manière globale ? »
Concepteur : « À quoi ressemble la page des préférences ? »
SRE : « Que faire si le service de messagerie est hors service ? Réessayer ? Mettre en file d’attente ? Abandonner ? »
Assistance : « Comment expliquer à un utilisateur pourquoi il n’a pas reçu l’e-mail ? »
Questions qu’il convient de se poser avant de voter
- Un seul canal pour l’instant, ou faut-il intégrer dès le départ les e-mails, les notifications push et Slack ?
- Préférences de l’utilisateur : option globale, par événement ou par chaîne ?
- Déduplication et résumés : faut-il les mettre en place dès maintenant ou « plus tard » ?
- Garanties de livraison : au moins une fois, au plus une fois, exactement une fois ?
- Historique des opérations : le service d’assistance peut-il expliquer à un utilisateur pourquoi une notification n’est pas parvenue ?
- Modèles : qui rédige le contenu, qui s’occupe de sa localisation, et où est-il stocké ?
Le chiffre réel correspond à « la table de trente », et non à « la première rangée ». Si la salle ne peut voir que la première rangée, le projet n’est pas encore au point ; il faut donc séparer le canal dont vous avez besoin dès maintenant du système vers lequel vous évoluerez.
C’est le système qu’il faut dimensionner, pas l’e-mail. La première notification concerne une journée ; la trentième concerne le projet.
Tout comme pour l’estimation d’une intégration de paiement, l’interface publique ne reflète pas la réalité du travail. Consultez les autres exemples d’estimations déjà réalisés, ou lancez une session gratuite de « planning poker » une fois le tableau esquissé.