Autoevaluación Supervisión Efectiva

Documento de discusión — de plantilla Excel a plataforma de tests automatizados de CGM Consulting Group

Cliente piloto: Pintulac · Test piloto: Autoevaluación - Supervisión Efectiva (modelo "Las Tres Ces")

Tabla de contenidos

1. Qué revisamos
2. Decisiones tomadas
3. Anatomía del test
4. Cómo se calculan los resultados hoy
5. Estado actual: Pintulac
6. Hallazgos en los archivos actuales
7. Lo que esto nos dice sobre el producto a construir
8. Modelo de datos propuesto
9. Roles y permisos
10. Arquitectura y stack
11. Preguntas abiertas para discutir
12. Próximos pasos propuestos

🧭 Qué revisamos

Dos archivos, punto de partida de todo lo demás:

Es decir: hoy "automatizar el test" = copiar la hoja de la plantilla una vez por persona y llenarla a mano. Eso es exactamente el proceso que este proyecto busca reemplazar.

⬆ volver arriba

✅ Decisiones tomadas

Primera ronda de discusión, resuelta:

⬆ volver arriba

🧩 Anatomía del test

El test evalúa el modelo propietario de "Las Tres Ces" de Supervisión Efectiva: Claridad, Contagio y Control. Cada C se divide en subsecciones temáticas, y cada subsección contiene varios parámetros puntuables.

Cada parámetro se califica dos veces, en escala 1–10:

• Aplicación — qué tanto el líder aplica ese comportamiento.
• Respuesta — qué tanto responde/devuelve el equipo frente a ese comportamiento.

34 parámetros × 2 ejes = 68 datos por persona, todos de entrada manual, sin lista desplegable ni validación de rango en la plantilla (se puede tipear cualquier número, incluso fuera de 1–10, y Excel no lo objeta).

⬆ volver arriba

🔄 Cómo se calculan los resultados hoy

Dentro de cada hoja de colaborador, además de las respuestas crudas (columnas C y D), hay tres niveles de agregación construidos a punta de fórmulas y copiado manual de celdas:

flowchart LR
    A["Respuestas crudas<br/>C13:D70<br/>(34 filas × Aplicación/Respuesta)"] --> B["Promedio por subsección<br/>tabla N:P<br/>=SUM(rango)/n"]
    B --> C["Promedio por C<br/>tabla U57:W59<br/>Claridad · Contagio · Control"]
    A -.copiado celda a celda.-> D["Tabla plana U63:W97<br/>=+C13, =+D13, ... una fila por parámetro"]
    D --> E["12 gráficos de barra<br/>(uno por subsección)"]
    D --> F["1 gráfico radar<br/>'Rueda Supervisión Efectiva'"]
    C --> F

    classDef raw fill:#e8f0fe,stroke:#4285f4,color:#1a237e
    classDef calc fill:#fef7e0,stroke:#f9ab00,color:#5f3d00
    classDef chart fill:#e6f4ea,stroke:#34a853,color:#0d3d1a
    class A raw
    class B,C,D calc
    class E,F chart

Lo importante: la tabla plana U63:W97 (la que alimenta el gráfico radar grande) no es un cálculo, es una copia manual celda-por-celda (=+C13, =+D14, …) de las 34 respuestas. Se reconstruye a mano cada vez que se copia la hoja para un nuevo colaborador. Es el eslabón más frágil del archivo — y es justo donde encontramos el bug (ver Hallazgos).

⬆ volver arriba

📊 Estado actual: Pintulac

5 colaboradores evaluados hasta ahora. Promedios por C (escala 1–10):

💡 Un patrón que salta a la vista: en los 5 colaboradores y en las 3 Ces, Respuesta siempre puntúa por debajo de Aplicación (brecha de ~1 a ~2 puntos). Nadie puede verlo hoy sin abrir las 5 hojas y comparar a mano — es exactamente el tipo de insight que un dashboard agregado debería mostrar solo, y es un buen argumento a favor de construir la vista comparativa entre colaboradores/equipo desde el día uno.

⬆ volver arriba

⚠️ Hallazgos en los archivos actuales

⬆ volver arriba

🎯 Lo que esto nos dice sobre el producto a construir

La plantilla Excel no es solo el "diseño visual" del test — ya contiene, implícita, la lógica de negocio completa que el sistema nuevo debe reproducir (y arreglar):

• Un test tiene secciones → subsecciones → parámetros, en ese orden jerárquico, y ese orden importa para el reporte.
• Cada parámetro se responde en dos ejes simultáneos (Aplicación / Respuesta), no es un formulario de una sola pregunta por ítem.
• Los resultados se necesitan en tres niveles de zoom: por parámetro, por subsección, por categoría (C) — y ese último nivel es el que alimenta el radar, que es claramente la visualización "estrella" que le importa al negocio.
• El valor real no está en capturar la respuesta — está en agregar, comparar entre personas y seguir en el tiempo, cosa que Excel no hace hoy y que es el hallazgo #1 de la sección anterior.
• Pintulac es el cliente piloto y esta es la prueba piloto — el sistema debe pensarse multi-cliente y multi-test desde el modelo de datos, no como un caso especial.

⬆ volver arriba

🗂️ Modelo de datos propuesto (borrador para discutir)

