00 metodologia evaluacion

Actualizado: 7 de marzo de 2026

Metodologia de Evaluacion Tecnica#

Version: 4.0 — 7 de marzo 2026 Aplica a: Todos los cargos tecnicos del proyecto SoyDigital / Indotel Filosofia: No hay examenes. Hay un reto. Evaluamos tu codigo, no tus respuestas. Metodologia: Cada cargo tiene un reto distinto, planteado como un Sprint de Scrum con historias de usuario, criterios de aceptacion y Definition of Done.

Documentos relacionados: Cada cargo tiene su propio reto en un archivo separado. Este documento define la metodologia comun a todos.

Cargo Archivo
C1 — Brigadista / Tecnico de Campo C1-brigadista.md
C2 — Desarrollo Backend C2-backend.md
C3 — Desarrollo Frontend C3-frontend.md
C4 — DevOps e Infraestructura C4-devops.md
C5 — Ingenieria de Redes C5-redes.md
C6 — Desarrollo FullStack C6-fullstack.md

Cargo	Archivo
C1 — Brigadista / Tecnico de Campo	C1-brigadista.md
C2 — Desarrollo Backend	C2-backend.md
C3 — Desarrollo Frontend	C3-frontend.md
C4 — DevOps e Infraestructura	C4-devops.md
C5 — Ingenieria de Redes	C5-redes.md
C6 — Desarrollo FullStack	C6-fullstack.md

1. Filosofia de Evaluacion#

No usamos examenes teoricos. La unica evaluacion valida es lo que produces.

El candidato recibe un Product Backlog con historias de usuario priorizadas, un tiempo fijo (el Sprint), y debe entregar un Incremento funcional. Nosotros evaluamos ese Incremento — el repositorio, el deploy, el historial de commits, la calidad del codigo — con criterios objetivos y transparentes.

Principios:

Tu repo es tu examen. Lo abrimos, hacemos git log, corremos tree, leemos tu codigo
Tu git log es tu proceso de pensamiento. Queremos ver progresion, no un solo commit
Tu deploy es tu capacidad de entrega. Si no levanta, no cuenta
Tu README es tu capacidad de comunicacion. Si no se como correrlo, pierdes puntos
No evaluamos lo que sabes recitar. Evaluamos lo que sabes construir

2. Cargos y Niveles#

2.1 Cargos Evaluados#

ID	Cargo	Stack / Enfoque	Tipo de reto
C1	Brigadista / Tecnico de Campo	Hardware, redes basicas, Linux, despliegue fisico	Practico presencial
C2	Desarrollo Backend	Node.js, TypeScript, NestJS, Prisma, PostgreSQL	Desarrollo de producto — PayrollAPI
C3	Desarrollo Frontend	React, Next.js, TypeScript, TailwindCSS	Desarrollo de producto — MetricsDash
C4	DevOps e Infraestructura Cloud	Docker, CI/CD, GCP, monitoreo, seguridad	Desarrollo de producto — DeployOps
C5	Ingenieria de Redes	Wi-Fi, VPN, DNS/DHCP, protocolos, hardware de red	Practico presencial
C6	Desarrollo FullStack	Frontend + Backend completo	Desarrollo de producto — TaskFlow

Cada cargo tiene un reto distinto. Los retos de desarrollo (C2, C3, C4, C6) comparten la misma metodologia de evaluacion (este documento) pero el producto a construir es diferente. Los retos presenciales (C1, C5) tienen su propia mecanica.

2.2 Niveles de Seniority#

Nivel	Nombre	Experiencia tipica	Autonomia esperada	Alcance del reto
N1	Junior	0-1 anos	Supervisado, sigue instrucciones	Historias basicas (H01-H04)
N2	Semi-Senior	1-3 anos	Semi-autonomo, propone soluciones	Historias basicas + intermedias (H01-H08)
N3	Senior	3-6 anos	Autonomo, toma decisiones tecnicas	Todas las historias (H01-H12)
N4	Arquitecto / Experto	6+ anos	Lidera, disena sistemas, mentora	Todas + extras de arquitectura (H01-H15)

Nota sobre cargos y niveles:

