É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 : choisir un événement, générer un modèle, l’envoyer. La deuxième l’est tout autant. La dixième, c’est lorsque l’équipe se rend compte qu’elle développe un système de notifications depuis deux mois sans s’en être rendu compte. Préférences, résumés, déduplication, plages horaires « ne pas déranger », règles de remplacement par canal — autant d’éléments qui ne figuraient pas dans le ticket initial — deviennent tous incontournables dès qu’un utilisateur reçoit une notification à 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 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 ne lui est pas parvenue ?
- Modèles : qui rédige le contenu, qui s’occupe de sa localisation, et où est-il stocké ?
Le chiffre exact correspond à « la table des trente », et non à « la première rangée ». Si le public ne peut voir que la première rangée, l’histoire n’est pas encore prête — split le seul canal dont vous avez besoin pour l’instant, issu du système dans lequel vous évoluerez.
Évaluez le système dans son ensemble, et non pas le courriel isolément. La première notification ne représente qu’une journée ; la trentième correspond au projet tout entier.
Tout comme l’estimation d’une intégration de paiement, la surface publique ne reflète pas fidèlement le travail requis. Consultez les autres exemples d’estimations concrètes, ou lancez une session gratuite de Planning Poker une fois le tableau esquissé.