¿Cuándo fue la última vez que hiciste algo nuevo “a la primera”? ¿Era medianamente complejo? Piénsalo de nuevo y déjame adivinar… ¿La respuesta es “nunca”?

Por eso mismo, porque cuando nos enfrentamos a una “primera vez”, y más si es algo complicado, rara vez sale bien a la primera. Si esto lo extrapolamos al sector TI, la conclusión es que es necesario iterar para obtener el resultado deseado.

Y aunque sepas hacer una paella de marisco estupenda, el primer día que la haces en tu apartamento de vacaciones o en casa de un amigo no te queda igual de bien… ¿me equivoco?

El enfoque natural, la perfección por la repetición

La alternativa que siempre nos han presentado ante ese tipo de situaciones es realizar un análisis detallado, una planificación con muchos hitos y las dependencias bien identificadas: conseguir el conocimiento, trazar un plan inteligente y aplicarlo sin apartarnos de él hasta llegar al resultado especificado. Suena bien.

En nuestro ejemplo paellero esto supondría estudiarse el manual de la cocina y el de la nueva paellera para saber cuánto calor genera la primera y cómo es difundido por la superficie de la segunda.

El procedimiento no acaba ahí. También deberíamos obtener los estudios científicos que se hayan hecho sobre cómo cocer distintos tipos de arroz con el agua de la zona... y un par de días después (con mucha hambre) podríamos decir que estamos preparados para empezar a cocinar.

Sería un proceso largo, sin garantías de que en algún momento tengamos la comida y con un ROI (quitar el hambre y con suerte disfrutar de su sabor) que puede venir demasiado tarde… y no olvidemos que los requisitos cambian, porque puede que el día de antes, cuando ya tenías los cálculos hechos, se apunte tu cuñado… ¿siguen siendo válidos los cálculos si en lugar de cuatro somos ocho?

Ante esta situación absurda, en la vida real nos “ponemos manos a la obra”, hacemos la paella y aprendemos para la siguiente. En el peor de los casos, la primera no nos saldrá muy bien (pero habremos comido) y en la segunda y la tercera, los resultados ya serán excelentes. Iteración y adaptación.

Lo absurdo de muchos proyectos de TI

Cuanto más rápido puedas iterar, más rápido podrás aprender y más rápido se obtienen los resultados deseados. Y, sin embargo, el enfoque predictivo aún es el más extendido para proyectos TI.

Y cuanto más grande es el proyecto, con más ahínco se persigue un enfoque cerrado. ¿Por costumbre? ¿Por imitación?

Cuando reflexionamos, se nos da una justificación que no es mucho mejor: vamos a gastar mucho dinero y queremos garantías de que recibiremos aquello por lo que estamos pagando.

Y efectivamente lo recibimos: un proyecto sobresaturado de gestión, enfrentamientos por la interpretación de los requisitos y un montón de planificaciones revisadas.

Por lo demás, la realidad es tozuda y los sucesivos retrasos en la entrega final deberían hacernos pensar que finalmente sí nos vemos “forzados a iterar”, aunque no sea una iteración productiva: lista de ajustes pendientes, entrega apresurada e insatisfactoria con baja calidad, especificación revisada e informe de fallos.... ¿Nos suena esta situación? Por supuesto que sí, y aún así se repetirá el enfoque para el siguiente proyecto.

Si hemos de ser sinceros, hubo un tiempo en el que el enfoque predictivo era el único disponible para proyectos de TI. Y es que este tipo de enfoque es justificable únicamente en dos situaciones (los ejemplos son matizables y sujetos a discusión, pero sirven para ilustrar el concepto):

• Cuando el coste del cambio es muy elevado: si construimos una casa, no podremos construir una planta más si no lo tuvimos en cuenta al construir los cimientos o no podremos llevar la cocina al sitio previsto para el salón, porque no tendremos las tuberías necesarias.
• Cuando el coste del test/fallo es muy elevado: nadie piensa en hacer test A/B sobre el software de control de un reactor nuclear.

hbspt.cta.load(2189055, '7317a215-fbd1-4cc3-a54d-afee694a88f7', {});

¿Qué hace posible el cambio en la gestión del negocio?

En los comienzos de esta industria, las herramientas disponibles tenían un alto coste en ambos aspectos (coste de cambio y coste de fallo):

