Ejemplo ilustrativo con datos ficticios
Cómo se ve una fase definida y comprobada
Una empresa recibe altas y cambios de datos de sus proveedores por un portal. El formulario ya existe y llega la información, pero la revisión sigue resolviéndose por correo.
Falta el recorrido: quién revisa, cómo se devuelve con observaciones, qué cambia al corregir y quién aprueba.
Pruébalo
Pruébalo antes de que te lo expliquen
Elige un rol y opera sobre las solicitudes. Cuando una acción no está permitida, el motivo aparece escrito: ese motivo es la regla que se acordó con el negocio.
Ve 3 de 3 solicitudes.
Solicitudes visibles 3 de 3
PRV-1044
Cambio de cuenta bancaria — Insumos Norte
- Proveedor
- Insumos Norte
- Adjuntos
- Carta del representante
- Envíos
- 1
Observada
Volvió al proveedor con un motivo escrito. El proveedor la corrige y la reenvía.
Observación: La carta no está firmada por el representante legal registrado.
Acciones
- Tomar para revisar: Ya no está enviada: está observada.
- Devolver con observación: Una solicitud se observa mientras está en revisión.
- Corregir y reenviar: La corrige el proveedor que la envió, no un rol interno.
- Enviar otra vez el mismo formulario: Reenviar el formulario es una acción del proveedor que lo envió.
- Aprobar: Aprobar está reservado al jefe de compras. El analista revisa, no decide.
Historial de la solicitud
- 11 mar, 16:45EnviadaProveedor — Insumos Norte
- 12 mar, 08:20Tomada para revisiónAnalista de compras
- 12 mar, 08:41Devuelta con observaciónAnalista de compras«La carta no está firmada por el representante legal registrado.»
Qué se acordó
Qué se acordó antes de implementar
Ninguna de estas reglas menciona una pantalla: son decisiones del negocio, y por eso se cierran antes de escribir código. Aquí van las tres que más se discuten; las otras dos están en el detalle técnico.
- Regla 1 Cada proveedor consulta únicamente sus propias solicitudes.
- Cómo se comprueba Comparar lo que ven dos proveedores del ejemplo: cada uno ve las suyas y ninguna del otro.
- Regla 2 Solo el rol autorizado puede aprobar.
- Cómo se comprueba Revisar el comportamiento para cada rol. El analista revisa y observa; aprobar no está disponible para él.
- Regla 3 La decisión debe poder revisarse después.
- Cómo se comprueba Consultar el historial: estado, fecha, rol responsable y la observación con la que se devolvió.
Comprobaciones de este ejemplo.
Al cerrar la fase
Qué quedaría al entregar una fase equivalente
-
Instrucciones de continuidad
¿Puede seguir otro equipo desde aquí?
Sin ella La solución queda atada a quien la escribió.
-
Versión identificada
¿Sobre qué exactamente se validó?
Sin ella No se sabe a qué punto volver si algo falla.
-
Pruebas de aceptación
¿Cómo compruebo que cumple lo acordado?
Sin ella «Terminado» pasa a ser una opinión.
-
Funcionalidad
¿Qué puede hacer hoy un usuario que ayer no podía?
Sin ella No hay entrega, hay una demostración.
-
Reglas acordadas
¿Qué debe pasar en cada etapa, y qué si no pasa?
Sin ella Todo lo de arriba se construye sobre una suposición.
Las condiciones de propiedad, accesos y continuidad se definen antes de contratar: están en cómo trabajamos. Qué modalidad corresponde a una fase como esta, en implementación por fases.
Ver el detalle técnicoLas otras dos reglas que también se acordaron, la matriz de permisos, la comprobación que corre en el servidor, el recorrido completo de una solicitud y el historial de un caso.
Detalle técnico
Corregir y reenviar nunca abren una solicitud nueva.
- Regla del negocio Una solicitud observada puede corregirse.
- Cómo se comprueba Editarla y reenviarla: vuelve a revisión conservando su historial y su identificador.
- Regla del negocio Repetir el envío no debe crear un duplicado.
- Cómo se comprueba Ejecutar la acción de nuevo y comprobar el registro: el identificador se mantiene, sube el contador de envíos y la lista no crece.
Permisos
Quién puede hacer qué
Esta es la tabla que se acuerda antes de escribir código. Cada casilla es una decisión del negocio, no una opción técnica.
| Rol | Ver todas | Tomar para revisar | Devolver con observación | Corregir y reenviar | Aprobar |
|---|---|---|---|---|---|
| ProveedorSolo sobre las solicitudes que envió. | No: Ver todas | No: Tomar para revisar | No: Devolver con observación | Sí: Corregir y reenviar | No: Aprobar |
| Analista de comprasRevisa y observa; no decide. | Sí: Ver todas | Sí: Tomar para revisar | Sí: Devolver con observación | No: Corregir y reenviar | No: Aprobar |
| Jefe de comprasDecide sobre las que están en revisión. | Sí: Ver todas | No: Tomar para revisar | No: Devolver con observación | No: Corregir y reenviar | Sí: Aprobar |
- Lo que ve el usuario
- La acción no está disponible para su rol, y el motivo está escrito.Evita el error honesto y explica la regla en el momento en que importa.
- Lo que se comprueba al implementar
- El servidor rechaza una aprobación que llega de un rol no autorizado, aunque la petición no haya pasado por la interfaz.Es la comprobación que sostiene la regla. La de arriba, sola, no la sostiene.
Esta demostración corre en el navegador y muestra el primer nivel. El segundo es parte de lo que se implementa y de lo que se prueba en la entrega.
Lectura estática
El recorrido, en texto
La misma información que recorre la interacción, para leerla sin ejecutarla.
Enviada
Proveedor
Entra a la cola. Todavía no la mira nadie.
En revisión
Analista de compras
Alguien la tiene a su cargo y comprueba el respaldo.
Aprobada
Jefe de compras
Decisión final, con autor y fecha.
Observada
Analista de compras → Proveedor
Vuelve con un motivo escrito.
Reenviar no crea un expediente nuevo: sube el contador de envíos y la lista sigue igual.
La rama es lo que casi nunca se especifica a tiempo: qué pasa cuando la solicitud no sigue el camino esperado.
- Enviada
- El proveedor la envió. Está a la espera de que alguien la tome para revisar.
- En revisión
- Un analista la tiene. Puede devolverla con observaciones o dejarla lista para aprobar.
- Observada
- Volvió al proveedor con un motivo escrito. El proveedor la corrige y la reenvía.
- Aprobada
- Tiene decisión final. Queda registrado quién aprobó, cuándo y sobre qué versión.
El historial que queda
Así queda registrada PRV-1044 después de observarse, corregirse y aprobarse.
- 11 mar, 16:45 Enviada — Proveedor, Insumos Norte
- 12 mar, 08:20 Tomada para revisión — Analista de compras
- 12 mar, 08:41 Devuelta con observación — Analista de compras «La carta no está firmada por el representante legal registrado.»
- 12 mar, 14:05 Corregida y reenviada (envío 2 de la misma solicitud) — Proveedor, Insumos Norte
- 12 mar, 15:03 Aprobada — Jefe de compras
Cinco movimientos, un solo expediente. El reenvío quedó registrado como envío 2 y no como uno nuevo.
¿Tienes un recorrido a medio cerrar?
Cuéntanos qué existe hoy y qué parte falta definir o implementar.