Construye la cultura técnica que produce software de calidad de forma sostenida: la cultura del code review, los principios de ingeniería compartidos y los rituales que mantienen los estándares técnicos elevados con el tiempo.
Cuándo usarlo: Diseñar la cultura técnica de un equipo de ingeniería que produce software de calidad de forma sostenida.
Herramienta recomendada: Claude
Eres un experto en ingeniería de software y en la construcción de culturas técnicas de alta calidad en equipos de desarrollo. Quiero que me ayudes a diseñar la cultura técnica de mi equipo de ingeniería para que produzca software de calidad de forma consistente y sostenida. Mi contexto: - Tamaño del equipo: [número de desarrolladores y nivel de seniority] - Stack tecnológico principal: [lenguajes, frameworks, arquitectura] - Situación actual de calidad: [deuda técnica, cobertura de tests, frecuencia de bugs en producción] - Proceso de code review actual: [existe, es informal, es riguroso, no existe] - Principales problemas de calidad que sufro ahora: [bugs frecuentes, regresiones, código inconsistente, etc.] - Metodología de trabajo: [Scrum, Kanban, Shape Up, etc.] Con esa información, quiero que me entregues un plan completo en estas áreas: **1. Principios de ingeniería del equipo** Ayúdame a formular entre cinco y ocho principios de ingeniería que definirán cómo trabaja mi equipo. Para cada principio incluye: el enunciado del principio, la explicación de por qué importa, un ejemplo concreto de cómo se aplica en el día a día y un antipatrón que el principio ayuda a evitar. Los principios deben cubrir al menos: calidad del código, mantenibilidad, testing, revisión entre pares y tratamiento de la deuda técnica. **2. Cultura y proceso de code review** Diseña el proceso de code review ideal para mi equipo. Incluye: quién revisa (autor, revisor, quorum mínimo), criterios de aprobación, tiempos de respuesta esperados, qué cosas bloquean un merge y qué son solo sugerencias, cómo dar feedback constructivo y cómo gestionar los desacuerdos técnicos. Proporciona también una guía de diez preguntas que todo revisor debe hacerse antes de aprobar un pull request. **3. Rituales de calidad técnica** Propón seis rituales concretos que reforzarán la cultura de calidad. Para cada uno: nombre, frecuencia, duración, quién participa, qué se revisa o discute y cuál es el output esperado. Incluye al menos: revisión de bugs de producción (blameless postmortem), sesión de deuda técnica, tech talk interno y revisión de métricas de calidad. **4. Definición de "done" con calidad incorporada** Diseña una Definition of Done que incorpore criterios de calidad técnica no negociables. Incluye criterios de código, tests, documentación, revisión de seguridad y rendimiento. Explica cómo introducirla sin que el equipo la perciba como burocracia y cómo mantenerla actualizada cuando el contexto cambia. **5. Tratamiento de la deuda técnica** Propón un sistema para gestionar la deuda técnica de forma que no se acumule hasta convertirse en un problema crítico. Incluye: cómo identificarla y documentarla, cómo priorizarla frente a nuevas funcionalidades, qué porcentaje de la capacidad del equipo dedicar a reducirla y cómo comunicar su impacto al negocio en términos no técnicos. **6. Formación técnica continua** Diseña un programa de aprendizaje técnico continuo para el equipo. Incluye: cómo organizar tech talks internos, cómo gestionar el tiempo de aprendizaje dentro del sprint, cómo compartir conocimiento tras asistir a conferencias y cómo crear un ambiente donde hacer preguntas y admitir que no sabes algo es seguro y valorado. **7. Métricas de calidad técnica** Lista las ocho métricas que usaré para medir la salud técnica del equipo. Para cada una: definición exacta, cómo se mide, frecuencia de revisión, umbral de alerta y qué acción tomar cuando se degrada. Incluye métricas de DORA (deployment frequency, lead time, MTTR, change failure rate) y métricas de calidad de código. Responde en español. Sé concreto y accionable. Ten en cuenta que el objetivo es construir una cultura que se autorregulea y mantiene los estándares sin depender de una sola persona.