Antes de empezar un proyecto de software no necesitas tener toda la solución diseñada. Sí necesitas un inventario verificable de procesos, datos, sistemas, accesos, integraciones, responsables y restricciones. Sin esa base, el equipo no distingue una decisión pendiente de una dependencia que puede bloquear el trabajo.
Preparar no significa entregar contraseñas ni producir documentación perfecta. Significa reducir supuestos y dejar claro qué existe, quién puede validarlo y qué debe comprobarse antes de comprometer arquitectura, alcance o fecha.
Empieza por el trabajo y el flujo actual
El inventario técnico solo tiene sentido si responde a un problema. Resume primero:
- quién realiza el trabajo;
- qué hecho lo inicia;
- qué pasos y decisiones contiene;
- qué entrada utiliza;
- qué salida debe producir;
- qué excepciones aparecen;
- qué sistema o persona interviene en cada paso.
Si todavía no existe esa referencia, prepara antes el alcance y los criterios de aceptación. C07 no vuelve a decidir qué construir: comprueba si los materiales y responsables necesarios para hacerlo están disponibles.
GOV.UK sitúa en discovery el conocimiento de usuarios, contexto, procesos, sistemas y restricciones antes de comprometer la construcción (GOV.UK, observada el 29/08/2026). Es una guía para servicios públicos británicos; aquí se utiliza como disciplina de preparación, no como duración o método contractual universal.
Inventaría los datos por finalidad y responsable
No empieces con “tenemos una base de datos”. Para cada conjunto necesario registra:
| Campo | Pregunta |
|---|---|
| Fuente | ¿En qué sistema, archivo o formulario nace? |
| Finalidad | ¿Qué decisión o resultado necesita ese dato? |
| Identificador | ¿Cómo se reconoce la misma entidad entre sistemas? |
| Formato | ¿Qué estructura, valores y reglas utiliza? |
| Calidad | ¿Qué vacío, duplicado o inconsistencia se conoce? |
| Volumen y ritmo | ¿Cuánto existe y cuándo cambia? |
| Responsable | ¿Quién entiende el significado y puede validar una muestra? |
| Conservación | ¿Qué debe mantenerse, archivarse o excluirse? |
Una muestra pequeña y trazable suele revelar más que una exportación masiva sin contexto. Incluye casos normales, excepciones y registros problemáticos, pero evita copiar datos personales cuando basten valores ficticios o anonimizados.
Si el punto de partida son hojas y tareas manuales, la guía para pasar de Excel a un sistema sin migrar el caos ayuda a separar dato, regla, excepción y parche antes de trasladarlos.
Dibuja cada integración como un intercambio
“Integrar con el ERP” todavía no describe una integración. Para cada intercambio concreta:
- sistema de origen y destino;
- dato o evento que viaja;
- dirección de lectura o escritura;
- disparador y frecuencia;
- volumen observado o pendiente de medir;
- identificador compartido;
- transformación necesaria;
- respuesta ante duplicado, retraso o fallo;
- responsable de cada extremo.
Microsoft organiza el análisis de una integración alrededor de volumen y frecuencia, dirección y capacidad de los sistemas (Microsoft Learn, observada el 29/08/2026). La guía está vinculada a Power Platform y contiene ejemplos de capacidad propios; el marco se usa para formular preguntas, no para trasladar cifras ni recomendar esa tecnología.
No des por disponible una API porque exista una página comercial. Registra la documentación concreta, el plan contratado, los objetos y operaciones permitidos, límites, autenticación y entorno de prueba. Lo desconocido queda pendiente; no se convierte en compatibilidad prometida.
Prepara accesos sin compartir credenciales maestras
Un proyecto puede necesitar acceso a documentación, entornos, APIs, repositorios o cuentas de proveedor. Para cada uno define:
| Decisión | Registro mínimo |
|---|---|
| Propiedad | cuenta y responsable de negocio |
| Identidad | usuario individual o identidad de servicio |
| Permiso | lectura, escritura, administración u operación concreta |
| Entorno | prueba, preproducción o producción |
| Entrega | quién concede el acceso y cuándo se necesita |
| Retirada | quién lo revoca al cambiar el equipo o terminar el trabajo |
Aplica el menor permiso compatible con la tarea y evita enviar secretos por documentos, chats o correo sin un mecanismo aprobado. No entregues acceso a producción durante una fase de definición si todavía basta con documentación, capturas controladas o un entorno de prueba.
Trata privacidad y seguridad como requisitos del caso
Si el proyecto usa datos personales, documenta finalidad, categorías necesarias, acceso, conservación y responsables desde el diseño. La AEPD explica la protección de datos por defecto como limitar cantidad, extensión, conservación y accesibilidad a lo necesario (AEPD, última modificación 05/01/2026; observada el 29/08/2026). Su guía orienta, pero no sustituye el análisis del tratamiento concreto.
Esto no convierte el artículo en evaluación jurídica o de seguridad. Si hay datos sensibles, transferencias, infraestructura crítica o requisitos regulatorios, identifica al responsable competente y deja la decisión pendiente hasta su revisión.
Asigna owner a cada vacío
Una lista de pendientes sin responsable solo desplaza la incertidumbre. Clasifica cada elemento:
ready: existe, está localizado y alguien puede validarlo;pending: falta una decisión o evidencia con owner y fecha de revisión;blocked: una dependencia impide definir o probar una parte relevante;not-applicable: se revisó y no pertenece al alcance actual.
No conviertas todos los pendientes en bloqueos. Un dato histórico puede esperar si la primera fase no lo usa; una credencial de producción no debe concederse antes de necesitarla. La prioridad depende del siguiente trabajo verificable.
Paquete mínimo para iniciar discovery o estimación
- Problema, usuarios y flujo actual.
- Alcance inicial y decisiones abiertas.
- Inventario de datos con finalidad, muestra y owner.
- Sistemas e integraciones con dirección y operación necesaria.
- Restricciones conocidas de contrato, proceso o tecnología.
- Cuentas y permisos requeridos por entorno, sin secretos compartidos.
- Responsables de negocio, datos, sistemas y aprobación.
- Dependencias clasificadas como
ready,pendingoblocked. - Criterio para decidir si se puede estimar, prototipar o detener.
Este paquete no elimina la incertidumbre. La hace visible para que una propuesta pueda declarar supuestos, exclusiones y pruebas en lugar de esconderlos dentro de una cifra o una fecha.