El Quality Champion
Dominant dimension: Calidad
Los equipos de software hablan mucho de entregar, pero rara vez sobre las personas que se aseguran de que lo que se entrega realmente funciona. Los Quality Champion son esas personas. En los equipos, viven en la cola de revisión de pull requests. Leen los diffs como los editores leen los manuscritos: no solo para detectar errores, sino para evaluar claridad, mantenibilidad y las formas sutiles en que el atajo de hoy se convierte en la interrupción del próximo trimestre.
Pero la calidad no es solo una actividad de equipo. En la era del desarrollo asistido por IA, muchos ingenieros capaces trabajan solos: construyendo proyectos paralelos, manteniendo bibliotecas de código abierto o trabajando como freelancers. Su disciplina de ingeniería se manifiesta de manera diferente: cuerpos de PR descriptivos, ramas de funcionalidad en lugar de hacer push directamente a main, issues vinculados a cambios de código e historiales de commits limpios. Estos hábitos protegen un proyecto, trabaje en él una persona o cien.
La dimensión de Calidad en Chapa se adapta a cómo trabajas. Para desarrolladores colaborativos, mide el comportamiento de revisión: cuántas revisiones envías, la proporción de revisiones respecto a tus propias PRs y señales de higiene de código. Para desarrolladores en solitario, mide la disciplina de ingeniería: descripciones de PR, uso de ramas de funcionalidad, vinculación de issues y limpieza de commits.
Para obtener el arquetipo Quality Champion, tu dimensión de Calidad debe ser la más fuerte y puntuar al menos 60. Esto aplica tanto a perfiles colaborativos como en solitario: un desarrollador solo con hábitos disciplinados de PR puede perfectamente ser un Quality Champion.
Los revisores puros que rara vez abren sus propias PRs no son penalizados. El algoritmo reconoce que algunos ingenieros senior pasan la mayor parte del tiempo en revisión, y esa contribución es inmensamente valiosa aunque no produzca commits propios.
En los equipos, los Quality Champion suelen ser los ingenieros senior, los tech leads, los staff developers que han pasado de escribir funcionalidades a multiplicar la efectividad de todos a su alrededor. Son la razón por la que tu equipo detecta la inyección SQL antes de que llegue a producción. Son la razón por la que la segunda PR del desarrollador junior es dramáticamente mejor que la primera.
Los Quality Champion en solitario son los desarrolladores que tratan su propio proyecto con el mismo rigor que aplicaría un tech lead. Cada PR tiene una descripción. Cada funcionalidad empieza en una rama. Los issues están vinculados, los commits son limpios. Estos hábitos se acumulan: dentro de un año, su historial de git cuenta una historia que cualquiera puede seguir.
En proyectos de código abierto, los Quality Champion son los mantenedores que gestionan issues, revisan contribuciones de la comunidad y establecen el listón de calidad que define la reputación del proyecto. Sin ellos, los proyectos derivan hacia la entropía.
En el radar de Chapa, la forma de un Quality Champion se extiende fuertemente hacia la derecha (eje de Calidad). El visual es un diamante que se inclina lateralmente: ancho donde importa la calidad, estrecho donde el volumen bruto de entregas puede ser menor. Es la forma de alguien que mejora el código de todos los demás.