«Añadir una barra de búsqueda» resulta ser «elegir un motor de búsqueda, crear un modelo de relevancia y ser el propietario del índice para siempre».

La búsqueda presenta dos aspectos que el ticket no menciona en ningún momento. El primero es la relevancia: ¿qué hace que un resultado sea mejor que otro y quién lo decide? El segundo es de carácter operativo: ¿dónde se almacena el índice, cómo se mantiene sincronizado con la fuente de datos de referencia y qué ocurre cuando se desfasada? «Añadir búsqueda» implica un control de la interfaz de usuario. El trabajo consiste en la clasificación y el índice.

Un equipo que ya haya implementado un sistema de búsqueda sabe que la respuesta rara vez es la misma dos veces. La búsqueda de texto completo de Postgres funciona bien hasta que alguien necesita tolerancia a los errores tipográficos. Elasticsearch es rápido hasta que tiene que pagar por su uso los fines de semana. Algolia resulta sencillo hasta que se necesita una clasificación personalizada. La estimación depende de qué compromiso adopte el equipo, y esa decisión normalmente aún no se ha tomado cuando el ticket llega a la fase de refinamiento.

Lo que se dice en la sala

Backend: «Postgres puede hacer esto con tsvector.»

PM: «¿Deberían coincidir también los errores ortográficos? ¿Y los plurales?»

Frontend: «¿Vamos a implementar la función de autocompletado o simplemente se enviarán los datos y luego aparecerán los resultados?»

SRE: «¿Cómo mantenemos el índice sincronizado? ¿Mediante disparadores? ¿Mediante una tarea? ¿Mediante un flujo?»

Titular: «¿Quién tiene la última palabra cuando alguien se queja de que la respuesta correcta está en la segunda página?»

Preguntas que conviene plantearse antes de votar

  • ¿De qué corpus se trata?: ¿cuántos documentos hay y con qué frecuencia cambian?
  • ¿FTS de Postgres, un servicio de búsqueda específico o un servicio alojado (Algolia, Typesense)?
  • Tolerancia a los errores ortográficos, derivación, sinónimos, plurales: ¿cuáles se tienen en cuenta?
  • ¿Facetas y filtros, o simplemente una única lista ordenada?
  • ¿Cómo se mantiene sincronizado el índice y cuál es el margen de antigüedad?
  • ¿Quién mantiene la relevancia a largo plazo y cómo la ajusta?

Si la elección de la infraestructura aún está por decidir, esa decisión constituye un «pico», no una «historia». Determine la magnitud de dicho pico y vuelva a calcular el coste de la implementación una vez que la relevancia tenga un responsable.

El cuadro de búsqueda corresponde a un día. La relevancia y el índice son las características, por lo que debe estimarlas.

Consulte la estimación de una integración de pagos para el mismo caso, una superficie pública reducida que oculta una larga cola operativa, así como los demás ejemplos de estimaciones ya realizados. O bien, inicie una sesión gratuita de «planning poker» cuando la cuestión de relevancia cuente con un responsable.