viernes, 10 de febrero de 2012

Por qué fallan los despliegues en producción

Es inevitable. Parece una ley de la naturaleza. Hemos desarrollado un software con todo nuestro cariño (vale, a veces sin tanto cariño). Hemos superado con éxito los despliegues en pruebas y pre-producción, las correspondientes pruebas en esos entornos, etc (porque...¿hacéis pruebas verdad?). Y vamos a instalarlo en el entorno de producción, llega el gran día...y el gran fracaso. ¿Qué ha pasado?

No nos engañemos, la única verdad es que algo hicimos mal. ¿Qué ocurre si vamos sin lista de la compra y nos dejamos algo? ¿A quién le echamos la culpa? Oigo excusas del estilo "es que lo planificamos bien...", "hicimos todo lo que pudimos...", "es que otras personas hicieron el despliegue...", "yo es que no estaba ahí...", "a mí nadie me avisó de que esto íba a estar así...".

Planificar un software es complejo, y exige un ejercicio de experiencia, método y disciplina, para que el resultado se acerque a la realidad. Sin embargo, en raras ocasiones el despliegue, el último esfuerzo, recibe la atención necesaria (vamos, básicamente, no aplicamos adecuadamente la experiencia, el método, y la disciplina). ¿Porqué? Analicemos un poco el tema.

Habilidades Técnicas.
Esta no parece ser la causa. Aparentemente estamos preparados para todo. Somos técnicamente competentes. No hay nada o casi nada del despliegue que se nos resista.
La verdad es otra. Aunque efectivamente, no suele ser un problema grave, las habilidades técnicas adolecen de estar sobrevaloradas por nuestra parte. Nos consideramos:
  • Power developers cuando apenas sabemos programar...
  • Arquitectos cuando apenas somos buenos programadores...
  • Expertos cuando no tenemos conocimiento ni experiencia ni para llamarnos arquitectos...
Esto, que merece un post aparte, tiene especial gravedad cuando usamos para nosotros la vara de medir tamaño "mini" (cualquier cosa que hagamos, nos convierte en expertos), y para medir a los demás usamos la vara "maxi" (para que alguien se gane nuestro respeto, ha de superar pruebas que ni la mitad de hackers en el mundo superaría).
Conocimiento del Entorno.
Esta ya sí que parece ser una de las principales causas. Después de todo, si falla la instalación es porque algo se ha producido en el entorno de producción, que era ajeno a nuestro conocimiento. Unas veces será porque no había algo instalado que debía de estar. Otras será porque falta una acción sobre el entorno (configuración, carga de datos, etc.). Sin embargo, no podemos echar las culpas a los demás. Somos los primeros responsables de identificar las necesidades (requisitos), obtener toda la información del entorno (hardware, software, horarios de acceso, ventanas de trabajo, etc). Cuántas veces le echamos al cliente la culpa de que su entorno esté configurado así o asá, de que su personal no haga las cosas que le pedimos...¿Hasta qué punto es realmente culpa suya?

Falta de Preparación.
Nos sobran conocimientos técnicos. Realmente nos sobran. Somos capaces de incorporar las últimas tecnologías (aún cuando realmente sean innecesarias). Pero falta preparación. Preparación de materiales, de avisar con adecuada antelación, de identificar las necesidades y sobre todo, falta experiencia y falta método.

Hace poco, conversaba con unos colegas profesionales en un foro internacional, sobre si era mejor utilizar una checklist donde lleváramos anotadas todas las acciones al detalle...o de si la experiencia y el "olfato" de perro viejo, eran lo más adecuado. Al final, pareció llegarse al consenso de que ambos son necesarios. Esta conversación, que espero rescatar para este blog algún día, podemos trasladarla a la disyuntiva entre usar: experiencia o un proceso detallado. Por desgracia, suelen faltar ambos. Veámoslo.

Falta de Experiencia.
Cuántas veces oigo de profesionales supuestamente experimentados, excusas para culpar a otros (o al aire, porqué no), de que su software no funciona tras ser instalado en producción. Enseguida la gente pone en su currículum X años de experiencia en programación, en tal o cual tecnología, en gestión de equipos, bla bla. Pero no he visto aún un currículum donde ponga: he instalado en entornos finales de cliente más de n-cientas aplicaciones, o cosas por el estilo. Y es que falta experiencia en despliegues. No sólo es haber trabajado en docenas y docenas de evolutivos en entornos de alta disponibilidad. Además, la clave es haber participado con éxito en el despliegue. Y cuando digo participación, no me refiero a mirar y esperar a que el cliente lo instale. Me refiero a DEFINIR los pasos y actividades de instalación...a prever las consecuencias y estados de cada uno de dichos pasos, y guiar al cliente por adelantado mediante un "Plan de Instalación".

Falta de Método.
Esta causa está muy relacionada con la anterior. Falta un método. Pero un método apropiado al cliente, a sus entornos, a su personal, a sus datos, a su forma de trabajar...
Es la misma situación que una toma de requisitos. En nuestra estupidez, culpamos al cliente "de no habernos sabido contar sus necesidades". Pues no. Es culpa nuestra, el no saber extraer la información adecuada. Los profesionales somos nosotros. El cliente sólo es...eso. ¿O es que tenemos nosotros la culpa cuando el médico nos pregunta los síntomas? Pues no. Si ser equivoca en el diagnóstico, le echamos siempre la culpa a él. Para eso es un profesional.
Pues cuántas veces me tengo yo que oir en esta profesión, justo la historia al revés. La culpa es del cliente. Que no ha sabido dar los datos, la información, los requisitos...
Creo que debería de haber una rama de ingeniería en excusas. Esa no la suspendería nadie.

Falta de Gestión.
Si las dos anteriores suelen fallar, no veamos ya la gestión. En nuestra prepotencia, nos presentamos en el servidor con le paquete de instalación, y no prevemos los contenidos básicos que un buen gestor ha de preparar:
  • Plan de trabajo
  • Recursos involucrados. Recursos opcionales.
  • Estimación
  • Plan de marcha atrás
  • Plan de contingencia
  • Plan de riesgos
Si has llegado a este punto, y has esbozado una sonrisa (especialmente con lo de la gestión), y estás convencido de que no es necesario nada de esto, éste artículo era para ti. Por desgracia, hay gente que es a las buenas prácticas como el agua para el aceite. Para ellos, tengo también en mente un post con un buen listado de excusas para diversas situaciones. Como decía un antiguo compañero:


"¿Para qué vas a buscar soluciones...si puedes encontrar culpables?"

2 comentarios:

  1. Me ha gustado mucho, gran post Roberto.

    ResponderEliminar
  2. A Alex: es cierto que escribiendo con pasión se producen los mejores resultados. Pero si además se tienen los incentivos adecuados, no sé si será éxito, pero al menos me produce satisfacción. La satisfacción de que gracias al feedback que he ido recibiendo fuera de este blog gracias a este post y otros, aún hay esperanza. Porque puedo errar en algún tema, pero me consta que este post está plagado de verdades como puños. Las verdades que sólo la experiencia te hace descubrir. Y que ahora compruebo que hay mucha más gente ahí fuera que necesitaba oir esta verdad.

    ResponderEliminar