Qué mira una auditoría técnica

Una auditoría mide el riesgo que compra quien entra

Una auditoría técnica antes de una ronda, de una compra o de la firma de un cliente grande no existe para poner nota a tu sistema. Existe para responder a una pregunta: si esto sale mal, cuánto cuesta y quién lo paga. Las preguntas que se hacen durante la revisión cuelgan de ahí.

Entenderlo cambia cómo te preparas. Un sistema con deuda técnica reconocida, documentada y con un plan de plazos pasa mejor que uno sin deuda conocida del que nadie sabe explicar cómo se despliega.

Si un inversor, un comprador o un cliente grande va a mirar dentro y no hay nada preparado, esta es tu situación. Es una de las cinco por las que nos llaman, y suele llegar con fecha puesta.

Los cinco sitios donde mira

Propiedad y procedencia del código. Quién es dueño de lo que se ha construido. Si hubo proveedores externos, si el contrato cedía los derechos, si el repositorio está a nombre de la empresa o de la cuenta personal de alguien. Aquí también entra el inventario de licencias de las dependencias, porque una licencia contagiosa dentro de un producto que se vende cerrado es un problema legal, no técnico.

Desde que parte del código se genera con asistentes, esta pregunta se ha vuelto más frecuente y más incómoda. Se responde con procedencia y con revisión, no negando que se use.

De cuántas personas depende esto. Cuántas personas pueden desplegar. Cuántas entienden la parte por la que pasa el dinero. Qué pasa si mañana no está la que lleva más tiempo. Un sistema que solo una persona sabe tocar no es un activo estable, y quien invierte lo comprueba mirando quién ha escrito cada parte. Está contado en un sistema legacy es código sin dueño.

Los datos. Dónde están, quién puede leerlos, qué se guarda de personas y con qué base legal, cuánto se conserva y qué pasa si alguien pide que se borren. Y la pregunta que más veces se queda sin respuesta buena: cuándo fue la última vez que se restauró una copia de seguridad de verdad, no cuándo se hizo. Una copia que nunca se ha restaurado no está comprobada.

El dinero, si pasa por tu sistema. Si cobras, facturas o concilias con software propio, esa parte se mira aparte y con lupa. Que los ingresos declarados cuadren con el banco. Que las facturas no tengan huecos de numeración ni se puedan modificar después de emitidas. Que el cumplimiento fiscal esté donde tiene que estar, que en España pasa por lo que exige Verifactu. Reconstruir dos años de conciliación bancaria durante una due diligence sale caro y llega tarde.

La capacidad de cambiar. Se mide por lo que tarda un cambio pequeño en llegar a producción y por lo que se rompe cuando llega. Se mide con hechos: cómo se despliega, si vuelve atrás solo cuando falla, qué se comprueba de forma automática y qué se comprueba mirando. Un sistema donde cada cambio cuesta más que el anterior es un sistema cuyo plan de producto no se puede cumplir, y eso es lo que un inversor está comprando.

Cómo se comporta la conversación

Un auditor no te va a pedir el código y ya está. Va a pedir que alguien le cuente una decisión y luego va a ir a comprobarla. Las respuestas que sostienen esa comprobación son las escritas: por qué se eligió esta arquitectura, qué se descartó, qué se sabe que está mal y qué plazo tiene.

Lo que complica una auditoría es la sorpresa: encontrar algo que el equipo no había mencionado. A partir de ahí se revisa con más detalle todo lo demás.

Por eso conviene entregar tú mismo la lista de lo que está mal, con su tamaño y su orden.

Qué se puede preparar antes, y en cuánto tiempo

En dos o tres semanas se puede tener casi todo lo que se pide.

Un documento corto de arquitectura con las tres o cuatro decisiones que explican el sistema, y lo que se descartó. El inventario de servicios, cuentas, dominios y licencias, con quién es el titular de cada uno. Una restauración de copia de seguridad hecha de verdad, con la fecha apuntada. La lista de accesos, con las bajas de gente que ya no está. Y el registro de deuda técnica conocida, con tamaño y prioridad.

Eso mismo es lo que hace falta para que el sistema deje de depender de quien lleva más tiempo. Las decisiones y el marco de entrega están tratados en tres decisiones de arquitectura.

Si la fecha ya está puesta

Cuando la auditoría tiene fecha y no hay nada preparado, la prioridad es saber qué van a encontrar antes de que lo encuentren.

Eso es lo que hace un diagnóstico. Tres semanas leyendo el código y hablando con quien usa el sistema, y un informe con qué falla, qué cuesta arreglarlo y en qué orden. Cuesta 2.900 € + IVA; el proyecto que suele venir después se cierra por fases, con el precio de cada fase por escrito antes de empezar. El informe es tuyo, y sirve para llegar a la revisión con la lista escrita y también para decidir que este año no toca. Si el trabajo es reescribir la parte que no aguanta, eso es software a medida.