Cómo Preparar a tu Equipo para una Auditoría de Código

Anunciar una auditoría de código en un equipo suele provocar la misma reacción que anunciar una inspección de Hacienda: silencio incómodo, sonrisas tensas y alguien que de repente recuerda que tiene «muchas cosas que ordenar». Es una pena, porque una auditoría bien planteada no es un examen ni una caza de brujas: es la mejor radiografía que va a tener ese código en su vida. Pero la diferencia entre una auditoría que transforma y una que solo genera un PDF caro está, en gran parte, en cómo se prepara el equipo.

En nuestra guía sobre auditorías de código contamos qué revisamos y qué entregamos. Esta es la otra cara: qué puedes hacer tú — CTO, tech lead o responsable de producto — en las semanas previas para que la auditoría rinda el doble y cueste la mitad.

Primero, las Personas: Véndelo Bien o Piérdelo Todo

El mayor riesgo de una auditoría no es técnico: es humano. Si el equipo percibe la auditoría como una amenaza, obtendrás respuestas defensivas, entrevistas vacías y un informe que nadie ejecutará. Si la percibe como lo que es — ayuda externa para ver lo que el día a día no deja ver — obtendrás la mejor fuente de información que existe: la gente que vive el código.

• Comunícalo tú, no por rumor. Una auditoría descubierta por un comentario en un pasillo nace envenenada. Anúncialo en persona, con la razón de negocio por delante: «vamos a crecer / refactorizar / levantar una ronda, y necesitamos evidencia objetiva del estado real».
• Di explícitamente qué no es. No es un ranking de desarrolladores, no se usa para evaluar desempeño individual y no habrá nombres en los hallazgos. El código es hijo de su contexto: plazos, pivotes, personas que ya no están. Dilo y cúmplelo.
• Promete el informe al equipo. Si solo dirección ve el resultado, el equipo asumirá lo peor. Comprometer por adelantado una sesión de resultados con el equipo técnico desactiva el 80% de la resistencia.

Semanas Antes: Prepara el Acceso, no el Escaparate

Hay una tentación comprensible: dos semanas antes de la auditoría, ponerse a arreglar código a toda velocidad. No lo hagas. Maquillar el escaparate tiene tres problemas: consume energía que necesitarás después, distorsiona exactamente la evidencia que estás pagando por obtener, y — esto es lo importante — se nota. El historial de git delata los commits de pánico.

Lo que sí acelera la auditoría (y la abarata, porque las horas del auditor se van en encontrar cosas, no en pedir accesos):

1. Acceso de solo lectura, completo y el primer día: repositorios, CI/CD, tablero de incidencias, monitorización y, si existe, la herramienta de calidad. Cada día de «es que el SSO…» es un día menos de análisis.
2. Un documento de contexto de una página: qué hace el producto, qué partes del sistema son críticas para el negocio, qué tecnologías conviven y por qué, y el mapa de personas responsables por área. Nadie conoce tu sistema mejor que tú: esa hora de escritura le ahorra una semana al auditor.
3. La lista de «lo que ya sabemos»: todo equipo tiene un inventario mental de vergüenzas conocidas — el módulo que nadie quiere tocar, la dependencia congelada desde 2023, los tests que se saltan en CI «porque son flaky». Escríbela. No porque el auditor la vaya a copiar (va a verificarla), sino porque comparar vuestra lista con los hallazgos es la mejor métrica de cuánto conocimiento real tiene el equipo sobre su propio código.
4. La pregunta de negocio, por escrito: «revisa todo» no es una pregunta. «¿Aguanta esta arquitectura triplicar usuarios?», «¿podemos reescribir el checkout sin tumbar el resto?», «¿qué me estoy comprando exactamente?» — esas sí. La pregunta define la profundidad de cada dimensión del análisis.

Durante la Auditoría: Disponibilidad sin Asedio

La auditoría convive con el equipo, no lo frena — pero necesita dos cosas del lado de casa:

• Un interlocutor con criterio y con agenda. Una persona que conozca el sistema, pueda responder «¿por qué esto está así?» y tenga bloqueada una hora al día para desbloquear dudas. Si ese interlocutor cambia cada día, la auditoría avanza a paso de caracol.
• Entrevistas sin managers en la sala. Cuando lleguen las conversaciones con el equipo, que sean a solas con el auditor. La pregunta más rentable de una auditoría — «¿qué te da miedo tocar?» — solo tiene respuesta honesta si quien firma las nóminas no está presente.

Y una petición de honestidad: si hay un incidente reciente, una fuga de datos o un despliegue catastrófico que nadie quiere mencionar, cuéntalo en la primera semana. Saldrá de todas formas — los logs y el historial de git son memoriosos — y descubrirlo por terceros destruye la confianza que la auditoría necesita para funcionar.

Después: Donde se Gana o se Pierde Todo

La auditoría más cara es la que no cambia ninguna decisión. El informe llegará con hallazgos incómodos — siempre lo hace — y ahí se separan los equipos que mejoran de los que archivan:

1. Recibe el informe sin ponerte a la defensiva. Cada hallazgo trae evidencia, impacto y esfuerzo estimado. Discute la evidencia si la crees errónea — es legítimo y sano — pero no conviertas la sesión en un juicio sobre el pasado. El pasado no es editable; el backlog, sí.
2. Preséntalo al equipo antes de que circule. Los hallazgos contados por el auditor, con contexto, generan conversación. Los mismos hallazgos filtrados por dirección generan paranoia.
3. Ejecuta los quick wins la primera semana. El informe traerá hallazgos de alto impacto y bajo esfuerzo — un control de acceso ausente, una dependencia vulnerable, un backup que nunca se ha probado a restaurar. Cerrarlos rápido no es solo seguridad: es la señal al equipo de que la auditoría sirvió para algo.
4. Convierte lo estructural en roadmap, no en culpa. Los hallazgos grandes (acoplamiento, deuda arquitectónica, deuda técnica acumulada) necesitan planificación, no heroísmos. Asigna capacidad real: un 15-20% del tiempo del equipo pagando deuda de forma sostenida gana a cualquier «sprint de refactor» que se cancelará en el segundo trimestre.

Los Tres Errores que Arruinan una Auditoría

1. Usarla como arma. Si el objetivo oculto es justificar despedir al equipo o cambiar de proveedor, el equipo lo olerá en la primera entrevista y la auditoría recogerá silencio en vez de información. Hay decisiones legítimas que tomar sobre equipos y proveedores — pero no uses una auditoría de código como coartada.
2. Maquillar el código antes. Además de inútil, es contraproducente: el auditor compara el estado del código con la velocidad histórica del equipo. Un repo milagrosamente limpio en las últimas dos semanas levanta exactamente las sospechas que intentaba evitar.
3. Archivar el informe. Si a los tres meses nadie ha ejecutado ni un quick win, el problema no era el código. La auditoría es el principio de un proceso de mejora, no el proceso en sí.

En Resumen

Preparar una auditoría de código es 20% logística y 80% cultura: acceso completo desde el día uno, un documento de contexto honesto, la lista de problemas conocidos por escrito y — sobre todo — un equipo que entiende que la auditoría evalúa el código, no a las personas. Quien prepara bien la auditoría no solo obtiene un mejor informe: empieza la mejora antes de que llegue el primer hallazgo.

Si estás valorando una auditoría y quieres saber cómo la planteamos — dos a cuatro semanas, sin frenar al equipo, con un backlog priorizado al final — hablemos de tu caso →

Sigue leyendo: Auditoría de código: qué revisamos, cómo trabajamos y qué te entregamos.