Uso operativo PtD. Dependencias e integraciones explican por que una tarea puede avanzar, quedar condicionada o bloquear actividades posteriores, especialmente con sistemas institucionales externos.
Caso de uso
Una API de INM o COMAR no tiene ambiente disponible y el equipo debe decidir si continua con mock, documenta condicion o replanea tareas afectadas.
Dependencias
- Registrar institucion o responsable, descripcion concreta, fecha requerida, impacto, tareas afectadas, contingencia y semaforo.
- Diferenciar falta de informacion, falta de ambiente, autorizacion pendiente, contrato incompleto, datos no disponibles o validacion institucional.
- Actualizar la dependencia cuando cambie estado, responsable, fecha o impacto en ruta critica.
Integraciones
- Registrar sistema, forma de integracion esperada, contrato OpenAPI, autenticacion, datos intercambiados, ambientes, pruebas y criterios de certificacion.
- Indicar si opera en mock, adaptador condicionado, ambiente QA, certificacion o produccion.
- Relacionar integracion con tareas tecnicas, pruebas, seguridad, datos y aceptacion funcional.
Escalamiento
- Un bloqueo que afecta fecha contractual debe reflejarse en dashboard, tarea, dependencia y mesa de seguimiento.
- Si el equipo usa mock, debe quedar claro que no equivale a integracion productiva.
- Toda aceptacion condicionada debe tener responsable, fecha objetivo, impacto y tarea afectada.
Buenas practicas
- No esconder dependencias en comentarios sueltos; usar el registro PtD y relacionarlo con tareas.
- Mantener contratos y datos de prueba separados de secretos o credenciales.
- Revisar dependencias antes de modificar fechas de tareas de interoperabilidad.
Resultado esperado
Las conversaciones tecnicas con instituciones se convierten en trazabilidad operativa y evitan cierres falsos de integracion.