FullStack (C6) puede evaluarse en niveles N1 a N3. Se evalua en Frontend y Backend simultaneamente. Debe demostrar competencia en ambas capas: API + UI.
Arquitecto (N4) es el unico nivel que se evalua de forma transversal en todas las disciplinas: Backend + Frontend + DevOps. No basta con dominar una o dos — el Arquitecto demuestra dominio del sistema completo, desde el modelo de datos hasta el pipeline CI/CD y la observabilidad.

3. Rubrica Detallada — Que Evaluamos del Repo#

Esto es lo central del proceso. No preguntamos teoria: la leemos directamente de tu codigo. Cada criterio tiene puntos positivos y penalizaciones especificas.

3.1 Complejidad Algoritmica#

No preguntamos "que es Big O". Abrimos tu repo y contamos:

Penalizaciones (las buscamos con grep, ESLint, y lectura manual):

Que buscamos	Como lo detectamos	Penalizacion
Loops anidados innecesarios ( $O(n^2)$ o peor)	`for` dentro de `for`, `.find()` dentro de `.map()`	-3 pts por cada caso evitable
Queries N+1	Prisma/ORM sin `include`/`join`, SELECT en loop	-5 pts por patron N+1 detectado
Busquedas lineales donde cabe un indice o hash	`.find()` sobre arrays grandes sin usar Set/Map	-2 pts por caso
Sorts innecesarios o redundantes	`.sort()` en cada render o en cada request	-2 pts por caso
Memoria descontrolada	Arrays que crecen sin limite, fetches sin paginacion	-3 pts por caso
Full table scan por falta de indice	Query sin WHERE indexado sobre tabla con 1000+ rows	-3 pts por caso

Puntos positivos:

Que buscamos	Puntaje
Uso correcto de indices en DB (EXPLAIN muestra Index Scan)	+5 pts
Paginacion implementada en API y frontend con `meta: { total, page, pages }`	+5 pts
Caching donde tiene sentido (Redis, in-memory, HTTP cache headers)	+5 pts
Batch operations en vez de loops de queries individuales (`createMany`, `transaction`)	+5 pts
Complejidad optima demostrada (ej: fractional indexing para posiciones)	+5 pts

3.2 Arquitectura#

No preguntamos "que es clean architecture". Miramos tu tree y tu codigo:

Que buscamos	Como lo detectamos	Puntaje
Separacion de capas clara	Carpetas: routes/controllers/services/repositories (o modules en NestJS)	+10 pts si hay, -10 si todo esta en un archivo
Desacoplamiento	Los servicios no importan directamente Express/Fastify/el framework HTTP	+5 pts
Inyeccion de dependencias	Usa DI container (NestJS nativo) o patron de inyeccion manual	+5 pts
Manejo de errores centralizado	Middleware/filter de errores global, no try-catch sueltos en cada endpoint	+5 pts
Configuracion externalizada	Variables de entorno via `.env`. No hay URLs, puertos o claves hardcodeadas	+5 pts, -10 si hay secrets en el codigo
Monolito bien estructurado	Modular, con boundaries claros entre dominios	+10 pts
Microservicios (si aplica)	Solo si tiene sentido para el scope. No por moda	+10 pts si justificado, -5 pts si es overengineering innecesario

3.3 Modelado de Datos#

Que buscamos	Como lo detectamos	Puntaje
Modelo normalizado	Schema Prisma/migrations sin columnas redundantes. No repetir datos	+10 pts
Indices apropiados	Index en campos de busqueda frecuente y FKs	+5 pts
Relaciones correctas	FK con onDelete CASCADE o RESTRICT segun la logica del dominio	+5 pts
Migraciones versionadas	Archivos de migracion en el repo, no solo `db push`	+5 pts
Datos de prueba / seed	Script de seed que crea datos de ejemplo para levantar el proyecto rapido	+3 pts
Soft-delete implementado	`deletedAt` con queries filtradas. No borrado fisico	+3 pts

3.4 Patrones de Diseno#

No preguntamos "que es Observer". Buscamos si los usaste donde tienen sentido:

Patron	Donde deberia aparecer	Puntaje
Repository	Abstraccion sobre Prisma/DB para cada entidad	+5 pts
Strategy	Multiples implementaciones intercambiables (ej: proveedor de pago real vs mock)	+5 pts
Observer/Events	Webhooks, notificaciones, side effects desacoplados	+5 pts
Factory	Creacion de objetos con datos default	+3 pts
Middleware/Guard	Auth guard, role guard, rate limiting	+5 pts
Singleton (correcto)	Instancia unica de Prisma client, instancia unica de SDKs	+3 pts
Antipatrones detectados	God classes (1 archivo > 300 lineas), funciones > 50 lineas, acoplamiento circular	-5 pts por caso

