Madurez de la Programación Asistida por IA

Evalúa la práctica de desarrollo asistido por IA de tu equipo en cuanto a adopción de herramientas, prompting, validación, seguridad e impacto, desde Ad Hoc hasta Optimizado.

Correr en TeamRetro

Mide la eficacia con la que tu equipo utiliza los asistentes de programación con IA

Los asistentes de programación con IA han pasado de ser una novedad a una herramienta diaria, pero la adopción por sí sola no hace que un equipo sea eficaz. Este modelo de madurez ayuda a los equipos de ingeniería a analizar con honestidad cómo utilizan la IA a lo largo del ciclo de vida del desarrollo: desde la adopción de herramientas y la habilidad para redactar prompts hasta la validación de resultados, la seguridad y el impacto medible. Al puntuar cada dimensión en una escala de cinco etapas, desde Ad Hoc hasta Optimizado, los equipos construyen una imagen compartida de dónde son fuertes, dónde la IA introduce riesgos y dónde la inversión deliberada dará sus frutos. Úsalo para impulsar conversaciones sinceras, establecer una línea base y hacer un seguimiento de cómo crece tu práctica de desarrollo asistido por IA con el tiempo.

Dimensiones

Adopción de Herramientas

Con qué amplitud y reflexión se adoptan, configuran y mantienen actualizadas las herramientas de programación con IA en todo el equipo.

  • Cobertura de Herramientas

    Usamos herramientas de programación con IA de forma constante en nuestro trabajo diario de desarrollo.

    1. Ad HocUnos pocos ingenieros experimentan con herramientas de IA; la mayoría nunca las usa.
    2. EmergenteAlgunos ingenieros usan herramientas de IA con regularidad, pero la cobertura es irregular en el equipo.
    3. DefinidoLa mayoría de los ingenieros recurre a las herramientas de IA en tareas rutinarias; la adopción es amplia aunque no universal.
    4. GestionadoLas herramientas de IA forman parte del flujo de trabajo diario de casi todos los ingenieros, con elecciones sensatas según la tarea.
    5. OptimizadoLas herramientas de IA se usan de forma instintiva donde ayudan y se evitan conscientemente donde no; el equipo tiene un criterio claro y compartido.

  • Calidad de la Configuración

    Nuestras herramientas de IA están bien configuradas para nuestro código base, flujos de trabajo y contexto del proyecto.

    1. Ad HocLas herramientas funcionan con valores predeterminados; sin contexto específico del proyecto, convenciones ni salvaguardas configuradas.
    2. EmergenteUnos pocos ingenieros ajustan su propia configuración; nada se comparte a nivel de equipo.
    3. DefinidoExiste una configuración a nivel de equipo (archivos de reglas, instrucciones, listas de exclusión) para la mayoría de las herramientas.
    4. GestionadoLa configuración está versionada, revisada y se mantiene al día a medida que evoluciona el código base.
    5. OptimizadoLa configuración es un activo de primer nivel: medida, iterada y ajustada para maximizar la precisión en nuestro código.

  • Apoyo en la Incorporación

    Los nuevos miembros del equipo se ponen al día rápidamente con nuestras herramientas y prácticas de IA.

    1. Ad HocLos recién incorporados descubren las herramientas de IA por su cuenta; sin orientación, ejemplos ni punto de partida compartido.
    2. EmergenteIndicaciones informales de los compañeros; sin material escrito.
    3. DefinidoExiste una guía de configuración e inicio documentada y mayormente actualizada.
    4. GestionadoLa incorporación incluye sesiones prácticas de IA, prompts de ejemplo y un compañero para las primeras dudas.
    5. OptimizadoLos nuevos ingenieros son productivos con nuestro flujo de trabajo de IA en su primera semana y contribuyen al material de incorporación.

  • Conocimiento de Herramientas

    Nos mantenemos informados sobre las nuevas capacidades de programación con IA y reevaluamos nuestra cadena de herramientas.

    1. Ad HocNadie sigue lo que cambia en el ámbito de la programación con IA; usamos lo que adoptamos al principio.
    2. EmergenteUnos pocos ingenieros siguen el tema por su cuenta; los hallazgos rara vez llegan al equipo.
    3. DefinidoAlguien comparte actualizaciones relevantes de vez en cuando; sabemos a grandes rasgos qué hay disponible.
    4. GestionadoEvaluamos periódicamente nuevas herramientas y funciones frente a nuestras necesidades y cambiamos cuando vale la pena.
    5. OptimizadoExploración activa con experimentos compartidos; las decisiones sobre la cadena de herramientas son deliberadas y se basan en evidencia, no en el bombo publicitario.

