1.3 ¡Menudo lío!

Hoy en día, las organizaciones y empresas suelen disponer de uno o varios sistemas informáticos interconectados, que les sirven para trabajar en el día a día y poder ofrecer sus servicios y productos a los clientes y usuarios. Algunos de los programas más comúnmente usados son los de ofimática, contabilidad, ERP, CRM, etc. Quedan lejos los días en que los oficinistas usaban rudimentarias y ruidosas máquinas de escribir, ¿te acuerdas de ellas?

El desarrollo de estos complejos sistemas informáticos no es una tarea nada fácil y, por supuesto, pueden intervenir muchísimas personas de diferentes perfiles a la hora de diseñarlos, implementarlos, testearlos e implantarlos. Al contrario de lo que algunos creen, los programas informáticos no suelen estar desarrollados por una única persona, sino por equipos de profesionales que se complementan entre ellos.

Así como las empresas tradicionales habitualmente están organizadas en varios departamentos, tales como: gerencia, marketing, legal, comercial, etc., en las empresas dedicadas al desarrollo de software también podemos encontrar varios departamentos, entre ellos: gestión de producto, desarrollo, operaciones, seguridad, QA, etc. A su vez, cada uno de estos departamentos puede estar dividido en varias áreas según convenga. Por ejemplo, el departamento de desarrollo puede estar separado entre backend y frontend.

Por supuesto, hay empresas y organizaciones en las que estas divisiones no están tan claras, ya que trabajan con una estructura organizativa más plana y tienen equipos multidisciplinares que constan de personas con perfiles bien distintos: desarrolladores de backend, frontend, operaciones, etc. Por otro lado, hay empresas u organizaciones que externalizan una o varias de estas partes, por ejemplo, subcontratando a un tercero para que se encargue de la parte de operaciones y gestione los entornos de producción. Sin embargo, uno de los problemas más habituales es la falta de visión global, comunicación y cooperación entre los distintos departamentos o áreas de la organización.

Un ejemplo típico es el siguiente: los desarrolladores necesitan un nuevo entorno para desplegar una aplicación y lo piden a los compañeros de operaciones. Estos tardan unos días y finalmente se lo proporcionan. Una vez lo tienen, los desarrolladores se dan cuenta de que falta instalar una librería, por lo tanto, hacen una nueva petición para que instalen el paquete en el sistema. Al día siguiente, una vez instalado el paquete faltante, los desarrolladores consiguen desplegar la aplicación y comunican al departamento de QA que «el trabajo ya está hecho» y pueden proceder a validarlo. No obstante, aún queda un largo camino hasta poder considerar que la tarea ha sido finalizada con éxito…

Al día siguiente, los encargados de QA se quejan de que están encontrando fallos. Entonces, los desarrolladores investigan los errores reportados y concluyen que estos se producen por culpa de un puerto que está cerrado en el entorno que les han proporcionado. Así pues, piden a los compañeros de operaciones que lo abran. Pero, como se trata de un puerto no estándar, hay que pedir autorización al departamento de seguridad. Para complicar más las cosas, estos últimos se niegan, alegando que abrir ese puerto iría en contra de la política de seguridad de la empresa.

A partir de aquí, empieza una batalla campal con muchas fricciones entre los distintos departamentos, ya que todos dicen que han hecho su trabajo y no pueden hacer nada más porque ya no depende de ellos. Sin embargo, no están consiguiendo el objetivo real conjuntamente porque la aplicación sigue sin funcionar y el plazo de entrega no para de alargarse. ¿Te suena esta historia de terror?

Después de dar muchas vueltas y quedarse estancada durante días, semanas o incluso meses, la incidencia (también llamada patata caliente) va escalando progresivamente hacia niveles superiores en la jerarquía de la organización, hasta que finalmente alguien toma una decisión. A partir de ese momento, vuelve hacia abajo en forma de directrices de actuación cada vez más concretas. En un caso como el del ejemplo, quizás permitan la apertura del puerto en el firewall, cambien una política demasiado restrictiva a nivel global, refactoricen el código para que no requiera ningún puerto no estándar, o pongan un proxy por delante que use un puerto estándar, entre otras opciones.

Para que seas realmente consciente de la importancia y el impacto de todo esto, te diré que, según la Ley de Conway: «Cualquier organización que diseñe un sistema producirá un diseño que copia la estructura de comunicación de dicha organización». Por lo tanto, ¿qué resultado obtendremos si trabajamos en una organización caótica o demasiado rígida?

A lo largo del libro, propondré soluciones, estrategias, alternativas, herramientas, ejemplos, etc., para evitar errores y problemas comunes en el ámbito del desarrollo de software, además de poder minimizar las consecuencias cuando los fallos se produzcan de forma inevitable. Así pues, arrancamos motores.