3.5 Seguridad#

Que buscamos	Puntaje
Contrasenas hasheadas con bcrypt (costo >= 10) o argon2	+5 pts
CORS configurado: solo origenes permitidos, no `*` en produccion	+3 pts
Input validation en todos los endpoints (Zod, class-validator, Joi)	+5 pts
SQL injection imposible (ORM con parametros, no string concatenation)	+5 pts
Secrets en `.env` con `.env.example` en el repo (sin valores reales)	+5 pts, -20 pts si hay secrets commiteados en el historial
Rate limiting en login y registro (ej: 5 intentos por minuto por IP)	+5 pts
CSRF/XSS: tokens CSRF en forms, sanitizacion de HTML	+3 pts
Headers de seguridad: Helmet o equivalente configurado	+3 pts

3.6 Testing#

Que buscamos	Puntaje
Tests unitarios: validacion, permisos, logica de negocio	+10 pts
Tests de integracion: endpoints reales contra DB de test	+10 pts
Coverage > 60%	+5 pts adicionales
Coverage > 80%	+5 pts adicionales (acumulable)
Tests E2E: al menos el flujo principal del producto	+5 pts
No hay tests (N3/N4)	-10 pts
No hay tests (N1/N2)	Neutral (no penaliza, pero no suma)

3.7 DevOps y Deploy#

Que buscamos	Puntaje
Deploy funcionando en URL publica (obligatorio para N2+)	+10 pts
Dockerfile optimizado: multi-stage build, imagen final < 200MB	+5 pts
CI/CD configurado: push a main = tests + build + deploy automatico	+10 pts
Variables de entorno bien gestionadas (secrets del CI, no en el repo)	+5 pts
Endpoint GET /health con: status, uptime, version, DB connectivity	+3 pts
Logging estructurado en JSON con timestamp, level, message, requestId	+5 pts
Monitoring basico: alerta si healthcheck falla, metricas de latencia	+5 pts

3.8 Frontend#

Que buscamos	Puntaje
Componentes reutilizables: Button, Modal, Card como componentes genericos	+10 pts
Estado global bien manejado: Zustand, Context API correctamente, o React Query. No prop drilling excesivo	+5 pts
Responsive design: funciona en mobile (375px) y desktop (1440px)	+5 pts
Accesibilidad basica: aria-labels en botones sin texto, semantic HTML, tabulacion correcta	+5 pts
Performance: Lighthouse > 80 en todas las categorias	+5 pts
SSR/SSG donde tiene sentido	+5 pts
Code splitting / lazy loading para rutas pesadas	+3 pts
Interacciones fluidas: < 16ms por frame, no hay jank visible	+10 pts
Skeleton loaders o estados de carga (no pantalla en blanco mientras carga)	+3 pts

3.9 Git y Proceso#

Que buscamos	Puntaje
Commits atomicos: cada commit hace UNA cosa, con mensaje descriptivo	+5 pts
Historial que muestra progresion logica	+5 pts
Branches por feature o al menos commits bien organizados	+3 pts
Un solo commit "initial commit" con todo el codigo	-5 pts
Commits basura: "fix", "asdf", "test123", "WIP", "aaaa"	-3 pts
Force push que destruye historial	-5 pts

3.10 Documentacion#

Que buscamos	Puntaje
README completo: setup, tests, deploy, env vars, arquitectura basica	+5 pts
API documentada: Swagger accesible o Postman collection en el repo	+5 pts
Diagrama de arquitectura: C4, Mermaid, draw.io, cualquier formato legible	+5 pts
ADRs (Architecture Decision Records): al menos 3 decisiones documentadas	+5 pts
Nada documentado (N3/N4)	-5 pts
Nada documentado (N1/N2)	Neutral

4. Pesos por Cargo (% del puntaje total)#

