“Cuando teníamos las respuestas nos cambiaron las preguntas”
(Anónimo y popularizado por Mario Benedetti)
Como en tantas otras ocasiones, cuando me encuentro un patrón, comportamiento repetitivo, etc., en diferentes empresas, equipos, personas, intuyendo así que no es caso aislado, es más bien algo común, tendencia, este quien aquí escribe utiliza este nuestro blog como altavoz, para que otros, en circunstancias similares, no sientan el “-sólo me pasa a mí-“, vean que no son los únicos y que aquello que les pasa… realmente le está pasando a muchos.
Y dicho esto, la historia de hoy comienza así…
En el pasado, hasta hace unos 5 años, por redondear cifras, muchos de los protagonistas de esta historia trabajaban en un modelo (y, ojo, negocio) llamemos… tradicional, en términos de gestión e ingeniería software. Ciclos de vida en cascada, requisitos cerrados, testing real una única vez, al final del proyecto, y entregas de producto al cliente a muchos meses vista (resumidamente y por no extendernos).
Como todo en la vida, el desarrollo tradicional tenía sus problemas pero la cosa no iba más allá, al final se había tomado experiencia en ello, en gestión de requisitos, estimaciones, etc.
Aunque en aquella época se podría haber trabajado de manera llamemos… ágil, destacando aquí, de entre muchas características ágiles, el uso del ciclo de vida iterativo – incremental obteniendo prototipos cada pocas semanas (frente a una gran versión después de muchos meses), trabajar así no era altamente determinante para el negocio en aquellos tiempos, ya que en cualquier caso la entrega del prototipo final del producto al cliente era obligatoriamente después de muchos meses, años, ya que por aquellos tiempos nuestro producto era “instalado”, era un paquete que el cliente descargaba e instalaba en sus sistemas, en su CPD, al que nuestros protagonistas no tenían acceso (salvo caso puntual, yendo físicamente hasta allí para hacer la instalación) o, simplemente, nuestro software se vendía en los kioscos, una vez al año sacábamos nueva versión, etc. Ya sabes de lo que te hablo.
Pero el tiempo pasó y llegó lo que los modernos llaman “cloud” y los más modernos aún “nube” (por cierto, mi madre también habla de “la nube”).
Como aquí ya sabéis que no nos gusta perdernos en detalles tontos, y somos de post cortos, claros y concisos, la llegada del cloud supuso que las aplicaciones antes “instaladas” en el CPD del cliente, en sus máquinas, en todos y cada uno de los clientes, numerosas instalaciones en numerosos CPDs, pasaron a estar instaladas en un único CPD (simplificadamente, ya sé que hay CDPs de respaldo, ya, no nos perdamos), el nuestro, el del proveedor, dando servicio desde una única instalación que gestiona el proveedor a todos los clientes.
Entre decenas de cambios que esto supuso, voy a detenerme en uno crucial: en la época cloud ya no había excusa para demorar meses la entrega de una nueva, pequeña, aparentemente mínima funcionalidad, cómo sucedía en la época del software instalado.
En la época del software instalado, era razonable que yo no fuese cada dos por tres a tu CPD a instalarte una pequeña nueva funcionalidad, además esto suponía un gran problema, ya que si tenía muchos clientes, es decir, muchas versiones de mi software en muchos CPDs diferentes e iba instalando versiones diferentes en cada uno de ellos, ufff, mantener aquello, resolver las incidencias, etc., uff, era físicamente inmantenile, tenía que mantener demasiadas versiones a la vez… uff.
No se podía, o no se podía mucho, o estaba justificado mantener durante mucho tiempo dos o tres versiones del producto e ir evolucionando todos los clientes a la vez.
Por ello, por aquellos tiempos (ojo, yo esto lo he vivido), durante muchos meses se iban recogiendo las peticiones que hacían los clientes, se iba armando “LOS” requisitos que tendría la siguiente versión, se disponía de un catalogo de requisitos cerrado, se negociaba con los clientes qué entraría en la siguiente versión, qué no, que iba primero, etc.
Con la llegada del “cloud” (en el contexto en que aquí estamos) hubo quien supo ver en el cambio una oportunidad, en el problema una ventaja, en la adaptación al cambio una manera de adelantarse a los competidores, en la tecnología y en los informáticos en vez de «un mal necesario» una manera «de liderar el sector»…
Uniendo cloud + gestión ágil (iteraciones cortas, velocidad, requisitos cambiantes, etc.) + una potente y sólida base técnica (integración continua, testing del bueno, etc.), cosa que muchos de los que venían del software instalado desconocían totalmente (o desconocen) se podía añadir casi al instante nuevas funcionalidades para todos nuestros clientes. Se podía incluso experimentar con nuevas funcionalidades.
Se podía hasta hacer que en real fuesen los clientes los que nos dijesen qué funcionalidades querían y cuales no. Se podía ver que pasar a producción 10 veces al día no era una locura sino una ventaja competitiva. Con nuestro moderno «coche» ágil, y su potente motor de practicas técnicas robustas (por eso te repito tanto que te cuides del El Scrum flácido, la agilidad flácida o la agilidad de “pinta y colorea”), se podía dejar muy muy atrás a las empresas que iban en «carreta» de caballos tradicional…
Terminando la historia de hoy, con el propósito de no alargarla, la situación en la que nos encontramos hoy es que “cuando teníamos las respuestas nos cambiaron las preguntas”, cuando empezamos a saber cómo trabajar en modo “tradicional”, cuando casi que eran lo único que nos contaron en la Uni… nos cambiaron al cloud.
Y la situación más dramática es que en el modelo cloud la competitividad entre empresas de software en el mismo sector se ha desatado cruelmente. Y lo peor, para algunas (lo mejor, para otras), sobre todo en aquellas que vienen del software «instalado», es que aun hoy hay quien no ha sabido, y parece que no sabrá, cómo añadir “ágil” + “robustas prácticas técnicas” a su desarrollo en “cloud” lo que está haciendo que ya muchos empiecen a ver que aquello de lo ágil no era una moda… era la clave para sobrevivir.
NOTA: Recuerda el 20 y 21 de Mayo, tienes una cita obligatoria con la Agilidad, la gestión de Equipos Eficientes y el Peopleware.
Un curso presencial de Scrum Master con certificación oficial por Scrum Manager.
Toda la información aquí.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Uno de los problemas a resolver del SW en cloud es la poca flexibilidad para extenderlo con funcionalidades a medida o integración con otras herramientas de la empresa. Esto a veces provoca que la empresa tenga que adaptar sus procesos a la herramienta y no al revés, como debería ser.