Artículo escrito por: Sandra Sánchez, product manager en Claranet
Un equipo de desarrollo web tiene que lidiar, con toda probabilidad, con un proveedor de hosting. La arquitectura de su programación puede ser perfecta, el código puede funcionar según lo previsto y lo entregado aportar el valor que se esperaba, pero si el proveedor de la solución sobre la que todo ello está implementado no sigue una misma mentalidad de trabajo, todo puede jugar en su contra.
El desarrollador puede llegar a hacer tantos test unitarios como necesite pero, en la práctica, si ejecutar cada test le lleva más tiempo que pensar en cómo hacerlo, acabará por prescindir de él. Es consciente de lo que le aporta, de que es un paso necesario, pero se convierte en un impedimento en su flujo de trabajo, así que lo elimina. En otras palabras, por no tener lo más básico, prescinde de lo necesario. ¿Y qué es lo más básico? Una conexión potente en su sede, el acceso mediante balanceo de carga a un entorno saturado a peticiones o un protocolo de accesos, cambios y subidas a producción definido que contemple un plan B o incluso C, por ejemplo.
Parece lógico, pues, que debemos tener muy claro dónde alojamos los datos, de qué flexibilidad disponemos y qué nivel de servicio nos han garantizado. Es decir, si disponemos de una plataforma estable desde la que programar de forma continua y con los recursos que necesitamos, cuando los necesitamos.
Cuando el equipo ágil se convierte en cliente
¿Qué pasa cuando los programadores se convierten en clientes? Además de dar un servicio ágil, el desarrollador debe aprender a trabajar con su proveedor siguiendo los mismos principios, porque parte del valor que ofrezca dependerá de la base que haya construido para desarrollar todo su proyecto.
Cuando hablamos de arquitectura -no desde el punto de vista de software, sino desde el de la infraestructura-, para el cliente final tomar decisiones como si el servidor tiene que ser físico o cloud puede parecer una pérdida de tiempo. Pero la realidad es que cuando algo no funciona, siempre se mira a dos sitios: código o servidor. Y por muy bien que el desarrollador haya programado sus test, sus pruebas o su script de subida a producción, e incluso haya detectado rápidamente que el error no está en su código, no queda eximido de responsabilidad. Puede tratarse de recursos del servidor no controlados, de que la sincronización con la base de datos no funciona correctamente, que se haya actualizado el sistema operativo y algo haya cambiado, etc. pero llegados a este punto (y una vez resuelto), la pregunta es: ¿se puede evitar para la próxima vez? Y la respuesta es otra pregunta: ¿puede la empresa ágil convertirse en un cliente ágil?
Es un concepto curioso, porque el equipo tiene que dar lo mismo que pide. Es decir, colaboración desde el primer momento, seguimiento, diálogo constante, priorización, pruebas conjuntas… etcétera. Ser ágil significa, entre otras cosas, trabajar en equipo. Pero no en dos direcciones, sino en cuatro: bidireccionalmente con el cliente y bidireccionalmente con el proveedor. Y para ello es crucial tomar la decisión correcta al escoger dónde se alojará una web, que es algo más que un espacio donde programar: cuanto más complejo se hace un entorno, cuantos más recursos necesita, si surgen cuestiones legales, si se necesita conexión de oficina a data center o bajas latencias, entre otros factores. Se vuelve imprescindible estrechar la relación con el proveedor de hosting y conectividad. Porque los equipos y las compañías, desde el punto de vista ágil, también son clientes. Y qué mejor manera de entender a un cliente que convirtiéndose en uno de ellos.
