Saltar a contenido

Plan por fases

Supuestos de capacidad

Verificar antes de comprometer fechas

  • 20 horas semanales, dato dado
  • Una persona, supuesto no confirmado. Si son dos personas a 10 horas cada una, las estimaciones se degradan por coordinación y cambian
  • Estimaciones de un tercero sin visibilidad sobre la fluidez real del equipo: banda de error ±50%

Total hasta fase 5: ~355 horas ≈ 18 semanas ≈ 4 meses y medio. Con la banda de error: entre 3 y 7 meses.

Cronograma

gantt
    title Plan de implementación (20 h/semana)
    dateFormat YYYY-MM-DD
    axisFormat %b
    section Base
    F0 Fundaciones        :f0, 2026-10-01, 10d
    section Carril A
    F1 Ingesta mínima     :f1, after f0, 28d
    F2 Filtros y decisión :f2, after f1, 14d
    section Comercial
    F3 Carril C y mapa    :f3, after f2, 21d
    section Inteligencia
    F4 Carril B           :f4, after f3, 35d
    F5 Scoring LLM        :f5, after f4, 14d
    section Continuo
    F6 Fuentes adicionales :f6, after f5, 21d

Fase 0 — Fundaciones · ~25 h

Repo, esqueleto Django, Postgres, MkDocs desplegado, registro de fuentes vacío, CI que corre tests.

Criterio de salida: python manage.py migrate funciona, el admin abre, el sitio de docs se publica, y hay un test que corre en CI.

  • Repo con estructura de proyecto Django
  • Postgres local y de producción
  • Modelos fuentes, ingestas, avisos migrados
  • MkDocs con despliegue automático
  • CI con pytest

Fase 1 — Carril A mínimo · ~80 h

Tres fuentes sin autenticación: Banco Mundial procnotices, BID CKAN, TED.

Esta es la fase que valida toda la arquitectura. Si el contrato de normalización aguanta tres fuentes de forma distinta, aguanta las demás.

  • Bucle genérico de ingesta que lee de fuentes
  • Normalizador BM + fixture + test
  • Normalizador BID + fixture + test
  • Normalizador TED + fixture + test
  • Deduplicación por fuente_id + id_nativo y hash de contenido
  • Comando renormalizar sobre el crudo guardado
  • Reporte en texto plano por correo
  • Arrancar ingesta silenciosa del carril B (Projects API), aunque no se reporte

Por qué la ingesta del carril B arranca acá

Acumular es gratis y el diff necesita historial. Si esperamos a la fase 4 para empezar a guardar snapshots, la fase 4 arranca ciega.

Criterio de salida: un reporte real, con cinco ítems o menos, que alguien lea y encuentre útil.

Fase 2 — Filtros y decisión · ~40 h

  • Filtros duros con códigos de razón
  • Asignación de escalon en normalización
  • Filtro por categoria_adquisicion
  • Cálculo de dias_ventana y alerta por ventana corta
  • Tabla decisiones expuesta en el admin de Django
  • Panel de calibración: cuántos descarta cada filtro

Criterio de salida: la alerta suena entre dos y tres veces al mes. Si suena más, los filtros están flojos.

Fase 3 — Carril C y mapa de base instalada · ~60 h

La fase que puede pagar el proyecto

No necesita historial: los datos ya existen. Produce dos entregables comerciales inmediatos, antes de que el carril A gane una sola licitación.

  • Ingesta de adjudicaciones (mismos endpoints, distinto tipo de aviso)
  • Carga histórica hacia atrás, varios años
  • Extracción de WMO Radar Database para países AR IV
  • Tablas radares, empresas, adjudicaciones
  • Vista: países AR IV con dos o más fabricantes o bandas
  • Vista: primes activos en la región, ordenados por volumen adjudicado
  • Comando check_debarment contra el dataset de sancionados del BID
  • Regla de ventana T+3 a T+9 sobre adjudicaciones nuevas

Entregables comerciales:

  1. Lista de países objetivo para integración, ordenada por heterogeneidad del parque
  2. Lista de fabricantes a quienes ofrecerse como socio local, con evidencia de su actividad regional

Criterio de salida: ambas listas existen, están revisadas a mano, y contestan la pregunta abierta de si nuestro stack coincide con la base instalada real de la región.

Fase 4 — Carril B · ~110 h

La fase más larga. Para acá ya hay meses de snapshots acumulados desde la fase 1.

  • Projects API: snapshot semanal y versionado
  • Motor de diff: qué constituye cambio reportable
  • Documents API con qterm sobre taxonomía técnica
  • Descarga y extracción de PDF, con caché por hash
  • Filtro de dos etapas: metadata barata antes de extraer
  • Vinculación id_proyecto_padre entre carriles
  • Ingesta de informes del Comité de Huracanes y páginas AR IV
  • Sección "Movimientos de cartera" en el reporte

Criterio de salida: la sección de movimientos de cartera sale vacía muchas semanas. Si sale llena todas las semanas, el diff está mal calibrado.

Fase 5 — Scoring con LLM · ~40 h

  • Prompt versionado de dictamen estructurado
  • Caché por hash de documento + versión de prompt
  • Detección de señales de pliego dirigido
  • Extracción de campos de decisión faltantes desde el pliego
  • Score de reglas con pesos configurables

Criterio de salida: al menos la mitad de lo que llega al reporte merece lectura completa del pliego.

Fase 6 — Fuentes adicionales · continuo

Por orden de valor esperado:

  1. UNGM, preferentemente vía suscripción Pro y parseo del digest
  2. IATI Datastore, con Full Access solicitado desde fase 1 por la demora de aprobación
  3. SAM.gov
  4. Portales nacionales OCDS de la región
  5. Búsqueda web residual

Trámites que conviene arrancar en fase 0

La clave de SAM.gov y la solicitud de Full Access de IATI no dependen de nosotros y tienen demora. Pedirlas al principio aunque se usen en fase 6.

Qué NO se construye

Registrado explícitamente para no reabrirlo cada mes:

  • Modelo de machine learning de scoring — no hay datos y no los habrá
  • Frontend propio antes de fase 6 — el admin de Django alcanza
  • Orquestador de flujos — ver ADR 0003
  • Integración con CRM — primero hay que tener qué integrar
  • Cobertura mundial — el alcance es AR IV más lo que los bancos financien ahí