Habilidades de Prompting

Qué tan bien se comunica el equipo con las herramientas de IA: mediante prompts claros, buen contexto, refinamiento y tareas del tamaño adecuado.

  • Claridad del Prompt

    Describimos las tareas a las herramientas de IA de forma clara y precisa.

    1. Ad HocLos prompts son frases vagas de una línea; los resultados son impredecibles y a menudo inservibles.
    2. EmergenteAlgunos ingenieros redactan buenos prompts; otros lanzan peticiones imprecisas a la IA y confían en la suerte.
    3. DefinidoLos prompts suelen incluir intención, entradas y salida esperada; los resultados son en su mayoría acertados.
    4. GestionadoLos prompts son consistentemente claros e inequívocos; el equipo comparte una noción de cómo es un buen prompt.
    5. OptimizadoLa elaboración de prompts se trata como una habilidad de primer nivel; los ingenieros logran resultados de alta calidad al primer o segundo intento.

  • Aporte de Contexto

    Damos a las herramientas de IA el contexto adecuado (código, restricciones e intención) para que rindan al máximo.

    1. Ad HocLos ingenieros preguntan sin compartir el código circundante, las convenciones ni las restricciones; el resultado ignora la realidad.
    2. EmergenteSe aporta algo de contexto cuando es obvio; las restricciones más sutiles suelen pasarse por alto.
    3. DefinidoLos ingenieros incluyen rutinariamente los archivos, tipos y restricciones relevantes en sus prompts.
    4. GestionadoEl aporte de contexto es deliberado; por defecto se dirigen las herramientas a los archivos, ejemplos y pruebas correctos.
    5. OptimizadoEl contexto está curado: la IA ve lo suficiente para ser útil y no tanto como para distraerse; el resultado encaja con naturalidad en nuestro código base.

  • Refinamiento Iterativo

    Refinamos y reorientamos las respuestas de la IA con eficacia cuando el primer intento falla.

    1. Ad HocLos ingenieros aceptan lo que produce la IA o lo descartan por completo; rara vez insisten para refinar.
    2. EmergenteHay algo de refinamiento, pero los ingenieros a menudo vuelven a empezar de cero en lugar de partir de lo que ya hay.
    3. DefinidoLos ingenieros iteran sobre el resultado de la IA para corregir lagunas; las conversaciones son productivas y no circulares.
    4. GestionadoEl refinamiento es rápido y preciso; los ingenieros saben reorientar sin perder el hilo.
    5. OptimizadoLos ingenieros extraen el máximo valor de cada conversación; saben con fluidez cuándo refinar, cuándo empezar de nuevo y cuándo dejar la IA a un lado y escribirlo ellos mismos.

  • Descomposición de Tareas

    Dividimos el trabajo complejo en piezas del tamaño adecuado para la IA que producen resultados fiables.

    1. Ad HocLos ingenieros lanzan funcionalidades enteras a la IA y se decepcionan con el resultado.
    2. EmergenteAlgunos ingenieros dividen el trabajo de forma adecuada; otros piden demasiado de una vez.
    3. DefinidoLas tareas suelen acotarse a una función o un cambio pequeño; el resultado es utilizable.
    4. GestionadoLos ingenieros descomponen el trabajo de forma fiable en tamaños aptos para la IA y encadenan pasos cuando hace falta.
    5. OptimizadoLa descomposición es intuitiva; los ingenieros saben exactamente cómo dividir el trabajo para mantener la precisión de la IA y el control en sus manos.

