El alcance de un primer módulo debe definir un proceso completo, las personas que lo usan, los datos que necesita y las condiciones que demostrarán que funciona. También debe aclarar qué queda fuera y quién lo operará. Con esas decisiones puedes comparar propuestas de desarrollo a medida y revisar avances con evidencia.
¿Qué proceso conviene resolver primero?
Elige un trabajo con un inicio y un resultado reconocibles. «Mejorar operaciones» es demasiado amplio. «Recibir una solicitud de compra, revisarla y comunicar su aprobación o rechazo» permite delimitar el recorrido.
Busca un proceso cuyo problema puedas observar y cuyo responsable pueda participar. Revisa qué ocurre hoy, dónde se acumulan pendientes y qué decisiones siguen tomando las personas. Si todavía hay desacuerdo sobre las reglas, documentarlo es parte del trabajo previo al desarrollo.
Para comparar el resultado, registra una referencia: tiempo transcurrido por solicitud, tiempo de trabajo activo, devoluciones por información incompleta o pendientes sin responsable. Elige los indicadores que importen en tu operación, sin convertir una expectativa de mejora en una promesa contractual sin sustento.
¿Cómo convertir una idea en requisitos verificables?
Describe quién necesita hacer qué y para qué. La guía de historias de usuario de GOV.UK propone identificar al usuario, su necesidad y el objetivo, y añadir resultados comprobables como criterios de aceptación.
En un ejemplo hipotético, una persona de compras necesita revisar solicitudes para decidir cuáles pueden continuar. A partir de ahí, define los estados permitidos, los campos obligatorios y quién puede cambiar cada estado. Pregunta también qué sucede cuando una solicitud vuelve a revisión o su responsable está ausente.
Evita requisitos como «debe ser intuitivo» sin una prueba asociada. Es más útil acordar que un usuario representativo pueda completar la tarea con sus permisos, localizar un rechazo y entender qué información debe corregir.
¿Qué excepciones deben entrar en el alcance?
Un módulo pequeño necesita un camino completo para los casos incluidos. Pide al equipo operativo ejemplos de solicitudes duplicadas, datos faltantes, cancelaciones, responsables ausentes y cambios después de una aprobación.
No todas las excepciones necesitan resolución automática. Algunas pueden terminar en una bandeja de revisión. Lo importante es definir quién recibe el caso, qué información conserva y cómo evita que quede olvidado.
Escribe las exclusiones con el mismo cuidado. Por ejemplo, el primer módulo puede registrar aprobaciones sin emitir órdenes en el ERP. Esa frontera permite validar el flujo antes de añadir otra integración y evita que cada revisión incorpore funciones nuevas por accidente.
¿Qué datos, accesos y dependencias hay que acordar?
Haz un inventario breve de los sistemas involucrados. Para cada dato, indica de dónde viene, quién puede modificarlo y dónde se consultará su versión vigente. Confirma si existen APIs, exportaciones o ambientes de prueba, y quién autoriza el acceso.
Incluye las condiciones que pueden cambiar el esfuerzo: documentación incompleta, limpieza de registros, licencias de terceros o permisos todavía pendientes. Una propuesta debería distinguir los hechos comprobados de los supuestos que requieren validación.
Define además qué información necesita cada perfil, qué acciones se registrarán y cómo se eliminarán los accesos que ya no sean necesarios. Usa datos de prueba adecuados; no incluyas credenciales ni información sensible en el documento de alcance.
¿Cómo se acepta la entrega?
Prepara la revisión antes de construir. Para el ejemplo de compras, una lista inicial podría ser:
Ajusta estos criterios al proyecto. Documenta quién valida, con qué ejemplos y qué defectos impiden aceptar el módulo. Conserva también las decisiones tomadas durante las demostraciones para evitar que los acuerdos dependan de la memoria de los asistentes.
¿Qué debe quedar claro antes de empezar?
Cierra el alcance con responsabilidades de operación: acceso al código y a los datos, infraestructura, documentación, soporte, respaldo y procedimiento para solicitar cambios. La propiedad y las obligaciones deben quedar expresamente acordadas en la propuesta y el contrato.
Pide que cada estimación indique sus supuestos y cómo se manejará una dependencia que falle. El plazo y el costo solo son comparables cuando las propuestas cubren resultados y responsabilidades equivalentes.
Como siguiente paso, prepara una página con el proceso, su responsable, los casos incluidos, las exclusiones, los sistemas necesarios y los criterios de aceptación. Esa base permite conversar con QuantixCode sobre un primer módulo útil y decidir qué conviene validar antes de ampliar la inversión.