La primera vez que a un equipo de desarrollo le cae una auditoría interna, casi siempre pasa lo mismo: el equipo cree que le van a revisar el código, y le revisan otra cosa. Le piden quién autorizó un cambio, cuándo se aprobó, quién lo probó, cómo se sabe que lo que se probó es lo que se instaló, y qué pasa si hay que volver atrás. Nada de eso está en el código. Está —o no está— en el rastro que el equipo dejó mientras trabajaba.
Y ahí aparece la frase que convierte una revisión de rutina en un hallazgo: «sí, lo probamos, pero no quedó registrado».
Auditoría no busca errores. Busca ausencia de rastro
Este es el malentendido que más caro sale. Un auditor no está tratando de descubrir si usted programó bien. En la enorme mayoría de los casos no tiene cómo, y tampoco es su trabajo. Lo que hace es verificar que exista un procedimiento, que ese procedimiento se haya seguido, y que quede constancia de las dos cosas.
La consecuencia práctica es incómoda pero clara: un equipo excelente sin registro puntúa peor que un equipo mediocre con registro. No porque el auditor sea injusto, sino porque desde su posición el trabajo excelente sin rastro es indistinguible del trabajo que no se hizo.
Entender esto cambia por completo cómo se prepara uno. Deja de ser un ejercicio de defender la calidad del trabajo y pasa a ser un ejercicio de mostrar la cadena de decisiones.
Las cinco preguntas que van a llegar
Cambian los nombres y el orden, pero el fondo es casi siempre el mismo. Conviene tener las cinco respondidas antes de que las hagan.
1. ¿Quién pidió este cambio?
No alcanza con «me lo pidió Laura». Hace falta un pedido registrado en algún lado —un ticket, un correo, un acta— con fecha y con la persona que tiene atribución para pedirlo. Un cambio que entró por un mensaje de WhatsApp es, a los ojos de la auditoría, un cambio sin origen.
2. ¿Quién lo autorizó?
Pedir y autorizar no son lo mismo, y en muchas organizaciones no es la misma persona. Si el área usuaria pide y el dueño del sistema autoriza, tiene que haber dos rastros distintos. Este es el punto donde más equipos se quedan sin respuesta.
3. ¿Cómo se probó y quién dijo que estaba bien?
Acá hay una trampa frecuente: el equipo prueba y el equipo aprueba. Para una auditoría, quien construye no puede ser el único que valida. Hace falta una conformidad de alguien del lado del negocio, aunque sea un correo de dos líneas diciendo «probado, funciona».
4. ¿Lo que se probó es lo mismo que se instaló?
Esta es la pregunta que descoloca a los equipos que trabajan bien pero rápido. Si entre la prueba y la instalación se metieron dos correcciones más, lo que está en producción no es lo que se validó. La respuesta que sirve es una versión, una etiqueta, un número de entrega: algo que ate sin ambigüedad lo aprobado a lo instalado.
5. ¿Qué pasa si hay que volver atrás?
No se pregunta si alguna vez pasó. Se pregunta si existe el procedimiento y si alguien lo probó alguna vez. Un plan de reversión que nunca se ejecutó ni siquiera en un ensayo es, correctamente, considerado un plan hipotético.
El registro no se arma para la auditoría
El error de reacción más común, cuando llega el aviso de que va a haber una revisión, es armar la documentación hacia atrás. Es una mala idea por dos motivos.
El primero es práctico: reconstruir seis meses de decisiones lleva semanas y sale mal. Nadie se acuerda de por qué se hizo aquel cambio de marzo.
El segundo es más serio. Un legajo armado de golpe se nota. Todas las fechas de creación son de la misma semana, faltan los rastros intermedios, y aparecen aprobaciones firmadas después de la instalación. Un auditor con oficio lo detecta en veinte minutos, y a partir de ahí la conversación deja de ser sobre procedimientos y pasa a ser sobre confiabilidad. Ese es un lugar muchísimo peor.
La única estrategia que funciona es que el rastro sea un subproducto del trabajo diario. Si dejar constancia cuesta cinco minutos por cambio, se hace. Si cuesta media hora, no se hace, y no importa cuántas veces se pida.
Cómo dejarlo preparado sin frenar al equipo
Un solo lugar para los pedidos. Todo cambio entra por el mismo canal, sin excepciones. La excepción de hoy —«esto es urgente, mandámelo por mensaje»— es el hallazgo del año que viene.
La autorización como campo, no como conversación. Si la herramienta de tickets tiene un campo «autorizado por», se llena. Si no lo tiene, se pega el correo de aprobación en el ticket. Lo importante es que viva pegado al pedido y no en la casilla de alguien.
Una versión por entrega, y que se vea. Cada instalación en producción con su etiqueta, y esa etiqueta anotada en el ticket. Es el eslabón que conecta lo aprobado con lo instalado, y es el que más fácil se corrige y más caro sale cuando falta.
La conformidad del usuario, aunque sea de dos líneas. No hace falta un documento firmado. Un correo del referente del área diciendo «probado en el ambiente de pruebas, conforme» y guardado en el ticket resuelve el punto tres.
Un ensayo de reversión por semestre. Media hora, con un cambio menor, en un ambiente que no sea producción. Deja constancia de que el procedimiento existe y funciona, que es exactamente lo que se pregunta.
Cómo hablar en la reunión
Hay una diferencia de registro que conviene entender. Con un colega, usted explica el razonamiento: qué evaluó, qué descartó, por qué. Con un auditor, eso se lee como falta de un procedimiento claro. Lo que hay que entregar es el hecho, la fecha y el documento.
La respuesta útil tiene esta forma: «El pedido es el ticket 4417 del 12 de marzo, lo autorizó Ramírez el 13, la prueba está en el mismo ticket con la conformidad de Silva del 20, se instaló la versión 3.4.1 el 22, y el plan de reversión está en el documento adjunto.» Cuatro fechas, cuatro nombres, dos identificadores. Nada de arquitectura.
Y una regla que ahorra muchos problemas: cuando no sepa algo, dígalo y comprométase a una fecha. «Eso no lo tengo acá, se lo mando antes del jueves.» Improvisar una respuesta que después no se sostiene convierte un punto menor en un problema de credibilidad.
Lo que gana el equipo, más allá de la auditoría
Vale la pena decirlo, porque el registro se vive como burocracia y se abandona apenas afloja la presión: casi todo lo que pide una auditoría le sirve al equipo aunque no venga nadie a revisar.
Saber quién pidió cada cosa evita la discusión de «esto no lo pedí yo». Tener la autorización registrada protege al desarrollador el día que un cambio molesta a alguien. La etiqueta de versión es lo que permite responder en cinco minutos qué está corriendo en producción. Y el ensayo de reversión es lo que evita una noche entera de trabajo cuando algo sale mal.
El equipo que lleva registro no lo lleva para el auditor. Lo lleva porque le conviene, y de paso la auditoría deja de ser un evento.
En la formación para líderes trabajamos estas conversaciones tal como ocurren, con la documentación real que se pide en empresas de plaza. Conozca los planes o escríbanos si su equipo tiene una revisión encima.