Validación de Resultados

Con qué rigor el equipo revisa, prueba y cuestiona el código generado por IA antes de confiar en él.

  • Rigor en la Revisión de Código

    Revisamos el código generado por IA con tanto cuidado como el código escrito por personas.

    1. Ad HocEl código generado por IA se acepta con poca o ninguna revisión; los defectos se cuelan.
    2. EmergenteLos revisores ojean el código generado por IA pero no lo escrutan; algunos problemas se detectan, muchos se escapan.
    3. DefinidoEl código generado por IA se revisa con el mismo estándar que cualquier otro código.
    4. GestionadoLos revisores prestan especial atención a los modos de fallo conocidos de la IA (APIs inventadas, lógica plausible pero incorrecta).
    5. OptimizadoLas revisiones son igual de rigurosas e igual de rápidas; el equipo tiene heurísticas claras sobre qué mirar con más detenimiento.

  • Cobertura de Pruebas

    Nuestro código generado por IA está respaldado por pruebas automatizadas.

    1. Ad HocEl código escrito por IA llega sin pruebas; los errores aparecen en producción.
    2. EmergenteLas pruebas se añaden de forma inconsistente; la cobertura del código de IA va por detrás del resto del código base.
    3. DefinidoSe espera que el código generado por IA se entregue con pruebas; las expectativas suelen cumplirse.
    4. GestionadoEl enfoque test-first es el patrón habitual para el código generado por IA; la cobertura coincide aproximadamente con la del resto del código base.
    5. OptimizadoLa IA redacta y los ingenieros refinan los casos de prueba como flujo de trabajo por defecto; la cobertura del código de IA iguala o supera la del resto del código base.

  • Evaluación Crítica

    Cuestionamos y verificamos el resultado de la IA en lugar de aceptarlo tal cual.

    1. Ad HocLos ingenieros confían en el resultado de la IA salvo que esté claramente roto; las alucinaciones sutiles se cuelan.
    2. EmergenteLos ingenieros son escépticos al principio pero tienden a aceptarlo una vez que compila o funciona.
    3. DefinidoLos ingenieros verifican activamente afirmaciones, firmas de funciones y llamadas a bibliotecas frente a la documentación y los tipos reales.
    4. GestionadoEl equipo comparte un modelo mental de cuándo la IA es fiable y cuándo no, y aplica el esfuerzo en consecuencia.
    5. OptimizadoLa evaluación crítica es automática; los ingenieros detectan alucinaciones y disparates que suenan convincentes sin perder velocidad.

  • Atribución de Errores

    Podemos saber cuándo un defecto se originó en código asistido por IA.

    1. Ad HocLos defectos se corrigen sin que nadie se pregunte de dónde vinieron; el equipo no tiene señal sobre la contribución de la IA.
    2. EmergenteAlgún ingeniero advierte ocasionalmente un defecto introducido por la IA, pero el equipo no tiene una visión compartida.
    3. DefinidoLos defectos relevantes atribuidos a la IA se señalan en los post-mortems o retrospectivas cuando surgen.
    4. GestionadoEl equipo puede determinar de forma fiable, a posteriori, si un defecto provino de la asistencia de IA o no.
    5. OptimizadoLa atribución a la IA es una óptica clara y compartida sobre cada defecto significativo; el equipo tiene una imagen honesta del efecto de la IA en la calidad.

Integración en el Flujo de Trabajo

