Equipos y Respaldos

Dicen que Napoleón Bonaparte se organizaba de este modo:

“Si quieres que las cosas se hagan, nombra un responsable; si quieres que las cosas no se hagan, nombra un comité”.

Probablemente te tocó, desde la primaria hasta la universidad, ese clásico escenario donde alguien del equipo no hacía nada. Lo peor es que la mayoría de los maestros obligaban a que los trabajos se entregaran en equipo, prohibiendo hacerlo solo. El argumento de siempre: “es para que aprendan cómo funciona el mundo real”.

En la vida real, los jefes de equipo no necesariamente tienen el título por capacidad. Hay líderes de proyecto que están ahí por ser el primo, el hermano o el crush de alguien.

En el mundo real, aunque existan equipos, tu Plan B siempre debe ser un plan de trabajo que puedas ejecutar solo. Si estás en una empresa, hazlo como hobby.  Cuando fracasen, ofrece tu solución cuando te pidan arreglar el problema.

Como dueño de empresa o consultor, muchas veces puedes elegir a tus colaboradores, pero la lógica te dice que “todo el mundo quiere prosperar”. Pues no.

La mayoría de la gente ya sabe que llegó a su tope. Tienen sueños guajiros, sí, pero lo que realmente les preocupa es conservar el puesto o demostrar una fortaleza que no tienen. En vez de defender que su área o empresa haga un trabajo tan bueno que llame la atención, vas a ver muchísimos casos donde el responsable del área solo estorba. Te ponen metas imposibles en tiempo, dinero o alcance.

Por ejemplo, viendo vacantes actuales para la sección “Donde no trabajar”, están ofreciendo sueldos iguales a los de hace 17 años.

¿Qué tiene que ver esto con los equipos? Mucho. Mucha gente contrata “lo que puede”. He visto grupos de 5, 10 y hasta 20 programadores que no hacen nada; programan cosas que nadie quiere usar. Según ellos, usan ChatGPT, pero a la hora de la verdad, es una batalla entre tú, el programador o jefe solitario,  contra un montón de personas que solo se estorban entre sí.

Una de las cosas más importantes, siempre que puedas, es sacar respaldos de manera coherente. Por ejemplo, si haces cambios al sistema cada 7 días o muy poco, no pasa nada si no respaldas diario; pero si los usuarios capturan archivos y datos cada hora, tienes un problema potencial si no eres meticuloso.

Reglas de coherencia para tus respaldos:

• A) El crecimiento de la base de datos: Si tu base de datos crece normal, la ideal es respaldar diario (o dos o tres veces al día). Un tip vital: revisa que el archivo esté bien. Usa algo como 7-Zip para verificar que el archivo comprimido no esté corrupto. Un respaldo que no abre no es un respaldo, es basura.

• B) Documentos pesados y conexiones lentas: Si en tu trabajo suben archivos enormes a una estructura de directorios o a una segunda base de datos, sé realista. Si la conexión a internet es mala, aunque quieras respaldar diario, lograrlo una vez a la semana ya es un triunfo. Prioriza lo que es crítico.

• C) Proyectos y documentación: Los proyectos funcionales terminados y toda tu documentación también deben tener su propio respaldo independiente.

El respaldo como cláusula de supervivencia

Como consultor, uno de los puntos que incluyo en mis contratos es el derecho a tener un respaldo propio en mi domicilio. Esto lo justifico por cuestiones de continuidad del servicio y “negocio en marcha”, comprometiéndome, por supuesto, a tratar la información con total confidencialidad y cuidado.

Casos reales donde el respaldo me salvó la vida:

1. Robo total: Una empresa perdió todo físicamente. Mis respaldos los salvaron. El último era de las 18:00 p.m. y mi servidor personal tenía la copia adicional que permitió levantar todo de nuevo.

2. El colapso del 24 de diciembre: Un servidor colapsó su disco duro a las 11:12 a.m. un 24 de diciembre de 2012. Gracias al respaldo de las 8:00 a.m., solo perdimos tres facturas. El impacto fue mínimo.

3. El desastre en la Paraestatal: El área de sistemas borró por error la base de datos de una dirección con 400 personas. Se perdió el trabajo de meses de toda esa gente. Nosotros no. Mi respaldo de las 8:00 a.m. hizo que solo perdiéramos cuatro solicitudes ciudadanas que pudimos reconstruir fácilmente.

El Arte de la Guerra (y el CYA Cover Your assets)

Sin embargo, a veces el enemigo no es el código, sino la burocracia o la negligencia. Aquí tres lecciones de supervivencia:

A) El correo que te salva del desastre

En 2010, en una empresa de comunicaciones satelitales, el internet era lentísimo porque todos estaban en YouTube escuchando a Juan Gabriel. Me prohibieron sacar respaldos para “no saturar la red”.

¿Qué hice? Mandé un correo a tres directores de área informando que, por instrucciones de “X”, ya no se sacarían respaldos del área bajo mi cargo. Aclaré que solo respaldaría proyectos especiales desde mi casa (vía VPN) entre las 7:00 PM y las 6:30 AM. Resultado: Adivinen quién perdió todo y a quién trataron de echarle la culpa. El correo fue mi escudo.

B) El respaldo como “Servicio al Cliente” (o de emergencia)

Un cliente de facturación perdió archivos críticos de hace tres años. Su propio contador no tenía respaldo de las llaves FIEL (e.firma). Yo aún los conservaba en el WhatsApp de un teléfono de respaldo que guardo para esos casos. Esa “obsesión” por el respaldo me hizo el héroe de una situación ajena.

C) Protocolos de destrucción y auditoría (CYA)

