Qué deberías tener al terminar esta preparación
El objetivo no es redactar un contrato ni decidir la arquitectura. Es conseguir que dirección, usuarios y proveedores hablen del mismo problema con ejemplos suficientes para proponer un siguiente paso.
Un buen paquete inicial puede ocupar entre dos y cinco páginas, acompañado de documentos anonimizados. Debe explicar situación actual, personas, recorrido, excepciones, datos, sistemas, restricciones, señal de éxito y responsable de las decisiones.
Si una respuesta todavía no existe, indícala como incógnita. Una incertidumbre visible puede validarse; una suposición escondida reaparece como cambio, demora o riesgo durante la construcción.
1. Empieza por el problema observable
Describe qué sucede hoy, quién participa, con qué frecuencia y dónde aparece la fricción. «Necesitamos una app» es una solución posible; «los técnicos llaman para conocer el siguiente aviso y administración vuelve a escribir el parte» es un problema investigable.
Evita términos generales como mejorar eficiencia o digitalizar. Sustitúyelos por una escena: qué inicia el trabajo, qué información se recibe, qué decisión se toma, cuánto espera, qué sale mal y cómo se resuelve. Incluye volumen y variación si puedes medirlos.
- Qué ocurre y desde cuándo
- Quién lo detecta y quién soporta la consecuencia
- Con qué frecuencia y en qué momentos empeora
- Cómo se resuelve hoy y qué trabajo paralelo exige
- Qué pasa si no se cambia durante los próximos meses
- Qué ya se ha probado y por qué no fue suficiente
2. Separa objetivo, resultado y función
El objetivo explica el cambio buscado; la señal indica cómo observarlo; una función es solo una hipótesis para conseguirlo. «Enviar notificaciones» no es un resultado. «Reducir las llamadas para confirmar citas sin aumentar ausencias» sí permite evaluar distintas soluciones.
Elige una o dos señales, documenta su fuente y registra una línea base. Pueden ser tiempo de ciclo, correcciones, reaperturas, llamadas, adopción o capacidad. No inventes precisión: una muestra manual durante dos semanas es mejor que un porcentaje sin origen.
3. Identifica usuarios, responsabilidades y decisiones
No describas al usuario solo por cargo. Una persona de administración puede aprobar en un centro y consultar en otro. Indica dispositivo, ubicación, frecuencia, conectividad y conocimientos. Incluye usuarios poco frecuentes si realizan una acción crítica, como autorizar un pago o restaurar acceso.
- Quién inicia el proceso y con qué información
- Quién ejecuta la tarea principal y en qué contexto
- Quién valida, aprueba o puede bloquear
- Quién necesita consultar estado sin modificar
- Quién corrige excepciones y datos incorrectos
- Quién administra usuarios, permisos, catálogos y reglas
- Quién presta soporte y responde cuando algo falla
- Quién decide prioridades y acepta el entregable
4. Dibuja un caso de principio a fin
Después añade tres excepciones relevantes: falta información, una persona rechaza, el proveedor no responde, el dispositivo pierde conexión o el cliente modifica la petición. Las excepciones revelan más arquitectura que el caso ideal.
- Evento que inicia el proceso
- Datos mínimos y fuente de cada uno
- Responsable y estado después de cada acción
- Validaciones y aprobaciones
- Documentos, comunicaciones o movimientos generados
- Criterio de cierre y sistema donde queda registrado
5. Reúne ejemplos reales y anonimizados
Aporta formularios, hojas, capturas, emails, informes, tickets o documentos que el equipo ya utiliza. Incluye un caso normal, uno incompleto y uno problemático. Elimina datos personales y secretos que no sean necesarios para comprender el formato.
Marca qué campos son obligatorios, quién los mantiene, qué valores causan dudas y cuáles no se usan. Un ejemplo real evita horas de conversación abstracta y descubre definiciones distintas entre departamentos.
6. Aclara datos, histórico y permisos
No prometas «migrar todo» antes de revisar calidad y uso. Puede bastar con migrar datos activos, conservar un archivo histórico consultable o transformar solo lo que tenga un propietario y una finalidad.
- Qué entidades existen: cliente, pedido, equipo, aviso, artículo u otras
- Qué identificador evita duplicados y quién lo asigna
- Qué campos contienen datos personales o información sensible
- Quién puede consultar, modificar, aprobar, exportar y eliminar
- Cuánto histórico debe migrarse y para qué se consulta
- Qué retención, copia y recuperación exige la operación
- Qué exportación sería necesaria si se cambia de proveedor
7. Lista sistemas, proveedores y responsables
Una integración no está validada porque exista un logotipo o una página comercial. Solicita documentación técnica y acceso de prueba. Si eso no es posible, plantea una fase técnica separada antes de comprometer todo el flujo.
- Nombre del sistema, versión y proveedor
- Qué datos entran, qué datos salen y con qué frecuencia
- Qué sistema debe ser la fuente de verdad
- Si existe API, documentación, límites y entorno de prueba
- Quién puede autorizar acceso y facilitar credenciales
- Qué ocurre si el proveedor no responde o cambia la interfaz
- Cómo se detectan, reintentan y corrigen los fallos
8. Documenta restricciones no funcionales
Estas condiciones rara vez aparecen en una lista de pantallas, pero cambian coste y arquitectura. No necesitas especificar soluciones: describe el contexto y el daño que debería evitarse.
- Disponibilidad necesaria y periodos en los que una caída sería crítica
- Conectividad, trabajo offline y dispositivos reales
- Volumen actual, picos y crecimiento razonable
- Privacidad, consentimiento, auditoría y obligaciones aplicables
- Accesibilidad y perfiles con necesidades específicas
- Idiomas, territorios, monedas y zonas horarias
- Copias, recuperación y continuidad manual
- Navegadores, sistemas operativos, hardware y periféricos
9. Prioriza por flujo, no por lista de deseos
El primer alcance debe completar una tarea útil. Clasifica cada capacidad como necesaria para la prueba, necesaria para implantar, posible evolución o fuera del proyecto. Añade la razón; sin ella todo vuelve a parecer prioritario.
Evita repartir la primera versión de forma equitativa entre departamentos. Tres módulos incompletos producen menos aprendizaje que un flujo completo utilizado por un grupo representativo.
10. Comparte plazo, presupuesto y límites
Indica fecha necesaria y motivo, presupuesto orientativo, obligaciones, dispositivos, proveedores y decisiones ya tomadas. Ocultar un límite no mejora la propuesta; solo retrasa el momento en que el alcance debe adaptarse a él.
Distingue entre presupuesto para descubrir, construir e implantar, y coste recurrente de operar. Si todavía no existe una horquilla, pide una fase de blueprint que convierta incertidumbre en opciones comparables.
11. Pide propuestas comparables
No puntúes únicamente el total. Una propuesta puede ser menor porque resuelve mejor el alcance o porque omite una dependencia. Pide que cada proveedor señale qué validaría primero y qué circunstancia cambiaría su estimación.
- Interpretación del problema y preguntas pendientes
- Alcance, exclusiones, supuestos y dependencias
- Entregables y criterio de aceptación por fase
- Responsabilidades del cliente, proveedor y terceros
- Arquitectura y decisiones técnicas relevantes explicadas
- Plan de datos, integración, pruebas e implantación
- Precio, calendario, pagos y tratamiento de cambios
- Propiedad, repositorio, documentación, exportación y soporte
Plantilla breve para copiar en tu documento
Adjunta dos o tres ejemplos anonimizados y una lista de dudas. Eso suele resultar más útil que anticipar decenas de pantallas. El proveedor debería devolverte opciones, riesgos y preguntas, no limitarse a confirmar la lista.
- Situación actual: hoy [perfil] realiza [flujo] usando [herramientas] y aparece [problema] con [frecuencia].
- Objetivo: queremos mejorar [señal] desde una línea base de [dato y fuente], sin empeorar [restricción].
- Primer alcance: [perfil] completa [flujo] desde [inicio] hasta [cierre].
- Fuera inicialmente: [perfiles, excepciones, integraciones o territorios] y razón.
- Datos y sistemas: [fuentes], [responsables], [API o mecanismo] e incógnitas.
- Contexto: [dispositivos], [conectividad], [volumen], [seguridad] y [fecha motivada].
- Decisión: [persona] prioriza; [usuarios] validan; el piloto termina con [criterio].