Con qué naturalidad encaja la asistencia de IA en los hábitos diarios, la cadena de herramientas, los procesos del equipo y el equilibrio humano-IA.

  • Hábito Diario

    La asistencia de IA forma parte natural de nuestro trabajo de ingeniería del día a día.

    1. Ad HocLa asistencia de IA es una novedad que se saca de vez en cuando; no forma parte de cómo trabajan realmente los ingenieros.
    2. EmergenteAlgunos ingenieros recurren a la IA a diario; otros rara vez.
    3. DefinidoLa mayoría de los ingenieros usa la IA en su flujo normal varias veces al día.
    4. GestionadoLa asistencia de IA está totalmente integrada en el trabajo diario; los ingenieros también saben cuándo apartarse de ella.
    5. OptimizadoEl equipo opera con un ritmo humano-IA deliberado, usando la IA donde aporta valor y confiando en su propio criterio donde no.

  • Encaje en el Pipeline

    Las herramientas de IA encajan sin fricción en nuestro entorno de desarrollo y nuestro pipeline de CI/CD.

    1. Ad HocEl uso de IA queda totalmente fuera del pipeline; el resultado se pega a mano y la fricción es alta.
    2. EmergenteLas herramientas de IA funcionan en los editores pero se detienen a las puertas de CI/CD; la integración es superficial.
    3. DefinidoLa IA está integrada en los editores y la revisión de código; existen puntos de contacto con CI/CD para los casos comunes.
    4. GestionadoLas herramientas de IA encajan en la cadena de herramientas de extremo a extremo (IDE, revisión, CI, incluso respuesta a incidentes).
    5. OptimizadoLa integración con el pipeline es invisible: la asistencia de IA aparece donde es útil y se aparta del camino en el resto.

  • Adaptación de Procesos

    Hemos adaptado nuestros procesos para sacar el máximo provecho del desarrollo asistido por IA.

    1. Ad HocLos procesos no han cambiado desde la era pre-IA; el equipo usa la IA dentro de un flujo de trabajo antiguo.
    2. EmergentePequeños ajustes en las dailies o las revisiones para hablar de la IA; nada estructural.
    3. DefinidoSe han añadido prácticas concretas (enfoque de revisión, prompting en pareja, compartir prompts) a la forma de trabajar del equipo.
    4. GestionadoEl proceso del equipo se diseña activamente en torno a la asistencia de IA y se revisa con regularidad.
    5. OptimizadoProceso e IA evolucionan juntos; los cambios se prueban, se conserva lo que funciona y se descarta lo que no.

  • Equilibrio Humano-IA

    Sabemos cuándo apoyarnos en la IA y cuándo recurrir a nuestro propio criterio.

    1. Ad HocLos ingenieros o confían demasiado en la IA (y entregan sus errores) o se niegan a usarla (y pierden su ventaja).
    2. EmergenteLos ingenieros van descubriendo el límite caso por caso; las decisiones son inconsistentes.
    3. DefinidoLa mayoría de los ingenieros tiene una noción sensata de cuándo ayuda la IA y cuándo no.
    4. GestionadoEl equipo tiene heurísticas compartidas y articuladas sobre el trabajo humano frente al de la IA; los nuevos ingenieros las asimilan rápido.
    5. OptimizadoEl equilibrio es algo natural; los ingenieros se mueven entre modos con fluidez y debaten el límite abiertamente.

Seguridad y Cumplimiento

