Versión: 2.0
Fecha: 8 de Marzo, 2026
Arquitecto: Carlos Alberto Torres Camargo
Clasificación: Interno
┌──────────────────┐
│ JUNTA DIRECTIVA │
└────────┬─────────┘
│
┌────────▼─────────┐
│ GERENCIA / PO │ Product Owner
└────────┬─────────┘
│
┌──────────────┼──────────────┐
│ │ │
┌─────────▼────┐ ┌─────▼──────┐ ┌───▼────────────┐
│ ARQUITECTO │ │ PM / │ │ UX/UI │
│ DE SOLUCIONES│ │ SCRUM MASTER│ │ (Isabella) │
└──────┬───────┘ └─────┬──────┘ └───┬────────────┘
│ │ │
┌──────▼───────────────▼──────────────▼──────────────┐
│ EQUIPO DE FÁBRICA │
│ │
│ BACKEND FRONTEND │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ Sr. Backend │ │ Sr. Frontend │ │
│ │ (Gatekeeper) │ │ (Gatekeeper) │ │
│ │ Vanessa Luna │ │ Edward Macias │ │
│ └──────┬──────────┘ └──────┬──────────┘ │
│ │ │ │
│ ┌──────▼──────────┐ ┌─────▼────────────┐ │
│ │ Mid Backend │ │ Mid Frontend │ │
│ │ Sebastian │ │ Jonathan │ │
│ │ Saldarriaga │ │ Gutierrez │ │
│ └──────┬──────────┘ └──────┬───────────┘ │
│ │ │ │
│ ┌──────▼──────────┐ ┌─────▼────────────┐ │
│ │ Jr. Backend x2 │ │ Jr. Frontend │ │
│ │ Kevin Arroyave │ │ Andrea Guerrero │ │
│ │ Brahian Cortés │ │ │ │
│ └─────────────────┘ └──────────────────┘ │
│ │
│ ┌─────────────┐ │
│ │ DevOps │ │
│ └─────────────┘ │
└─────────────────────────────────────────────────────┘
| # | Nombre | Rol | Seniority Real | Stack | Responsabilidad Principal |
|---|---|---|---|---|---|
| 1 | Carlos Torres | Arquitecto de Soluciones | Senior | Full Stack | Gobernanza arquitectónica, capacitación, decisiones técnicas |
| 2 | Vanessa Luna | Sr. Backend (Gatekeeper) | Senior (Architecture) | Java 25, Hexagonal | Líder técnico backend, Gatekeeper de PRs, mentoría |
| 3 | Sebastian Saldarriaga | Mid Backend | Mid (Java Native) | Java 25, Spring Boot | Ejecución de features, soporte en mentoría de juniors |
| 4 | Kevin Arroyave | Jr. Backend | Junior (Trainee) | .NET → Java (cross-training) | Implementación supervisada |
| 5 | Brahian Cortés | Jr. Backend | Junior (Trainee) | .NET → Java (cross-training) | Implementación supervisada |
| 6 | Edward Macias | Sr. Frontend (Gatekeeper) | Senior (Tech Lead Pot.) | Angular 21 | Líder técnico frontend, core Nx, Component Library, Gatekeeper |
| 7 | Jonathan Gutierrez | Mid Frontend | Mid/Senior | Angular 21, Component Design | Component Library (nebula-ui-kit), componentes agnósticos, design-system |
| 8 | Andrea Guerrero | Jr. Frontend | Junior (High Potential) | Angular moderno | Implementación supervisada |
Nota sobre "Modo Dojo": Ninguno de los candidatos posee el seniority Senior/Gatekeeper autónomo necesario para operar sin supervisión del Arquitecto. El primer mes completo opera bajo mentoría intensiva.
Alcance: Diseño técnico, gobernanza arquitectónica, capacitación de alto nivel.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Definir y mantener la arquitectura | Continua | Manifiesto, patrones, estándares, decisiones técnicas |
| Aprobar cambios en librerías core | Por PR | nebula-models, nebula-commons, nebula-shared |
| Aprobar deploys a producción | Por release | Validar que cumple DoD y estándares |
| Capacitación técnica de alto nivel | Semana 2-3 | Sesiones intensivas Simappe para seniors |
| Sesiones técnicas semanales | Viernes 4 PM | 1 hr, tema rotativo, todo el equipo |
| Office Hours | Mar y Jue 10-11 AM | 1 hr, Q&A abierto, dudas técnicas |
| Code Review de alto impacto | Bajo demanda | PRs marcados "Architecture Impact: HIGH" |
| Evaluación técnica individual | Cada 4 semanas | Checkpoint 1:1 con cada desarrollador |
El Arquitecto NO es:
Criterios para escalar al Arquitecto:
Alcance: Implementación compleja, mentoría, control de calidad backend.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Implementar features complejas | Sprint | Entidades con lógica de negocio, integraciones |
| Gatekeeper de PRs backend | Diario | Aprobar/rechazar PRs de juniors y pares |
| Mentorear juniors backend | Continua | Pair programming primeras 2 semanas productivas |
| Crear nuevos servicios | Por necesidad | Con aprobación del Arquitecto |
| Proponer mejoras técnicas | Sprint Retro | Deuda técnica, optimizaciones |
| Code Review | Diario | SLA: 24 hrs para revisión |
| Modificar nebula-models | Por feature | Agregar DTOs, PR con aprobación Arquitecto |
Reglas del Gatekeeper Backend:
Alcance: Ejecución de features de complejidad media-alta, soporte en mentoría de juniors, segundo revisor de PRs.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Implementar features de complejidad media-alta | Sprint | CRUDs con lógica, validaciones, integraciones inter-servicio |
| Segundo revisor de PRs backend | Diario | Revisa PRs de juniors cuando el Senior no está disponible |
| Co-mentorear juniors backend | Continua | Pair programming, resolver dudas técnicas |
| Implementar módulos completos | Sprint | Con autonomía parcial, revisión del Senior antes de merge |
| Proponer mejoras en código existente | Sprint Retro | Refactoring, deuda técnica detectada |
| Participar en refinement técnico | Por sprint | Aportar estimaciones, identificar complejidad |
Diferencia con el Senior:
Diferencia con el Junior:
Ramp-up esperado: 2 semanas para ser productivo en Simappe (80% fit en Java nativo, requiere nivelación en el framework).
Alcance: Implementación de features asignadas bajo supervisión.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Implementar features asignadas | Sprint | Bajo supervisión del Senior |
| Escribir tests unitarios | Por feature | Cobertura mínima 70% |
| Seguir patrones establecidos | Siempre | Controller → Service → Component → Repository |
| Pedir code review antes de PR | Siempre | Nunca crear PR sin revisión previa del Senior |
| Documentar lo que aprende | Semanal | Notas personales, FAQ, troubleshooting |
| Participar en pair programming | Semanas 4-6 | Con Senior, transferencia de conocimiento |
Restricciones Junior Backend:
Alcance: Core del Nx Monorepo de negocio (nebula-erp), mentoría, control de calidad frontend, Gatekeeper de ambos repos frontend.
Proyecto asignado (PoC inicial): nebula-erp — https://gitlab.centricasoluciones.com/nebula/frontend/nebula-erp.git
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
Crear y mantener Core nebula-erp |
Continua | Nx workspace, app shell, routing, interceptors, guards, shared/* |
| Gatekeeper de PRs frontend | Diario | Aprobar/rechazar PRs en AMBOS repos (nebula-erp y nebula-ui-kit) |
| Implementar features complejas | Sprint | Módulos de referencia en nebula-erp, patrones nuevos |
Supervisar nebula-ui-kit |
Continua | Revisar PRs de Jonathan, aprobar publicación de versiones |
| Mentorear equipo frontend | Continua | Pair programming con Jonathan y Andrea, code review |
| Colaborar con UX/UI | Por módulo | Recibir diseños, implementar, iterar |
| Documentar patrones frontend | Por patrón | Guías de cómo crear módulos, componentes |
Reglas del Gatekeeper Frontend:
Alcance: Desarrollo y mantenimiento de la Component Library (nebula-ui-kit), componentes agnósticos reutilizables, design-system.
Proyecto asignado (PoC inicial): nebula-ui-kit — https://gitlab.centricasoluciones.com/nebula/frontend/nebula-ui-kit.git
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Implementar Component Library | Continua | DataTable, FormField, Modal, Sidebar, Toolbar, Breadcrumb, Toast, ConfirmDialog, FileUpload, EmptyState en nebula-ui-kit |
| Mantener design-system | Continua | Consistencia visual, temas, variables SCSS, alineación con manual UX/UI |
| Crear componentes agnósticos | Por necesidad | Componentes reutilizables sin acoplamiento a dominios de negocio |
| Publicar versiones en Nexus | Por release | Build con ng-packagr, publicar @nebula/ui-kit en Nexus con semver |
| Documentar componentes | Por componente | Props, eventos, ejemplos de uso, Storybook |
| Segundo revisor de PRs frontend | Diario | Revisa PRs de juniors cuando el Senior no está disponible |
Diferencia con el Senior:
nebula-erp)nebula-erp sin aprobaciónnebula-ui-kit (bajo supervisión del Senior)Diferencia con el Junior:
nebula-ui-kitnebula-ui-kit requieren revisión del SeniorPerfil: Jonathan Gutierrez tiene experiencia en creación de componentes agnósticos y diseño UI para plataformas transaccionales. Su fortaleza en design-system lo hace idóneo para liderar nebula-ui-kit.
Alcance: Implementación de módulos frontend usando componentes y patrones establecidos.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Implementar módulos frontend | Sprint | Usando Component Library existente |
| Seguir patrón Smart/Dumb | Siempre | Solo Smart Components inyectan servicios |
| Tests de componentes | Por feature | Snapshot + interaction tests |
| Pedir code review antes de PR | Siempre | Nunca crear PR sin revisión previa |
| Respetar boundaries Nx | Siempre | No importar de otros dominios directamente |
Restricciones Junior Frontend:
Alcance: Gestión del proyecto, facilitación Scrum, comunicación con gerencia.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Facilitar ceremonias Scrum | Por sprint | Planning, Daily, Review, Retro, Refinement |
| Gestionar backlog | Continua | Priorización con PO, refinement con equipo |
| Status Report a gerencia | Semanal (Viernes) | Avance, riesgos, bloqueadores |
| Gestionar impedimentos | Diario | Resolver bloqueadores del equipo |
| Coordinar con PO | Continua | HUs, criterios de aceptación, prioridades |
| Métricas y reportes | Quincenal | Velocity, burndown, calidad |
Alcance: Diseño visual, maquetas, validación de implementación.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Entregar diseños/maquetas por módulo | Por sprint | Antes del Sprint Planning |
| Definir Component Library visual | Inicial | Manual UX/UI, tokens de diseño |
| Validar implementación frontend | Por feature | Revisar que coincida con diseño |
| Iterar basado en feedback | Continua | Ajustes post-implementación |
| Participar en Sprint Review | Cada 2 semanas | Validar UX del entregable |
Alcance: Infraestructura, CI/CD, despliegues, monitoreo.
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
| Mantener pipelines CI/CD | Continua | Jenkins, build, test, sonar, deploy |
| Gestionar Docker y registries | Continua | Imágenes, Docker Compose, registry |
| Administrar nodos (NODE-00 a 03) | Continua | Monitoreo, backups, health checks |
| Deploy a ambientes QA/PROD | Por release | Con aprobación del Arquitecto |
| Gestionar certificados SSL | Por necesidad | Nginx Proxy Manager |
| Monitoreo y alertas | Continua | Grafana, Prometheus, alertas |
| Ejecutar rollback en QA y PROD | Por incidente | Con autorización: QA Lead (QA) o Arquitecto (PROD). Ver POLITICA_ROLLBACK |
Alcance: Validación funcional del lote en ambiente QA (nodo-02), aceptación o rechazo, accountability del cierre.
Rol formalizado por ADR-003 Política Entrega QA. Es accountability primaria de las Fases 5 y 6 del flujo de entrega (Validación y Cierre QA).
| Responsabilidad | Frecuencia | Detalle |
|---|---|---|
Recibir y leer QA_HANDOFF.md |
Por cierre de sprint | SLA: acuse mismo día hábil tras GATE-D |
| Ejecutar casos de prueba en nodo-02 | Fase 5 (Validación) | Usa 07_TestCases.md de cada HTU + casos críticos del handoff |
Producir QA_EXECUTION_REPORT.md |
Vivo durante Fase 5 | Matriz de casos vs resultado por ciclo de regresión |
| Abrir issues GitLab de defectos | Por defecto detectado | Con etiquetas bug, qa, sprint-N, severity-* |
| Decidir aprobación / rechazo del lote (GATE-E) | Por cierre de sprint | Según criterios de aprobación de ADR-003 §3.5 |
Firmar QA_CLOSURE.md (GATE-F) |
Por cierre de sprint | Cofirma con el Arquitecto. Autoriza release a PROD si aplica |
Aprobar input manual del stage Deploy QA |
Por build | En Jenkins UI, una vez ejecutados los casos críticos del flujo |
| Autorizar rollback en QA | Por incidente | Si detecta bug crítico (criterios en POLITICA_ROLLBACK §3) |
| Capturar métricas de calidad | Por sprint | First-time-right, MTTF, ciclos de retrabajo, distribución severidad |
| Participar en post-mortem de incidentes PROD | Por incidente | Aporta análisis de "por qué no se detectó en QA" |
Cobertura del rol:
QA_CLOSURE.md.Criterios para escalar al Arquitecto:
QA_HANDOFF ni en HTU.| Actividad | Arquitecto | Sr. Backend | Mid Backend | Jr. Backend | Sr. Frontend | Mid Frontend | Jr. Frontend | PM | UX/UI | DevOps | QA Lead |
|---|---|---|---|---|---|---|---|---|---|---|---|
| Decisiones arquitectónicas | A | C | I | I | C | I | I | I | I | C | I |
| Crear nuevo microservicio | A | R | I | I | I | I | I | I | I | C | I |
| Modificar nebula-models | C | R/A | R | I | I | I | I | I | I | I | I |
| Aprobar PR nebula-models/commons | A | C | I | I | I | I | I | I | I | I | I |
| Implementar feature backend | I | A | R | R | I | I | I | I | I | I | I |
| Implementar feature frontend | I | I | I | I | A | R | R | I | C | I | I |
| Code Review backend | C | A | R | I | I | I | I | I | I | I | I |
| Code Review frontend | I | I | I | I | A | R | I | I | I | I | I |
| Pipeline CI/CD | C | I | I | I | I | I | I | I | I | R/A | I |
| Sprint Planning | C | R | R | R | R | R | R | A | C | R | C |
| Refinement backlog | C | R | R | I | R | R | I | A | C | I | C |
| Testing integración | I | C | R | I | C | R | I | I | I | R/A | C |
Producir QA_HANDOFF.md |
A | R | C | I | I | I | I | C | I | I | C |
Promover develop → qa (GATE-D) |
A | R | C | I | I | I | I | I | I | C | I |
| Ejecutar pruebas QA | I | I | I | I | I | I | I | I | I | I | R/A |
Producir QA_EXECUTION_REPORT.md |
C | I | I | I | I | I | I | I | I | I | R/A |
| Decisión aprobar/rechazar lote QA (GATE-E) | C | I | I | I | I | I | I | I | I | I | R/A |
Firmar QA_CLOSURE.md (GATE-F) |
A | I | I | I | I | I | I | I | I | I | R |
Release qa → main (GATE-G) |
R/A | C | I | I | C | I | I | C | I | R | C |
| Deploy a producción | A | I | I | I | I | I | I | I | I | R | C |
| Rollback en QA | C | C | I | I | I | I | I | I | I | R | A |
| Rollback en PROD | R/A | C | I | I | C | I | I | C | I | R | C |
| Mentoría juniors | C | R | R | I | R | R | I | I | I | I | I |
| Diseño UX/UI | I | I | I | I | C | I | I | C | R/A | I | I |
| Validar UX implementada | I | I | I | I | C | C | I | I | A | I | C |
| Optimización performance FE | I | I | I | I | C | R | I | I | I | I | I |
Leyenda: R=Responsable (ejecuta), A=Aprobador (decide), C=Consultado, I=Informado
Notas sobre la RACI:
QA_CLOSURE.md (GATE-F) para autorizar release a PRODEl frontend de Nebula ERP se compone de 2 repositorios independientes. Cada miembro del equipo frontend tiene un proyecto primario asignado:
┌─────────────────────────────────────────────────────────────────────┐
│ FRONTEND NEBULA ERP │
│ │
│ nebula-ui-kit nebula-erp │
│ (Component Library) (Nx Monorepo Negocio) │
│ ┌─────────────────────┐ ┌──────────────────────┐ │
│ │ │ │ │ │
│ │ Jonathan Gutierrez │ │ Edward Macias │ │
│ │ (Mid Frontend) │ │ (Sr. Frontend) │ │
│ │ │ │ │ │
│ │ Responsable de: │ │ Responsable de: │ │
│ │ - Componentes UI │ publica │ - App shell │ │
│ │ - Design system │──────────────▶│ - Shared libs │ │
│ │ - Storybook │ @nebula/ │ - Nx boundaries │ │
│ │ - Publicar Nexus │ ui-kit │ - Features negocio │ │
│ │ │ (npm) │ - Routing/Guards │ │
│ └─────────────────────┘ │ │ │
│ │ Andrea Guerrero │ │
│ │ (Jr. Frontend) │ │
│ │ - Features simples │ │
│ │ - Bajo supervisión │ │
│ └──────────────────────┘ │
│ │
│ Edward Macias es Gatekeeper de AMBOS repos. │
│ Todo PR (ui-kit o erp) requiere su aprobación. │
└─────────────────────────────────────────────────────────────────────┘
| Repo | Git Clone URL | Responsable Primario | Colaboradores | Gatekeeper |
|---|---|---|---|---|
nebula-ui-kit |
https://gitlab.centricasoluciones.com/nebula/frontend/nebula-ui-kit.git |
Jonathan Gutierrez | Edward (reviewer), UX/UI (diseños) | Edward Macias |
nebula-erp |
https://gitlab.centricasoluciones.com/nebula/frontend/nebula-erp.git |
Edward Macias | Andrea (features), Jonathan (consulta) | Edward Macias |
Jonathan (nebula-ui-kit) Edward (nebula-erp)
│ │
│ 1. Implementa componente │
│ (ej: DataTable v1.0) │
│ │
│ 2. Crea PR en nebula-ui-kit │
│ ──────────────────────────────▶ │ 3. Revisa y aprueba PR
│ │
│ 4. Publica @nebula/ui-kit v1.0 │
│ en Nexus │
│ ──────────────────────────────▶ │ 5. npm update @nebula/ui-kit
│ │ en nebula-erp
│ │
│ │ 6. Usa DataTable en features
│ │ de negocio (accounting, etc.)
│ │
│ 7. Si Edward necesita ajuste ◀───────│ "Necesito prop X en DataTable"
│ en componente, lo solicita │
│ │
nebula-erp salvo consulta o pair programming con Edwardnebula-ui-kit — solo consume los componentes desde nebula-erp@nebula/ui-kit: Jonathan propone versión, Edward validaNota: Esta asignación es para la PoC inicial y Fase 1. Puede evolucionar cuando el equipo crezca o cambie la carga de trabajo.
NIVEL 1: Auto-resolución
Desarrollador busca en: Docs → Wiki → Stack Overflow → Google
Tiempo máximo: 30 min
NIVEL 2: Par / Senior
Preguntar al Senior del track (Backend o Frontend)
Tiempo máximo: 15 min de explicación
NIVEL 3: Office Hours con Arquitecto
Si el Senior no puede resolver → Mar/Jue 10-11 AM
Máximo 15 min por consulta
NIVEL 4: Sesión dedicada
Si requiere > 15 min → Agendar sesión con Arquitecto
SLA: dentro de 48 hrs
NIVEL 5: Decisión arquitectónica
Si afecta a más de 2 dominios o modifica libs core
→ Reunión formal con Arquitecto + documentación de decisión
Developer crea branch feature/XXX-descripcion
│
├── Implementa (siguiendo patrones)
├── Escribe tests (cobertura ≥ 70%)
├── Verifica lint + build local
│
▼
Crea PR en GitLab → Asigna a Gatekeeper (Sr. Backend o Sr. Frontend)
│
▼
Gatekeeper revisa (SLA: 24 hrs)
├── Aprobado → Merge a develop → Pipeline CI → Deploy DEV automático
└── Cambios solicitados → Developer corrige → Re-review
Developer propone cambio
│
▼
Gatekeeper (Senior) hace primera revisión
│
▼
Etiqueta PR como "Architecture Impact: HIGH"
│
▼
Arquitecto revisa (SLA: 24 hrs)
├── Aprobado → Merge → CI → Deploy
└── Cambios solicitados → Developer corrige → Re-review
| Version | Fecha | Autor | Descripcion |
|---|---|---|---|
| 1.0.0 | 2026-03-08 | Carlos Torres | Creación del documento de roles y responsabilidades |
| 2.0.0 | 2026-03-09 | Carlos Torres | Agregar roles Mid Backend (Sebastian Saldarriaga) y Mid Frontend. Actualizar organigrama con nombres reales. Expandir RACI a 10 roles. Agregar tabla de composición del equipo. |
| 2.1.0 | 2026-03-09 | Carlos Torres | Reemplazar Juan Atencio por Jonathan Gutierrez (Mid Frontend). Agregar seccion 4: Asignacion por Proyecto Frontend (Jonathan → nebula-ui-kit, Edward → nebula-erp). Actualizar perfiles con repos y URLs GitLab. |
| 2.2.0 | 2026-05-11 | Carlos Torres | Formalizar rol QA Lead (seccion 2.11) y agregarlo a la matriz RACI. Incorporar actividades del flujo de entrega a QA (GATE-D a GATE-G), rollback y QA_HANDOFF/QA_EXECUTION_REPORT/QA_CLOSURE. Alinea con ADR-003. |