Criterio de Evaluacion	C1 Brigadista	C2 Backend	C3 Frontend	C4 DevOps	C5 Redes	C6 FullStack
3.1 Complejidad algoritmica	—	15%	10%	5%	—	12%
3.2 Arquitectura	—	20%	15%	15%	—	15%
3.3 Modelado de datos	—	15%	5%	5%	—	10%
3.4 Patrones de diseno	—	10%	10%	5%	—	8%
3.5 Seguridad	—	10%	5%	15%	—	8%
3.6 Testing	—	10%	10%	10%	—	10%
3.7 DevOps y deploy	—	5%	5%	25%	—	5%
3.8 Frontend	—	—	25%	—	—	17%
3.9 Git y proceso	—	5%	5%	5%	—	5%
3.10 Documentacion	—	10%	10%	15%	—	10%
Reto practico presencial	100%	—	—	—	100%	—
Total	100%	100%	100%	100%	100%	100%

Diferencia clave entre cargos:

C2 Backend / C3 Frontend: se especializan en una capa. Se les evalua profundamente en esa capa con un reto especifico.
C6 FullStack: se le evalua en ambas capas con pesos balanceados. Debe demostrar que construye la API y la interfaz. No se le exige profundidad en DevOps (5%).
N4 Arquitecto: es el unico nivel que se evalua transversalmente en todo — Backend + Frontend + DevOps + documentacion de arquitectura. El Arquitecto no es un cargo separado; es un nivel de seniority que aplica a cualquier cargo (C2, C3, C4 o C6) y demuestra dominio completo del sistema.

5. Que Esperamos por Nivel — Expectativas Detalladas#

N1 — Junior#

Expectativa: Sabe construir algo basico que funciona. No necesita optimizar, pero no debe tener errores garrafales de seguridad.

Criterio	Expectativa concreta	Red flag (descalifica)
Complejidad	Acepta $O(n^2)$ si el dataset es pequeno. No hay $O(n^3)$ sin razon	Queries N+1 en pantalla principal
Arquitectura	Al menos separa rutas de logica. No todo en `index.js`	Todo el backend en un solo archivo de 500+ lineas
Datos	Schema funcional que levanta con `migrate deploy`	No hay migraciones. Schema cambia con `db push` sin control
Seguridad	Contrasenas hasheadas. No hay secrets en el codigo	Password en texto plano en la DB. API keys en el frontend
Testing	Opcional. Bonificacion si tiene al menos 1 test	—
Deploy	Local funciona con `npm run dev`. Deploy es bonificacion	`npm install` falla. No hay instrucciones de setup
Git	Commits razonables. Minimo 5 commits	Un solo commit con todo el codigo

N2 — Semi-Senior#

Expectativa: Construye algo completo, documentado, y desplegado. Sigue buenas practicas de API y datos.

Criterio	Expectativa concreta	Red flag (descalifica)
Complejidad	Cero queries N+1. Paginacion en endpoints de listado	Mas de 2 queries N+1 en endpoints usados
Arquitectura	Capas claras: controller/service/repository (o modules NestJS)	Logica de negocio en el controller directo
Datos	Modelo normalizado. Indices en campos clave. Soft-delete implementado	Datos redundantes. No hay indices. Hard-delete
Seguridad	Input validation en todos los endpoints. CORS configurado. Secrets en `.env`	Endpoints sin validacion. CORS `*` en produccion
Testing	Tests unitarios basicos: al menos auth y permisos	—
Deploy	Funcionando en URL publica. README con instrucciones de deploy	Deploy roto. URL no funciona al momento de revision
Git	Commits por feature. Mensajes que describen el cambio	Historial incomprensible

N3 — Senior#

Expectativa: Codigo de calidad produccion. Tests dan confianza. Decisiones documentadas.

Criterio	Expectativa concreta	Red flag (descalifica)
Complejidad	Cero funciones $O(n^2)$ evitables. Caching donde aplica. Batch operations	Algoritmos ineficientes en hot paths
Arquitectura	Clean architecture o hexagonal. DI. Desacoplamiento real entre dominios	Acoplamiento circular entre modulos
Datos	Indices optimizados. EXPLAIN limpio. Migraciones limpias. Seed funcional	Full table scans en queries frecuentes
Seguridad	Rate limiting. CSRF. Helmet. Validacion exhaustiva	Sin rate limiting en login
Testing	Unitarios + integracion. Coverage > 60%	No hay tests
Deploy	CI/CD configurado. Docker multi-stage. Healthcheck endpoint	Deploy manual sin pipeline
Git	ADRs o decisiones documentadas en el README	Sin documentacion de decisiones

