Évaluation d'une fonctionnalité de recherche
Comment évaluer une fonctionnalité de recherche : pertinence, classement, facettes et responsable de l'index. Les questions qui transforment la simple idée d'« ajouter un champ de recherche » en une véritable évaluation.
« Ajouter une barre de recherche » revient en fait à « choisir un moteur de recherche, élaborer un modèle de pertinence et détenir l’index pour toujours ».
La recherche comporte deux aspects que le ticket ne mentionne jamais. Le premier concerne la pertinence : qu’est-ce qui rend un résultat meilleur qu’un autre, et qui en décide ? Le second est d’ordre opérationnel : où se trouve l’index, comment reste-t-il synchronisé avec la source de vérité, et que se passe-t-il lorsqu’il prend du retard ? « Ajouter une recherche » implique un élément de contrôle de l’interface utilisateur. Le travail porte sur le classement et l’index.
Une équipe ayant déjà mis en production un moteur de recherche sait que la réponse est rarement la même deux fois. La recherche en texte intégral de Postgres convient tant que l’on n’a pas besoin d’une tolérance aux fautes de frappe. Elasticsearch est rapide, jusqu’à ce que vous deviez payer pour son utilisation le week-end. Algolia est simple à utiliser, jusqu’à ce que vous ayez besoin d’un classement personnalisé. L’estimation dépend du compromis que l’équipe choisit de faire, et cette décision n’a généralement pas encore été prise lorsque le ticket arrive en phase de précision.
Ce qui se dit dans la salle
Backend : « Postgres peut le faire avec
tsvector. »PM : « Les fautes de frappe doivent-elles quand même correspondre ? Et les pluriels ? »
Interface utilisateur : « Allons-nous mettre en place une fonction de saisie semi-automatique, ou simplement afficher les résultats après validation ? »
SRE : « Comment assurons-nous la synchronisation de l’index ? Par des déclencheurs ? Par une tâche ? Par un flux ? »
Chapeau : « À qui revient la pertinence lorsqu’une personne se plaint que la bonne réponse se trouve à la deuxième page ? »
Questions qu’il convient de se poser avant de voter
- De quel corpus s’agit-il : combien de documents contient-il, et à quelle fréquence sont-ils mis à jour ?
- Postgres FTS, un service de recherche dédié ou hébergé (Algolia, Typesense) ?
- Tolérance aux fautes de frappe, dérivation, synonymes, pluriels : lesquels sont pris en compte ?
- Facettes et filtres, ou simplement une seule liste classée ?
- Comment l’index reste-t-il synchronisé, et quel est le « budget de désactualisation » ?
- Qui détient la pertinence à long terme, et comment la peaufine-t-il ?
Si le choix de l’infrastructure n’est pas encore arrêté, cette décision constitue un spike, et non une feature. Définissez l’ampleur du spike et réévaluez l’effort de développement une fois qu’un responsable aura été désigné pour la feature.
Le champ de recherche correspond à une journée. La pertinence et l’index constituent les caractéristiques ; veuillez donc les évaluer.
Consultez l’estimation d’une intégration de paiement pour découvrir la même structure : une petite surface visible qui cache une longue traînée opérationnelle, ainsi que les autres exemples d’estimations concrètes. Ou lancez une session gratuite de Planning Poker lorsque la question de pertinence a été attribuée à un responsable.