Qué tan bien protege el equipo los datos sensibles, sigue las políticas y gestiona los riesgos de propiedad intelectual, licencias y seguridad en el código generado por IA.

  • Tratamiento de Datos

    Evitamos exponer información sensible o confidencial a las herramientas de IA.

    1. Ad HocLos ingenieros pegan cualquier cosa en las herramientas de IA (secretos, datos de clientes, código propietario) sin pensarlo.
    2. EmergenteLa mayoría de los ingenieros sabe que no debe pegar secretos; aún ocurren errores con datos más sutiles (información personal, diseños internos).
    3. DefinidoExisten reglas claras sobre qué puede y qué no puede ir a las herramientas de IA, y los ingenieros las siguen en su mayoría.
    4. GestionadoLos flujos de datos aprobados se comprenden bien, se apoyan en herramientas (redacción, listas de permitidos) y se refuerzan en las revisiones.
    5. OptimizadoLa exposición de datos sensibles a las herramientas de IA se previene estructuralmente, no solo se desaconseja; el equipo puede describir los controles con confianza.

  • Cumplimiento de Políticas

    Seguimos de forma constante las políticas de uso de IA de la organización.

    1. Ad HocLos ingenieros desconocen la política de IA de la organización o la eluden activamente.
    2. EmergenteLa política existe pero se sigue de forma laxa; los ingenieros a veces usan herramientas no aprobadas.
    3. DefinidoLos ingenieros conocen las reglas y se mantienen dentro de ellas en lo que importa.
    4. GestionadoLa política es visible en los flujos de trabajo (listas de herramientas aprobadas, plugins de IDE) y cumplirla es el camino de menor resistencia.
    5. OptimizadoLa política es copropiedad del equipo; las lagunas y fricciones se elevan a quien la mantiene en lugar de sortearlas.

  • Conciencia de PI y Licencias

    Comprendemos los riesgos de propiedad intelectual y licencias en el código generado por IA.

    1. Ad HocLos ingenieros no consideran de dónde vino el código generado por IA ni qué implicaciones de licencia conlleva.
    2. EmergenteExiste conciencia pero ninguna acción; al equipo le costaría responder a las preguntas de un auditor.
    3. DefinidoLos ingenieros conocen lo básico (tipo de licencia de las sugerencias, normas de atribución) y evitan los riesgos evidentes.
    4. GestionadoLas verificaciones de PI/licencias forman parte de la revisión; el equipo puede defender su postura de forma creíble si se lo piden.
    5. OptimizadoLa PI y las licencias son una parte explícita y asumida de cómo se entrega el código asistido por IA; los controles y las excepciones están documentados.

  • Vigilancia de Vulnerabilidades

    Revisamos activamente el código generado por IA en busca de problemas de seguridad.

    1. Ad HocEl código generado por IA va a producción sin escrutinio de seguridad; los ingenieros asumen que está bien porque funciona.
    2. EmergenteLos escáneres estáticos detectan los problemas obvios; los revisores rara vez miran más allá.
    3. DefinidoLos revisores comprueban activamente el código generado por IA en busca de fallos de seguridad comunes (inyección, secretos, configuraciones inseguras por defecto).
    4. GestionadoEl equipo tiene una noción clara de dónde la asistencia de IA aumenta el riesgo de seguridad y aplica escrutinio adicional allí.
    5. OptimizadoLos patrones de vulnerabilidad introducidos por la IA se rastrean, se reintroducen en los prompts y las listas de verificación de revisión, y rara vez se repiten.

Intercambio de Conocimiento

Con qué apertura el equipo captura prompts, comparte aciertos y fracasos, colabora entre equipos y desarrolla sus habilidades de IA.

  • Bibliotecas de Prompts

    Documentamos y compartimos prompts eficaces y patrones de IA.

    1. Ad HocCada ingeniero reinventa los mismos prompts; no se comparte nada.
    2. EmergenteAlgunos prompts útiles se pegan en el chat de vez en cuando y se vuelven a perder.
    3. DefinidoUn lugar compartido (repositorio, wiki, archivo) recopila prompts y patrones; la gente contribuye y lo consulta.
    4. GestionadoLa biblioteca está curada, actualizada y se usa como punto de partida para las tareas comunes.
    5. OptimizadoLos prompts compartidos evolucionan con el código base; la biblioteca es un verdadero activo de productividad y ahorra retrabajo de forma demostrable.

  • Cultura de Aprendizaje

    Compartimos abiertamente aciertos, fracasos y experimentos con el desarrollo asistido por IA.

    1. Ad HocLos ingenieros no hablan de cómo usan la IA; los aciertos y fracasos quedan en privado.
    2. EmergenteHay algo de intercambio por canales alternativos (mensajes directos, menciones casuales); nada estructurado.
    3. DefinidoLas experiencias con IA surgen en retrospectivas, demos o dailies; se airean tanto los aciertos como los tropiezos.
    4. GestionadoCompartir es un ritmo habitual del equipo: sesiones, informes o puntos recurrentes en la agenda.
    5. OptimizadoEl equipo tiene una verdadera cultura de curiosidad en torno a la IA; los fracasos se valoran como aprendizaje, no se culpan.

  • Colaboración entre Equipos

    Intercambiamos prácticas de programación con IA con personas fuera de nuestro equipo inmediato.

    1. Ad HocNuestras prácticas de IA se quedan dentro del equipo; no sabemos qué hacen otros equipos.
    2. EmergenteHay charlas informales entre equipos de vez en cuando; ningún intercambio real.
    3. DefinidoLos ingenieros comparten notas entre equipos cuando importa; los patrones útiles circulan.
    4. GestionadoExisten foros o gremios activos entre equipos para las prácticas de IA; la participación es genuina.
    5. OptimizadoEl equipo aporta y aprende de otros equipos de forma continua; la práctica de IA se difunde como un efecto volante.

  • Desarrollo de Habilidades

    Invertimos deliberadamente en mejorar nuestras habilidades de desarrollo asistido por IA.

    1. Ad HocEl crecimiento de habilidades es accidental; los ingenieros solo mejoran cuando por casualidad prueban algo nuevo.
    2. EmergenteUnos pocos aprendices autodidactas; la mayoría de los ingenieros se queda en el nivel con el que llegó.
    3. DefinidoEl equipo asigna algo de tiempo explícito a desarrollar habilidades de IA (sesiones, parejas, lectura).
    4. GestionadoEl desarrollo de habilidades es una inversión habitual; se prueban, evalúan y adoptan nuevas técnicas en equipo.
    5. OptimizadoEl crecimiento continuo y deliberado forma parte de la identidad del equipo; los ingenieros son visiblemente mejores en el trabajo asistido por IA cada trimestre.