N3 — FullStack (Frontend + Backend)#

Expectativa: Demuestra dominio real de ambas capas — construye la API y la interfaz completa. No es un backend que sabe un poco de CSS ni un frontend que sabe hacer un CRUD. Es alguien que puede entregar un producto funcional de punta a punta.

Criterio	Expectativa concreta	Red flag (descalifica)
Backend	API REST completa, bien estructurada, con capas separadas. Prisma + migraciones	API fragil o incompleta. Endpoints sin validacion
Frontend	Componentes reutilizables, estado bien manejado, responsive. No solo "funciona" — se ve profesional	UI rota en mobile. Prop drilling excesivo
Integracion	Frontend consume la API correctamente. Auth con tokens/cookies. Manejo de errores end-to-end	Frontend con datos hardcodeados. No consume su propia API
Datos	Modelo normalizado. Indices. Seed. Soft-delete	Schema inconsistente con lo que el frontend necesita
Seguridad	Bcrypt, input validation en API, CORS configurado. Secrets en `.env`	Secrets en el codigo. CORS `*` en produccion
Testing	Tests en ambas capas: al menos unitarios backend + 1 test de componente frontend. Coverage > 50%	Sin ningun test
Deploy	App funcionando en URL publica. README explica como levantar ambas capas	Deploy roto. No hay instrucciones

N4 — Arquitecto (transversal: Front + Back + DevOps)#

Expectativa: Dominio completo del sistema. El Arquitecto es el unico nivel que debe demostrar competencia en todas las disciplinas: Frontend, Backend y DevOps. Sistema listo para produccion real. Observabilidad, documentacion, y capacidad de defender cada decision ante evaluadores.

Criterio	Expectativa concreta	Red flag (descalifica)
Complejidad	Complejidad optima demostrable. Puede explicar el por que de cada estructura de datos elegida	No puede justificar sus decisiones
Arquitectura	Justifica monolito vs servicios. Boundaries de dominio claros. Event-driven si aplica	Overengineering sin justificacion
Datos	Estrategia de cache documentada. Desnormalizacion justificada si la hay	Modelo de datos incoherente
Seguridad	Threat model documentado. Zero-trust approach. Rate limit + WAF o equivalente	Vulnerabilidades criticas conocidas sin mitigar
Testing	E2E + integracion + unitarios. Coverage > 80%	Coverage < 60%
Deploy	Observabilidad completa: logs, metricas, alertas. Rollback strategy documentada	Sin monitoring ni healthcheck
Documentacion	Diagramas C4. ADRs (minimo 3). Runbook de operaciones	Sin documentacion
Defensa oral	30 minutos defendiendo decisiones ante 2 evaluadores senior. Responde a cuestionamientos tecnicos	No puede explicar su propio codigo

6. Puntaje y Clasificacion#

6.1 Puntaje maximo: 200 puntos#

La suma de puntos positivos menos penalizaciones, ponderada segun los pesos del cargo (seccion 4).

Como se calcula:

Se evalua cada criterio (3.1 a 3.10) y se asignan puntos segun la rubrica
Se aplica el peso del cargo. Ejemplo para Backend (C2): Arquitectura vale 20%, asi que si sacaste 35/50 en arquitectura, aporta $35 \times 0.20 = 7$ puntos al total
Se suman todos los criterios ponderados
Se normalizan a escala de 200

6.2 Condiciones minimas (no negociables)#

Independientemente del puntaje, estas condiciones deben cumplirse o es descalificacion automatica:

Nivel	Condicion obligatoria	Consecuencia si no se cumple
Todos	El repo existe y es accesible	No se evalua
Todos	`npm install` no falla	No se evalua
Todos	La aplicacion levanta localmente	No se evalua
N1+	Auth funciona (registro + login) — donde aplique al reto	Descalificado
N2+	Deploy en URL publica funciona	Descalificado
N3+	Al menos 1 test pasa con `npm test`	Descalificado
FullStack	Frontend y Backend implementados (no puede entregar solo una capa)	Descalificado
N4	Documentacion de arquitectura existe	Descalificado
N4	Defensa oral completada	Descalificado

6.3 Puntaje minimo para aprobar#

