Plantilla de especificación de producto: qué incluir, con un ejemplo
Beta privada. El acceso es por lista de espera y los planes de pago se abren cuando termine la beta. Apúntate a la lista de espera.
Una especificación de producto es útil cuando la gente encuentra con rapidez lo que necesita. Una plantilla lo hace fiable. A continuación se describen las secciones que necesitan la mayoría de los equipos y lo que corresponde a cada una, seguidas de un ejemplo práctico completo de una función ficticia.
Cabecera
Producto, responsable, estado y versión. El responsable es un rol o un equipo, como "Responsable de producto de facturación", de modo que la especificación siga apuntando a alguien cuando una persona cambia de puesto. El estado es uno de Borrador, En revisión o Aprobada.
Resumen
Dos o tres frases: qué se está construyendo y qué cambia para el usuario. Si alguien lee solo esto, debería seguir sabiendo de qué trata la especificación y si le afecta.
Problema
Qué está fallando hoy y para quién. Conviene describir la situación en la que se encuentra el usuario, con detalles concretos como la pantalla que usa y el paso en que falla. La solución no debe aparecer en esta sección.
Objetivos y fuera de alcance
Los objetivos describen cómo es el éxito, en términos que reconocería un usuario. El fuera de alcance indica lo que deliberadamente no se hará en esta especificación. Escribirlo pronto evita la mayoría de las discusiones de alcance más adelante.
Requisitos
Una tabla con un ID, un requisito por fila y una prioridad. Una escala habitual es Debe, Debería y Podría. Debe significa que la versión no se publica sin él. Debería significa que se incluye salvo que haya un motivo claro para no hacerlo. Podría significa que se incluye si el trabajo lo permite. Cada fila debería ser algo que quien prueba pueda marcar como superado o fallido.
Métricas de éxito
Medibles y con plazo. Una buena métrica tiene un objetivo, un periodo contado desde la publicación y una fuente identificada. Si no se puede medir, hay que indicar cómo se averiguará. "A los usuarios les gusta" no es una métrica.
Preguntas abiertas
Asuntos que hay que resolver antes o durante el desarrollo, cada uno con un responsable. Una lista visible es mejor que dudas ocultas.
Plan de lanzamiento
Cómo llega la función a los usuarios: uso interno, una beta limitada y disponibilidad general. Cada etapa necesita una condición para avanzar, escrita de forma que se pueda comprobar.
Ejemplo práctico: búsquedas guardadas
El siguiente ejemplo rellena la plantilla para una función ficticia. Tallybird, la aplicación de facturación, es inventada, y también lo son las cifras, los objetivos y los roles.
- Producto: aplicación de facturación Tallybird (ficticia)
- Función: Búsquedas guardadas
- Responsable: Responsable de producto, equipo de facturación
- Estado: En revisión
- Versión: 0.3
Resumen. Las búsquedas guardadas permiten a un usuario almacenar un conjunto de filtros de la lista de facturas con un nombre, como "Vencidas, Cliente Norte", y volver a abrirlo desde la barra lateral con un solo clic. Los resultados se consultan cada vez que se abre una búsqueda guardada, de modo que aparecen las facturas creadas después de guardarla. Cada usuario puede conservar hasta 20 búsquedas guardadas.
Problema. Los usuarios que revisan cada semana las facturas vencidas vuelven a montar los mismos tres filtros (estado, cliente e intervalo de fechas) cada vez. La lista de facturas no recuerda nada de eso. Un usuario que omite un filtro ve otra lista sin darse cuenta.
Objetivos.
- Un usuario puede guardar los filtros actuales de la lista de facturas y volver a abrirlos después desde la barra lateral.
- Una búsqueda guardada muestra siempre las facturas actuales, no una instantánea del día en que se guardó.
Fuera de alcance.
- Compartir una búsqueda guardada con otros usuarios. Esta especificación cubre solo búsquedas personales.
- Búsquedas guardadas para informes, clientes o pagos.
- Resúmenes programados por correo electrónico de una búsqueda guardada.
- Cualquier cambio en el funcionamiento de los propios filtros de facturas.
Requisitos. Cada fila es una decisión.
| ID | Requisito | Prioridad |
|---|---|---|
| SRCH-1 | Un usuario puede guardar los filtros actuales de la lista de facturas con un nombre de 1 a 40 caracteres. | Debe |
| SRCH-2 | Un usuario puede abrir cualquier búsqueda guardada desde la barra lateral con un solo clic, y la lista de facturas muestra aplicados sus filtros guardados. | Debe |
| SRCH-3 | Los resultados de una búsqueda guardada se consultan al abrirla, de modo que una factura creada después de guardarla aparece en los resultados. | Debe |
| SRCH-4 | Un usuario puede renombrar o eliminar sus propias búsquedas guardadas. Al eliminar, se pide confirmación en un cuadro de diálogo con un botón Eliminar. | Debe |
| SRCH-5 | Un usuario puede conservar hasta 20 búsquedas guardadas. Al intentar guardar una búsqueda número 21, aparece el mensaje "Ya hay 20 búsquedas guardadas. Para guardar otra, hay que eliminar una." y no se guarda nada. | Debe |
| SRCH-6 | Una búsqueda guardada solo es visible para el usuario que la creó. Una petición de la búsqueda guardada de otro usuario devuelve una respuesta 404. | Debe |
| SRCH-7 | Un usuario puede fijar hasta 3 búsquedas guardadas para que aparezcan por encima de las demás en la barra lateral. Al intentar fijar una cuarta, aparece un mensaje y no se fija. | Debería |
| SRCH-8 | Si una búsqueda guardada filtra por un cliente archivado, la búsqueda sigue abriéndose, muestra un aviso con el nombre del cliente archivado y aplica sus demás filtros. | Podría |
Métricas de éxito.
- En las 8 semanas siguientes a la disponibilidad general, al menos el 30% de los usuarios que ven la lista de facturas en una semana determinada también abren una búsqueda guardada esa semana. Fuente: recuento semanal del evento de analítica saved_search_opened, dividido entre los usuarios semanales que ven la lista de facturas.
- En las 12 semanas siguientes a la disponibilidad general, la etiqueta de la mesa de ayuda "repeat filter" aparece en 10 tickets o menos al mes, frente a 40 en el mes anterior a la publicación. Fuente: la exportación mensual de la mesa de ayuda.
- Menos del 0,5% de las aperturas de búsquedas guardadas devuelve un error de servidor en las 4 semanas posteriores a la disponibilidad general. Fuente: el registro de errores de servidor, filtrado por el endpoint de búsquedas guardadas.
Preguntas abiertas.
- ¿Deberían aparecer las facturas archivadas en los resultados de búsquedas guardadas por defecto? Responsable: responsable de facturación.
- ¿Es 20 el límite adecuado para las búsquedas guardadas, o las cuentas grandes necesitan más? Responsable: responsable de producto, tras revisar los tickets de soporte de la beta.
- ¿La barra lateral necesita un cuadro de búsqueda cuando un usuario tiene más de 10 búsquedas guardadas? Responsable: responsable de diseño.
- ¿Debería el evento saved_search_opened registrar también cuántos filtros se aplicaron? Responsable: ingeniero de datos.
Plan de lanzamiento.
- Uso interno. El equipo usa las búsquedas guardadas en su propia cuenta de prueba durante dos semanas. Se avanza cuando ningún error abierto está calificado como Crítico y cada requisito Debe supera el guion de pruebas.
- Beta limitada. Hasta 15 cuentas de clientes activan la función mediante un feature flag. Se avanza tras 4 semanas sin informes de facturas que falten en los resultados y con una tasa de errores inferior al 0,5%.
- Disponibilidad general. Todas las cuentas pueden usar las búsquedas guardadas. El artículo de ayuda está listo antes del cambio.
Vago frente a verificable
Un requisito es verificable cuando quien prueba puede ejecutar una comprobación y obtener un resultado claro de superado o fallido.
| Requisito vago | Reescritura verificable |
|---|---|
| Las búsquedas guardadas deberían cargarse con rapidez. | Los primeros 50 resultados aparecen en menos de 2 segundos en el percentil 95, en una cuenta con 10.000 facturas, medido en 20 ejecuciones en la cuenta de prueba de staging. |
| Los usuarios deberían poder gestionar sus búsquedas. | Un usuario puede renombrar o eliminar cualquier búsqueda guardada de su propiedad desde el menú de la barra lateral en 2 clics o menos, y una búsqueda eliminada desaparece tras recargar la página. |
| Las etiquetas de los filtros deberían ser fáciles de entender. | Cada filtro aplicado aparece como una etiqueta con la forma "Campo: valor", como "Estado: Vencida". Quien prueba puede hacer coincidir cada etiqueta con un nombre de campo de la lista de filtros de la especificación. |
| Los datos de otros usuarios deberían permanecer privados. | Una petición de una búsqueda guardada que pertenece a otro usuario devuelve una respuesta 404, comprobada mediante una prueba automatizada en cada endpoint de búsquedas guardadas. |
Cuánta plantilla usar
La plantilla debe ajustarse al tamaño del cambio.
- Cambio pequeño, como una etiqueta, un valor por defecto o una corrección de texto: una cabecera, un resumen y una fila de requisitos. Se omiten las métricas, las preguntas abiertas y el plan de lanzamiento.
- Cambio mediano, como una nueva opción en una pantalla existente: todas las secciones, pero breves.
- Función grande, como una nueva área del producto o un cambio en los datos almacenados: todas las secciones completas, con una fuente para cada métrica y una condición en cada etapa del lanzamiento.
Hay partes que nunca se omiten, sea cual sea el tamaño: el responsable y la versión en la cabecera, el fuera de alcance, una prioridad en cada requisito y un responsable en cada pregunta abierta. Son las partes que quienes revisan preguntan primero.
La hoja de ejemplo de especificación de producto SaaS de la página de inicio sigue esta estructura con una función ficticia llamada "Posponer y recordatorios". En Wordspecs, las mismas secciones forman una plantilla, de modo que cada especificación que escribe el equipo tiene las secciones en el mismo orden.
Relacionado: guardar las propias plantillas de hojas de especificaciones.