Empieza con una acción y una persona responsable
Escribe quién necesita hacer qué y para qué. “El responsable de almacén registra una entrada para que la existencia disponible refleje lo recibido” contiene un actor, una acción y un propósito. Es un mejor punto de partida que “módulo de almacén avanzado”.
Después identifica el inicio y el final del recorrido. ¿La entrada llega desde una orden de compra? ¿Necesita aprobación? ¿Cuándo afecta el saldo? Estas preguntas hacen visible el trabajo que una etiqueta general oculta.
Define datos y estados con ejemplos
Lista los campos necesarios y cuáles son obligatorios. Define formatos, unidades y relaciones. Un importe necesita moneda; una cantidad necesita unidad; una fecha puede necesitar zona horaria. Los nombres de campos no bastan para expresar estas reglas.
Los estados deben tener significado compartido. “Pendiente” puede significar información incompleta, espera de aprobación o espera de despacho. Si el negocio usa la misma palabra para situaciones distintas, el sistema necesita distinguirlas o documentar una regla inequívoca.
Borrador, enviado a revisión, observado, aprobado y cerrado. Es un recorrido ilustrativo: utiliza solo los estados que tu proceso necesite y define quién puede cambiar cada uno.
Incluye las excepciones que realmente ocurren
Describe qué pasa si falta información, el dato ya existe, el usuario no tiene permiso o un servicio externo no responde. No necesitas anticipar todos los errores imaginables, pero sí los casos relevantes de tu operación.
Por ejemplo, una importación puede detectar códigos repetidos. Define si debe rechazar el archivo completo, importar registros válidos o solicitar corrección. Las tres opciones producen experiencias diferentes y requieren pruebas distintas.
Redacta un criterio de aceptación observable
Un criterio puede seguir esta estructura: dada una situación, cuando se realiza una acción, entonces debe ocurrir un resultado. Evita palabras que no se puedan verificar, como “perfecto”, “instantáneo” o “muy intuitivo”, sin un contexto de evaluación.
| Parte | Ejemplo |
|---|---|
| Situación | Existe una solicitud en estado borrador con los campos obligatorios completos. |
| Acción | Su responsable la envía a revisión. |
| Resultado | Cambia el estado, queda registrada la acción y el revisor autorizado puede consultarla. |
| Excepción | Si falta un campo obligatorio, el sistema explica cuál y conserva los datos ya ingresados. |
Este criterio permite a negocio, desarrollo y pruebas conversar sobre lo mismo. No impone una tecnología; define el comportamiento esperado.
Separa prioridad y cambio de alcance
Marca lo indispensable para operar, lo conveniente y lo que puede esperar. Una primera versión debería resolver un recorrido completo aunque tenga menos módulos. Entregar muchas pantallas incompletas no equivale a entregar más valor.
Cuando aparezca una nueva idea, compárala con los criterios acordados. Puede ser una corrección de un comportamiento comprometido o una ampliación. Documentar esa diferencia evita discusiones basadas únicamente en expectativas.
No elimines una función esencial solo para cumplir una fecha sin revisar el objetivo. Tampoco agregues todas las ideas a la primera versión por miedo a olvidarlas: consérvalas en una lista de evolución.
Prepara una muestra antes de la reunión
Lleva un proceso, un formulario anonimizado y un reporte esperado. Añade una excepción frecuente y quién puede aprobar decisiones. Estos materiales permiten una conversación más precisa que una lista extensa de nombres de módulos.
Al terminar, debería existir un resumen de lo entendido, preguntas pendientes y criterios de aceptación iniciales. La propuesta puede entonces señalar qué está incluido y qué depende de información adicional.
Utiliza el formulario de proyecto para ordenar el contexto. Nuestro enfoque de desarrollo a medida parte de definir procesos y validar entregables por etapas.