Nivel	Minimo	Lo que significa
N1 — Junior	80/200	Construyo algo que funciona. Tiene potencial
N2 — Semi-Senior	100/200	Entrega profesional basica. Puede trabajar con supervision minima
N3 — Senior	130/200	Calidad de produccion. Puede liderar features
N3 — FullStack	140/200	Calidad de produccion en ambas capas. Puede entregar features completas end-to-end
N4 — Arquitecto	160/200	Puede disenar y liderar el sistema completo

6.4 Clasificacion y accion#

Rango	Resultado	Accion
170-200	Excepcional	Contratacion inmediata al nivel evaluado. Candidato para liderar equipo
140-169	Aprobado	Contratacion al nivel evaluado
110-139	Competente	Contratacion un nivel por debajo + plan de desarrollo 90 dias con mentor
80-109	En desarrollo	Solo para Junior: contratacion con mentoria obligatoria y re-evaluacion a 90 dias
< 80	No aprobado	No procede. Feedback escrito con areas de mejora

7. Logistica y Reglas del Juego#

7.1 Modalidad#

Aspecto	Detalle
Formato	Presencial en oficina (preferido) o remoto supervisado con camara encendida durante todo el Sprint
Herramientas permitidas	Editor de codigo, terminal, documentacion oficial de librerias
Herramientas prohibidas	AI generativa: GitHub Copilot, ChatGPT, Claude, Gemini, Cursor, etc. Deteccion: revision de patrones, timestamps, entrevista oral
Entorno	Laptop propia o proporcionada. Acceso a internet completo
Registro	Grabacion de pantalla obligatoria durante todo el Sprint (OBS, loom, o similar)

7.2 Equipo evaluador#

Rol	Responsabilidad
Evaluador tecnico 1	Revisa codigo, arquitectura, tests, seguridad. Califica rubrica seccion 3
Evaluador tecnico 2	Revisa deploy, DevOps, documentacion, git. Califica rubrica seccion 3
Evaluador de producto	Para N4: participa en la defensa oral. Evalua comunicacion y decisiones

Calibracion: Antes de cada ciclo de evaluacion, los evaluadores calibran criterios con un repo de ejemplo calificado previamente.

7.3 Timeline del proceso#

Paso	Duracion	Descripcion
1. Briefing	15 min	Se entrega el documento del reto al candidato. Se responden preguntas sobre el reto (no sobre como resolverlo)
2. Sprint	6-8 horas	El candidato trabaja. Puede hacer preguntas sobre requerimientos (como un Product Owner en un Sprint real)
3. Entrega	15 min	El candidato hace push final, comparte URL de deploy, sube video
4. Code review	48 horas	Los evaluadores revisan el repo asincronamente con la rubrica
5. Defensa oral (N4)	30 min	El candidato presenta y defiende sus decisiones
6. Feedback	24 horas	Feedback escrito al candidato con puntaje desglosado y areas de mejora

8. FAQ — Preguntas Frecuentes#

P: Puedo usar una plantilla/boilerplate para empezar? R: Si, pero debe estar declarado en el README y el historial de git debe mostrar tu trabajo sobre esa base. No puedes entregar un boilerplate sin cambios significativos.

P: Que pasa si no me da tiempo de terminar todo? R: Se evalua lo que entregaste. Es mejor tener 4 historias bien hechas que 8 a medias. La calidad siempre pesa mas que la cantidad.

P: Puedo preguntar cosas durante el Sprint? R: Si, pero solo sobre requerimientos ("el plan Free permite X?"), no sobre implementacion ("como conecto X con Y?"). Simulamos un Sprint real donde el evaluador es tu Product Owner.

P: La grabacion de pantalla es obligatoria? R: Si. Es parte de la evidencia. Si no hay grabacion, la evaluacion se invalida. Recomendamos OBS (gratis) o Loom.

P: Que pasa si detecto que use AI? R: Descalificacion. La deteccion se basa en: patrones de codigo (comentarios tipo AI, funciones perfectamente documentadas pero sin errores humanos), velocidad anormal para el nivel declarado, y la defensa oral (si no puedes explicar tu propio codigo, es sospechoso).

P: Puedo entregar antes del tiempo limite? R: Si. El tiempo sobrante no suma ni resta puntos. Lo que importa es la calidad del Incremento entregado.

Documento mantenido por el equipo de Arquitectura — Critertec / Indotel