Medición del Impacto

Con qué honestidad el equipo rastrea el efecto de la IA en la productividad y la calidad, e integra esas lecciones en su forma de trabajar.

  • Seguimiento de Productividad

    Evaluamos si las herramientas de IA mejoran realmente nuestra velocidad de entrega.

    1. Ad HocNadie sabe si la IA nos hace más rápidos o más lentos; asumimos que ayuda.
    2. EmergenteSe habla de la sensación sobre las mejoras de productividad; ninguna señal más allá de la anécdota.
    3. DefinidoEl equipo rastrea algunos indicadores (tiempo de ciclo, rendimiento de PRs) junto con la adopción de IA.
    4. GestionadoEl impacto en la productividad se rastrea de forma deliberada; el equipo puede describir el efecto de la IA con evidencia.
    5. OptimizadoEl seguimiento de la productividad es honesto sobre las ganancias y las pérdidas; el equipo ajusta el uso de IA según lo que muestran los datos.

  • Métricas de Calidad

    Evaluamos si la asistencia de IA ayuda o perjudica la calidad de nuestro trabajo.

    1. Ad HocSin visión de cómo afecta la IA a las tasas de defectos, el retrabajo de revisión o la mantenibilidad.
    2. EmergenteLos ingenieros advierten patrones de calidad de forma anecdótica; ninguna señal compartida.
    3. DefinidoEl equipo rastrea indicadores de calidad (tasas de defectos, retrabajo, comentarios de revisión) en el contexto del uso de IA.
    4. GestionadoEl impacto en la calidad forma parte de cómo el equipo piensa sobre la IA; tanto los efectos positivos como los negativos son visibles.
    5. OptimizadoLa calidad es una óptica de primer nivel sobre el uso de IA; el equipo ha cambiado su práctica según lo que descubrió.

  • Integración en Retrospectivas

    Reflexionamos sobre el desarrollo asistido por IA durante nuestras retrospectivas.

    1. Ad HocEl uso de la IA nunca surge en las retrospectivas; es invisible para la reflexión del equipo.
    2. EmergenteLa IA se menciona en las retrospectivas de vez en cuando, normalmente como un comentario puntual.
    3. DefinidoLos temas de IA son un hilo recurrente en las retrospectivas; el equipo los discute cuando importan.
    4. GestionadoLas retrospectivas sacan a la luz de forma constante observaciones relacionadas con la IA y las convierten en acciones.
    5. OptimizadoEl uso de la IA es una óptica habitual en las retrospectivas; los hallazgos se traducen rápidamente en cambios de práctica.

  • Mejora Continua

    Ajustamos nuestro uso de la IA en función de los comentarios, los resultados y las lecciones aprendidas.

    1. Ad HocCómo usamos la IA no cambia; nos guiamos por los primeros instintos.
    2. EmergenteAjustes ocasionales basados en la frustración individual o en un buen consejo de otro lado.
    3. DefinidoEl equipo revisa sus prácticas de IA con regularidad; los cambios perduran cuando demuestran su valor.
    4. GestionadoLa mejora es un bucle real (medir, ajustar, volver a medir) y el equipo puede señalar los cambios que ha hecho.
    5. OptimizadoLa mejora continua de la práctica de IA forma parte de cómo opera el equipo; nada de cómo usamos la IA es estático.

