É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 une barre 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 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 personne ne demande de 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 choisi par l’équipe, et cette décision n’a généralement pas encore été prise lorsque le ticket arrive en phase d’affinage.
Ce qui se dit dans la salle
Backend : « Postgres peut le faire avec
tsvector. »PM : « Faut-il quand même harmoniser les fautes de frappe ? 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 une solution hébergée (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 pic de travail, et non un projet à part entière. Évaluez l’ampleur de ce pic et réévaluez le coût de développement une fois qu’un responsable aura été désigné pour ce projet.
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 présentant la même structure : une petite partie visible qui cache une longue traînée opérationnelle, ainsi que les autres exemples d’estimation déjà traités. Vous pouvez également lancer une session gratuite de « planning poker » dès lors qu’un responsable a été désigné pour la question concernée.