Skip to content
SP StackPractices
beginner

Plantilla de Solicitud de Feature

Plantilla estructurada de solicitud de features para ayudar equipos a evaluar, priorizar e implementar nuevas capacidades con valor de usuario claro y criterios de aceptación.

Temas: devops

Plantilla de Solicitud de Feature

Usa esta plantilla para proponer nuevas features de manera que ayude a equipos de producto e ingeniería a evaluar valor de usuario y esfuerzo de implementación.

Plantilla

# Solicitud de Feature

## Resumen
Descripción de una oración de la feature.

## Declaración del Problema
¿Qué problema resuelve? ¿Quién tiene este problema y con qué frecuencia?

## Solución Propuesta
Describe la feature. Incluye mockups, wireframes o diagramas de flujo si están disponibles.

## Criterios de Aceptación
- [ ] Criterio 1: comportamiento específico y testeable
- [ ] Criterio 2: comportamiento específico y testeable
- [ ] Criterio 3: comportamiento específico y testeable

## Valor para el Usuario
- **Usuarios objetivo:** [equipo interno / clientes / admins]
- **Frecuencia:** [diaria / semanal / mensual]
- **Nivel de dolor:** [bloqueante / molesto / nice-to-have]
- **Workaround:** [existe / ninguno]

## Prioridad
- [ ] Crítica — bloquea operación de negocio
- [ ] Alta — dolor significativo de usuario, sin workaround
- [ ] Media — mejora experiencia, workaround existe
- [ ] Baja — nice-to-have

## Contexto Adicional
- Link a solicitudes relacionadas o feedback de clientes
- Análisis competitivo
- Estimaciones o restricciones

Por Qué Funciona Esta Estructura

SecciónPropósito
Declaración del problemaEvita “solución en busca de problema”
Solución propuestaDa a ingenieros un punto de partida para diseño
Criterios de aceptaciónDefine “terminado” antes de empezar a codear
Valor de usuarioAyuda a producto a priorizar contra otras solicitudes

Consejos para Quienes Solicitan

  • Empieza con el problema, no la solución — el equipo puede encontrar una solución mejor
  • Incluye una cita de usuario — “Como [usuario], quiero [feature] para poder [beneficio]”
  • Define una feature por solicitud — los paquetes son difíciles de evaluar y trackear

Consejos para Reviewers

  • Rechaza solicitudes poco claras rápidamente — label “necesita-mas-info” y deadline de 48 horas
  • Estima antes de comprometerte — t-shirt sizing (S/M/L) es suficiente para triage
  • Link al roadmap — muestra dónde encaja (o no) en los objetivos trimestrales

Preguntas Frecuentes

¿Qué pasa si quien solicita propone una mala solución?

Agradece por identificar el problema, luego colabora en una solución mejor. El objetivo es resolver el dolor del usuario, no implementar su sugerencia exacta.

¿Cómo prevengo el feature bloat?

Requiere una sección de “valor de usuario” en cada solicitud. Si la respuesta es “estaría cool” o “el competidor X lo tiene”, resiste. Las features deben resolver dolor real y frecuente.

¿Las herramientas internas deberían usar la misma plantilla?

Sí, pero relaja la sección de “valor de usuario”. Las solicitudes internas necesitan “equipo solicitante” y “tiempo ahorrado por semana” en su lugar.