Évaluation d'un système de notifications

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 « l’envoi d’un message Slack lorsque X se produit » sous-estime considérablement l’ampleur de la tâche, 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 ? Tenter à nouveau ? 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 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 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 ; vous devez donc split le seul canal dont vous avez besoin pour l’instant à partir du système dans lequel vous allez évoluer.

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 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 concrètes, ou lancez une session gratuite de Planning Poker une fois le tableau esquissé.