• En desarrollo: los comienzos fueron duros. En las tarjetas perforadas los bugs se corregían con celo (¿tiene ahora sentido la palabra “parche”?) y cuando querías ejecutar tu programa, ya fuera para probarlo o para obtener los resultados, debías pedir cita (literalmente). Y, sin embargo, hace más de 25 años que los principales entornos de desarrollo disponen de la facilidad de “refactorización” que permiten, precisamente, reorganizar código sin modificar la funcionalidad, de manera que sea posible obtener arquitecturas más sofisticadas con cada iteración. Por otro lado, el desarrollo dirigido por pruebas o los servidores de integración continua son herramientas comunes y extendidas.
• En infraestructura: asociado a cada nuevo proyecto solía ser necesario dimensionar (planificar) los nuevos (y caros) servidores hardware con compra de licencias y soporte, y con espacio reservado en CPDs corporativos aún más caros. Cloud y DevOps han revolucionado este enfoque. Puede que hayas leído sobre “la nube”, PaaS, IaaS, etc., pero si no sabes qué significa para ti o para tu proyecto “infraestructura como código” tu reloj sigue en el siglo XX. ¡No vale utilizar Cloud o entornos virtualizados y seguir utilizándolos como si fuesen máquinas físicas!
• En organización: puede que sorprenda, pero todo esto de la corriente ágil ¡no tiene su origen en el mundo del software, sino en algo tan “planificado” como la cadena de montaje de automóviles! Existe una rica variedad de métodos ágiles, porque existe una amplia tipología de proyectos software… Por ello, hay que conocer todos los métodos, porque todos funcionan y debes elegir el que mejor se adapte a ti. Todos comparten unos principios comunes expresados en el “Manifiesto ágil”, pero no todos sirven para todos los proyectos. Scrum o Kanban pueden ser los más conocidos en proyectos de mantenimiento, Scrumban como híbrido entre ambos... hasta llegar a Scrum of Scrums, Nexus o SAFE en entornos en el que el volumen del equipo es tan grande que necesitamos escalar sin perder agilidad.

En Paradigma llevamos varios años utilizando las herramientas adecuadas para abordar iterativamente los proyectos de TI.

Lo cierto es que no basta con tener las herramientas, ni siquiera con utilizarlas, hay que hacerlo de la manera adecuada y eso significa utilizarlas todas para lograr la flexibilidad total.

De nada sirve utilizar Scrum para el desarrollo si necesito esperar 2 meses por el nuevo servidor, o si un cambio en la base de datos no lo puede realizar el equipo, sino que ha de solicitarse al departamento correspondiente...

Curiosamente, la parte tecnológica, la que suele sonarnos más extraña, es la que más fácilmente se aplica. Incluso los cambios organizativos se aplican con cierta facilidad a nivel de proyecto: el reto está en aplicar la (verdadera) Transformación Digital a nivel de toda la organización y trabajar “organizados por proyecto” y no “organizados por departamento”.

¿Por qué hay empresas que se resisten a este cambio positivo?

Realmente, sólo hay un motivo por el que ciertas organizaciones siguen un enfoque predictivo, planificado y no iterativo para sus proyectos de TI: y es que el resto de la organización funciona así. De manera que, en lugar de agilizar el resto de áreas, la solución que se toma es anquilosar y constreñir este tipo de proyectos con burocracia alrededor del grupo ágil.

En un momento en el que se ha demostrado que las nuevas empresas tecnológicas irrumpen y conquistan cualquier mercado, por muy tradicional que nos suene (automoción, transporte, alojamiento, productos frescos...) la clave es liberar la agilidad de los procesos de TI para contagiar al resto de la organización y no al revés.

Tu negocio es una tarea compleja y tu proyecto es algo que no se ha hecho nunca antes y para lo que no existe ni puede existir un plan.

Es necesario iterar, porque es necesario adaptar el alcance a los cambios (siempre hay cambios) del mercado, del gusto de los usuarios, de nuestro negocio, de la tecnología, de la regulación...

Ahora que las herramientas están disponibles, hay que tener el coraje para vencer las resistencias internas y las tradiciones que nos atan. Hay quién lo llama Transformación Digital.

Si “la vida es lo que te pasa mientras estás ocupado haciendo otros planes”, “el negocio es lo que te pierdes mientras estás ocupado con un proyecto de alcance cerrado”.