Cómo pedir una mejora de software sin dejar el alcance abierto

«Que el sistema mande un correo cuando haya un pedido»

La frase parece clara. Pero ¿a quién le llega el correo? ¿A cualquier pedido o solo a los de cierto valor? ¿Qué dice? ¿Qué pasa si el pedido se cancela? Cada pregunta sin responder es una decisión que tomará otra persona, y probablemente no como tú la habrías tomado.

Pedir bien una mejora no requiere saber programar. Requiere describir el problema y cómo sabrás que quedó resuelto.

Los siete elementos de un buen requerimiento

Problema antes que solución

«Necesito un botón para exportar a Excel» es una solución. El problema puede ser «cada viernes copio a mano los pedidos de la semana para el informe de gerencia». Al describir el problema, quien desarrolla puede proponer otra solución mejor, como un informe automático.

Escenarios y criterios de aceptación

Las historias de usuario ayudan a describir quién necesita algo y para qué. Los criterios de aceptación concretan cuándo está terminado. Un formato útil es «Dado… cuando… entonces…», que usa la sintaxis Gherkin:

Escribe al menos un escenario normal y uno de excepción: ¿qué pasa si el pedido se cancela o si falta un dato?

Restricciones y fuera de alcance

Las restricciones evitan sorpresas: «no se puede modificar el ERP», «debe funcionar en móvil». La sección fuera de alcance es la que más protege: escribir lo que no se incluye evita que el alcance crezca sin control.

Cambios

Si durante el trabajo aparece una necesidad nueva, regístrala como cambio: describe qué se agrega, su efecto en esfuerzo y fecha, y quién lo aprueba. No la mezcles en silencio con el requerimiento original.

Procedimiento

1. Escribe el problema con un ejemplo real reciente.
2. Identifica usuarios.
3. Describe dos o tres escenarios, incluyendo excepciones.
4. Lista reglas y restricciones.
5. Escribe criterios de aceptación verificables.
6. Declara qué queda fuera.
7. Revisa la ficha con quien desarrollará antes de empezar.

Ejemplo aplicado

Cómo usar la ficha descargable

1. Llena problema, usuarios y escenarios.
2. Completa reglas y aceptación con quien desarrolla.
3. Declara lo que queda fuera.
4. Registra cada cambio con su efecto y aprobación.

Criterios de un buen requerimiento

Ejemplo sintético completo

Ejemplo sintético. Una empresa ficticia pide «que el sistema mande un correo cuando haya un pedido». Al completar la ficha, el problema real aparece: los pedidos de clientes nuevos se quedan sin revisar porque nadie se entera a tiempo.

La ficha queda así. Usuarios: el jefe de cartera. Escenario normal: llega un pedido de un cliente sin historial y el jefe de cartera recibe un aviso con el nombre del cliente, el valor y el enlace al pedido. Excepción: si el jefe de cartera no lo revisa en cuatro horas hábiles, el aviso pasa a su suplente. Criterios de aceptación: el aviso llega en menos de cinco minutos en el 100 % de diez pedidos de prueba; los clientes con historial no generan aviso. Fuera de alcance: aprobar el pedido desde el correo y avisos por WhatsApp.

Cuando el área comercial pide agregar también los pedidos mayores a cierto valor, se registra como cambio, con efecto en plazo y aprobación del responsable. Ejemplo inventado.

Cómo revisar lo entregado

Revisa la mejora contra los criterios de aceptación, no contra lo que recordabas haber pedido. Prueba los escenarios normales y las excepciones con datos realistas, anota lo que no cumple con un ejemplo concreto y aprueba por escrito cuando todo cumpla.

Cómo saber si funcionó

• El proveedor puede estimar sin preguntas básicas.
• La entrega se aprueba contra criterios escritos.
• Los cambios quedan registrados con su efecto.

Plan para las primeras cuatro semanas

1. Semana 1: llena problema y escenarios.
2. Semana 2: revisa con quien desarrolla.
3. Semana 3: acuerda criterios y fuera de alcance.
4. Semana 4: aprueba la ficha y define el control de cambios.

Diagnóstico antes de empezar

• Toma la última mejora que pediste y revisa si tenía criterios de aceptación.
• Cuenta cuántas veces se rehízo.
• Revisa si quedó escrito qué no incluía.

Un segundo ejemplo, en contraste

Ejemplo sintético. Una empresa ficticia pide un informe nuevo describiendo solo el problema: «no sabemos qué clientes dejaron de comprar». El proveedor propone una alerta en lugar de un informe, más simple y útil. Al contrario del primer ejemplo, la mejor ficha dejó abierta la solución y cerró el problema. Ejemplo inventado.

Qué hacer cuando algo falla

• Si lo entregado no cumple, señala el criterio exacto que falla.
• Si aparece un escenario no previsto, regístralo como cambio.
• Si hay desacuerdo, vuelve a la ficha aprobada.

Cómo medirlo con tus propios datos

• Cuenta cuántas preguntas hizo el proveedor antes de estimar.
• Registra cuántas veces se rehízo la mejora.
• Anota cuántos cambios se pidieron después de aprobada la ficha.
• Mide el tiempo entre la entrega y la aprobación.

Compara estos datos entre una mejora pedida sin ficha y otra pedida con ficha. Si con la ficha hay menos rehechos y la aprobación es más rápida, el método funciona. Si los cambios posteriores siguen siendo muchos, los escenarios iniciales estaban incompletos: incluye a más usuarios en la próxima ficha.

Errores frecuentes

• Pedir una solución sin describir el problema.
• Criterios como «que funcione bien».
• Olvidar los casos de excepción.
• No declarar qué queda fuera.
• Agregar cambios sin registrarlos.

Checklist

• Problema descrito con ejemplo.
• Escenarios normales y de excepción.
• Criterios verificables.
• Fuera de alcance declarado.
• Cambios registrados.