Cuándo utilizar este chequeo

  • Cuando tu equipo ha adoptado asistentes de programación con IA y quiere una línea base honesta de cuán eficazmente se utilizan.
  • Antes de fijar objetivos o tomar decisiones de inversión en torno a herramientas, formación o gobernanza de IA.
  • Cuando el código generado por IA plantea dudas sobre calidad, seguridad o rigor de revisión que el equipo quiere abordar abiertamente.
  • Como punto de control recurrente para seguir cómo madura tu práctica de desarrollo asistido por IA trimestre a trimestre.
  • Durante una retrospectiva o un encuentro del equipo para impulsar una conversación sincera sobre dónde ayuda la IA y dónde introduce riesgos.

Consejos y trucos

  • Haz que cada miembro puntúe de forma independiente antes de debatir, para que la conversación saque a la luz diferencias reales de percepción en lugar de pensamiento de grupo.
  • Centra el debate en las dimensiones con mayor dispersión de puntuaciones: el desacuerdo suele apuntar a la conversación más valiosa.
  • Trata los niveles de madurez como un lenguaje compartido, no como una nota; el objetivo es la reflexión honesta, no puntuar alto.
  • Elige una o dos dimensiones sobre las que actuar entre sesiones en lugar de intentar mejorar todo a la vez.
  • Repite la evaluación cada trimestre y compara los resultados para ver si los cambios deliberados están realmente marcando la diferencia.
  • Usa la opción 'No Aplica' con libertad: no todas las dimensiones importan por igual a cada equipo o etapa.

Preguntas más frecuentes

¿Quién debería participar en este health check?
Cualquiera que escriba, revise o entregue código con asistencia de IA, normalmente todo el equipo de ingeniería, incluidos los líderes. Incluir una variedad de niveles de experiencia da una imagen más honesta que encuestar solo a los entusiastas o solo a los escépticos.
¿Cómo se estructuran los niveles de madurez?
Cada dimensión se puntúa en una escala de cinco etapas que va de Ad Hoc, pasando por Emergente, Definido y Gestionado, hasta Optimizado. Los niveles describen cuán consistente, deliberada y eficaz es la práctica del equipo, no cuántas herramientas usa.
¿Una puntuación más alta es siempre mejor?
Los niveles más altos reflejan una práctica más madura y deliberada, pero el verdadero valor está en la conversación y las acciones que la siguen. Un equipo que puntúa de forma modesta pero habla con honestidad sobre dónde puede mejorar saca más provecho de esto que uno que persigue un resultado perfecto.
¿Con qué frecuencia deberíamos realizarlo?
Una cadencia trimestral funciona bien para la mayoría de los equipos: lo bastante frecuente para seguir el progreso tras los cambios, pero lo bastante espaciada para que los cambios significativos tengan tiempo de ocurrir. Realizarlo después de un cambio importante de herramientas o procesos también es valioso.
¿Qué hacemos con los resultados?
Usa la dispersión de las puntuaciones para detectar dónde el equipo coincide y dónde discrepa, elige una o dos dimensiones en las que centrarte y conviértelas en acciones concretas. Revisa esas acciones y repite la evaluación más adelante para ver si han marcado la diferencia.