Ingenioso vs. Hacer las Cosas

15 de octubre de 2010 • 2 min de lectura

Hay un equilibrio delicado entre hacerlo bien y entregar.

Dirijo un equipo de 8 desarrolladores. Cada hora que el equipo está bloqueado son ocho horas de desarrollo perdidas.

A un compañero de trabajo se le asignó la tarea de conseguirme una base de datos. Después de dos días de espera, pregunté sobre el estado. Dijo que estábamos teniendo problemas con la importación de datos. Cuando hizo el script de los datos, pesaba casi un gigabyte. Un gigabyte era demasiado para subir a subversion. Estaba buscando un método alternativo.

Pasa otro día. Le pregunté cómo iba. Dice que ya casi está listo. Ok genial, llevo tres días perdidos, 192 horas de tiempo de desarrollo perdido. Estoy ansioso por empezar. Mi equipo está sangrando horas.

Al cuarto día, está listo. ¡Por fin! Me envía el proyecto de base de datos y los scripts de importación de base de datos. Está usando PowerShell y BCP para importar los datos. Se los envío al equipo con instrucciones detalladas.

El equipo está 12 horas adelante de mí, en India. El ciclo de retroalimentación es de 12 horas. Toma 24 horas poner cualquier cosa en marcha.

Como dice la Ley de Murphy: “Todo lo que puede salir mal, saldrá mal”. El equipo ejecutó los scripts de importación de datos y se encontró con el fracaso. Los scripts de Powershell fallaron, un problema de seguridad impidió la importación de datos.

Llevo cinco días de retraso. Se han perdido 320 horas. La fecha límite se acerca, necesitamos empezar.

En este punto, necesito poner la base de datos en funcionamiento para el equipo. En mi máquina, desconecto la base de datos, la comprimo en zip y se la envío al equipo. Todos los desarrolladores saben cómo volver a conectar una base de datos. En una hora de recibir la base de datos, los ocho desarrolladores tienen una base de datos funcionando. ¡Éxito!

Crear un proceso ingenioso está bien, pero a veces simplemente hacer el trabajo es más importante que ser ingenioso.