¿Qué haces cuando necesitas destruir algo o dejar un área? Protocolo. En un trabajo hice un sistema de documentación en un foro MyBB. Me cambiaron de área para que alguien más se “adornara” con mi trabajo. Yo seguía siendo el admin y sabía que el servidor era vulnerable por falta de actualizaciones.

1. Mandé un correo sugiriendo borrar la información por ser datos sensibles no actualizados, ya que el flujo de trabajo de la persona nueva no lo usaba.

2. Fui físicamente a preguntar a tres personas clave y regresé a enviar otro correo: “Como me confirmaron X, Y y Z que ya no necesitan el sistema, aviso que en 10 días se borrará todo y eliminaré mis propios respaldos”.

3. Consecuencia: En la siguiente auditoría sacaron -10. Todo lo que les permitió pasar la auditoría tres años antes era ese repositorio que decidieron ignorar.

D) “Un cliente que no paga, no es cliente”

En la misma paraestatal del caso anterior, ante la falta de pago, envié este correo:

“Estimada jefa: Como sabe, la falta de pago de los últimos cinco meses está causando problemas en la operación. Ya no es posible para mí mantener ese servidor funcionando. Por falta de pago, el servidor será destruido el día 12 del próximo mes de manera automática. Sugiero que coordinen un respaldo, ya que la conexión aquí es muy mala…”

La IA no te salva del olvido (ni del apagón)

Al final, en la paraestatal se quedaron sin sistema. Pero no creas que esto solo le pasa a las grandes instituciones; probablemente tú también vas a perder información.

A veces te haces un soberano desastre con lo que generó la IA, o la conversación se volvió tan larga que el contexto se perdió, o simplemente cerraste la ventana, se fue la luz y ya no sabes qué pasó.

El caso del archivo fantasma Hace como un mes se me fue la luz mientras trabajaba. Según yo, el documento .docx de Word que estaba haciendo tenía respaldo automático. Tuve que salir y lo busqué tres días después: nada en mi máquina. No estaba en archivos temporales ni en la nube.

¿Dónde creen que estaba? En el historial de Copilot. Lo había pegado ahí para una revisión de ortografía y esa ventana del chat fue lo único que sobrevivió al apagón. La IA, sin querer, fue mi respaldo de última instancia.

El peligro de “subir y olvidar” Imagínate que haces un proyecto excelente, con un archivo adicional crítico, y lo subes al directorio de producción. Justo en ese momento, alguien decide restaurar un respaldo viejo o reconstruir el servidor sin avisarte.

Resultado: Lo que acabas de subir se borra de la existencia. Yo he podido recuperar archivos en situaciones así por una sola razón: tenía un respaldo local de ese archivo específico.

Conclusión del Artículo: Domando la Contingencia

La IA es brillante para generar, pero es pésima para recordar por ti a largo plazo si no gestionas los outputs. Domar la caja negra no es solo saber pedirle código; es saber que ese código es volátil.

Si no tienes un sistema de respaldos coherente (local, externo y contractual), estás trabajando sobre arena movediza. En este mundo, no sobrevive el que más código genera, sino el que tiene el respaldo listo cuando el servidor —o el jefe— deciden colapsar.

El respaldo de la IA es solo una pieza del rompecabezas

Como ejercicio, el pasado miércoles 25 en la sección “Pruébalo hoy”, hicimos un proyecto sobre cómo gestionar específicamente tus respaldos de archivos generados por IA. Es útil, sí, pero no te confundas: no es el único respaldo que importa, ni el más importante. https://vibecodingmexico.com/organizador-de-ias/

No olvides que antes de la IA, está la infraestructura real. Debes respaldar:

1. Tu propia máquina: Donde vive tu entorno de desarrollo.

2. Las bases de datos: El corazón de la información de tus clientes.

3. Los servidores: El código, los archivos que genera y donde realmente corre el sistema.

El respaldo de lo que hiciste con la IA, o de lo que la IA te entregó, es solo uno de tantos. Si tienes el código de la IA pero perdiste la base de datos de producción porque “no era prioridad”, de nada te va a servir el prompt más sofisticado del mundo.

Domar la caja negra es entender que la tecnología cambia, pero la responsabilidad sobre los datos es permanente.

Autoridad y Responsabilidad: Las dos caras de la misma moneda

Recuerda siempre: la autoridad va de la mano con la responsabilidad. Siempre. Si te quitan la autoridad para tomar decisiones técnicas (como prohibirte sacar respaldos), debes documentar de inmediato que la responsabilidad de las consecuencias ahora es de ellos.

Pero ojo: no lo hagas con palabras agresivas ni por WhatsApp. Usa el correo institucional. Si el protocolo lo permite con copia oculta a tu correo personal. El WhatsApp se pierde, se borra o “no se vio”; el correo institucional es un registro formal que sobrevive a las auditorías. Si la “Caja Negra” falla, que no sea por tu culpa. Y si falla porque no te dejaron domarla, asegúrate de tener el comprobante de que tú avisaste exactamente dónde estaba el problema y quién decidió ignorarlo.

• Nota: Existe un Software llamado Barracuda, que no recomiendo usar, sobre gestión de correos. En un lugar me pasó que el de sistemas saboteaba mis envios de correo a mi jefe inmediato por el institucional, así que la copia a tu propio correo, debe ser a un gmail por lo menos.

Corolario: El arte de cubrirse la espalda

Si sientes que el equipo o los jefes te están estorbando, no te limites a quejarte. Cubre tu responsabilidad de forma técnica y documental. Debes dejar evidencia clara de por qué haces las cosas y, sobre todo, de por qué NO las haces (cuando te lo prohíben o te limitan). Un correo enviado a tiempo, un respaldo bajo llave y un protocolo de destrucción avisado no son actos de rebeldía; son actos de profesionalismo en un entorno que a veces no lo es.