erDiagram
    CLIENTE ||--o{ EMPLEADO : emplea
    CLIENTE ||--o{ CAMPANA : encarga
    CLIENTE ||--o{ USUARIO : "admite (cliente_admin)"
    TEST_PLANTILLA ||--o{ SECCION : define
    SECCION ||--o{ SUBSECCION : define
    SUBSECCION ||--o{ PARAMETRO : define
    TEST_PLANTILLA ||--o{ CAMPANA : se_aplica_en
    CAMPANA ||--o{ ENVIO : genera
    EMPLEADO ||--o{ ENVIO : responde
    EMPLEADO ||--o| USUARIO : "puede iniciar sesión como"
    ENVIO ||--o{ RESPUESTA : contiene
    PARAMETRO ||--o{ RESPUESTA : califica

    CLIENTE {
        string nombre "Pintulac"
        string logo_url
        string color_primario
        string color_secundario
    }
    USUARIO {
        string email
        enum rol "cgm_admin / cliente_admin / colaborador"
    }
    TEST_PLANTILLA {
        string nombre "Autoevaluación Supervisión Efectiva"
        string escala "1-10"
        json ejes "[Aplicación, Respuesta]"
    }
    CAMPANA {
        string periodo "Q1 2026"
        string periodicidad "trimestral"
        date fecha_inicio
        date fecha_cierre
    }
    EMPLEADO {
        string nombre
        string cargo
        string tienda_pos
    }
    ENVIO {
        date fecha_respuesta
        enum estado "pendiente/completo"
    }
    RESPUESTA {
        int valor_aplicacion "1-10"
        int valor_respuesta "1-10"
    }

Puntos deliberados de este borrador, para reaccionar en la discusión:

• TEST_PLANTILLA es reutilizable entre clientes (Pintulac hoy, otro cliente mañana con el mismo test o uno nuevo) y entre tests (Las Tres Ces hoy, el próximo test de CGM mañana).
• CAMPANA es lo que falta hoy en Excel: amarra un test a un cliente en un periodo, lo que habilita comparar entre campañas en el tiempo. periodicidad guarda el plan ("trimestral") pero ENVIO.fecha_respuesta es la fecha real — nunca se asume que todos responden a tiempo.
• EMPLEADO.cargo y tienda_pos resuelven el hallazgo #4 (sin metadatos) y habilitan cortar los resultados por tienda/zona, no solo por persona.
• USUARIO separa quién puede entrar al sistema de quién es evaluado. Un cgm_admin no pertenece a ningún cliente. Un cliente_admin pertenece a un CLIENTE y ve todo lo de ese cliente. Un colaborador está casi siempre ligado 1:1 a un EMPLEADO (así puede loguearse y ver su propio radar) — ese vínculo es opcional en el modelo porque un cliente_admin podría, a futuro, ser también evaluado.
• CLIENTE.logo_url / colores habilitan branding por cliente en reportes y formulario, sin tocar código por cada cliente nuevo.
• Los ejes de calificación (Aplicación/Respuesta) se modelan como algo configurable por test, no hardcodeado — para que el próximo test de CGM no obligue a tocar el esquema.

⬆ volver arriba

🔐 Roles y permisos

⚠️ Pendiente de confirmar: dentro de "designado del cliente", ¿todos los designados tienen el mismo nivel (ven todo el cliente), o eventualmente habrá un nivel intermedio (ej. gerente de zona que solo ve su zona)? Hoy el modelo asume que todo designado ve el cliente completo — si se necesita un nivel intermedio más adelante, se puede resolver sin rediseño mayor (es la opción "configurable por asignación" que quedó descartada para el v1, pero el modelo de USUARIO la deja abierta).

⬆ volver arriba

🏗️ Arquitectura y stack

Todavía sin decidir entre las dos opciones que planteaste. Para aterrizar la conversación:

Recomendación para reaccionar: Drupal headless (Drupal como backend/API + roles + multi-tenant, frontend a medida para el formulario y los dashboards) — porque el catálogo de clientes/tests/campañas/permisos que describiste es justo lo que Drupal resuelve de fábrica, y da flexibilidad total en la capa de captura y visualización, que es la parte más "de producto" del proyecto. Pero es una recomendación, no una decisión — queda pendiente confirmarla.

⬆ volver arriba

❓ Preguntas abiertas para discutir

Formulario web

• ¿El colaborador entra con usuario/contraseña, o con un link único por campaña (sin cuenta que mantener)?
• Con 68 respuestas en un solo test, ¿el formulario permite guardar avance a medias y continuar después, o se llena de una sentada?
• ¿Se conserva la escala numérica 1–10 tal cual (input numérico), o vale la pena una UI tipo slider/estrellas para ese rango?

Roles y permisos

• Ver la pregunta pendiente en Roles y permisos: ¿todo designado de cliente ve el cliente completo, o hará falta un nivel intermedio (por zona/equipo) más adelante?

Branding

• ¿El branding por cliente es solo logo en reportes/PDF, o también colores/tema dentro del formulario que llena el colaborador?

Arquitectura

• Ver Arquitectura y stack: ¿Symfony puro o Drupal headless? ¿Alguien del equipo ya tiene experiencia fuerte en uno de los dos que deba pesar en la decisión?

Roadmap de tests

• Mencionaste que hay más tests de CGM además de las Tres Ces — ¿conviene ver por encima 1 o 2 de esos tests ahora, aunque no se construyan todavía, solo para confirmar que el modelo de datos (Modelo de datos propuesto) realmente generaliza y no está sesgado hacia las particularidades de este test?

⬆ volver arriba

🚀 Próximos pasos propuestos

1. Cerrar la decisión de arquitectura y stack (Symfony vs. Drupal headless) — es la que más condiciona cómo arranca el proyecto.
2. Resolver las preguntas de UX del formulario (login por link vs. cuenta, avance guardado) — afecta el modelo de ENVIO/USUARIO.
3. Convertir el borrador de modelo de datos en un esquema concreto (migraciones/entidades) sobre el stack elegido.
4. Definir el primer entregable útil: probablemente cargar los datos que ya existen de Pintulac (arreglando el bug del hallazgo #1) para tener un dashboard real desde el arranque, antes de construir la captura de campañas nuevas.

⬆ volver arriba