Vamos con la segunda y última parte del post que empezamos ayer…
3 – La velocidad y el llamado cloud
El tercer cambio venía de lo que ya decía J. Welch (el famoso CEO de General Electric) que “si no te mueves a la velocidad del mercado ya estás muerto”, y la velocidad aumentó, pero aumentó mucho, pero que mucho. Hasta el punto de que hoy lo más determinante es la velocidad en la que se desarrollan negocios basados en tecnología.
Y esto, entre otros, pasó porque llegó la época cloud, ahí 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. Y ahí si desarrollas negocios basados en software que está en “cloud”, en un app, etc., la agilidad no es moda… es supervivencia.
Ahora había que dar nuevas funcionalidades a los usuarios lo más rápido posible, impensable esperar meses, esperar a tener cerrados todos los requisitos y, además, esto de sacar funcionalidades rápido me posibilitaba para que el usuario viera rápidamente prototipos de mi negocio basado en tecnología, lo que me hacía saber qué necesitaba, por qué él pagaría, sin pasar por requisitos en papel y cerrados.
Mientras escribía esto, he estado buscando en el disco duro documentos de hace unos años, de alguna empresa para la que trabajé, y había frases del tipo a… «se entregará una versión semestralmente» ¿te imaginas eso hoy? ¿en este contexto? Impensable, estas fuera del negocio.
Bajo las anteriores premisas… ¿qué se podía hacer?
Dicho en la brevedad que permite un post, a ver, necesitamos requisitos cambiantes, y por ello planes adaptables, éxito no es tanto tiempos y presupuesto, y entra en juego hacer algo que valga para algo, y entregar funcionalidad muy rápido, para no ser expulsado del mercado, que ahora entrega servicios “cloud” y, además, para captar rápidamente necesidades… ¿qué necesito?
Pues necesitas un montón de cosas para cumplir lo anterior, pero voy a poner dos en lo alto de la lista.
La primera, un ciclo de vida con entrega de prototipos potencialmente entregable, operativos, un ciclo de vida iterativo e incremental, con iteraciones lo más cortas posibles, semanas o menos, y sin que dentro de cada iteración tenga porque haber fases lineales (tipo cascada), más bien tareas y con todo muy bien hecho, testing una actividad esencial y desde antes casi que de empezar, para que las cosas mal hechas no frenen la velocidad de las siguientes iteraciones. Así, con un montón de sinónimos de lo que queremos y si quieres un antónimo, buscamos lo contrario a un ciclo de vida en cascada.
La segunda, equipos altamente productivos y de talento. Cambiar el enfoque de “procesos” como clave para el cumplimiento del plan por “equipos”. Dejar de pensar en horas – silla y pensar en motivación. En cantidad por calidad.
Y en estas, así de resumido, está medio sector, intentando, por pura supervivencia, salir de la planificación clásica y lograr la planificación ágil. Hasta el punto de empezar a no verle sentido a la palabra planificación, ¿planificación ágil?, y hablar de un cambio cultural asentado en buenas prácticas.
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.
- Las 3 matrices de priorización Ágil - 19 octubre, 2023
- Etapas del Agile Product Management - 12 octubre, 2023
- Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023
Interesante artículo, pero hay una parte que no la entiendo:
—Cambiar el enfoque de “procesos” como clave para el cumplimiento del plan por “equipos”—
Puedes ampliar este punto por favor, lo demás queda claro pero me perdí aquí.
Cada vez que se produce un proceso revolucionario como en este caso, lo más fácil es negar absolutamente lo que se hace: planificación. Estoy de acuerdo en priorizar la dinámica que el plan, pero nunca abandonarlo.
El salto no es regresar al caos, sino superarlo. El desarrollo es en espiral, parece que que estas regresando pero en una nueva cualidad.
+
Yo creo que el problema de la metodología ágil es más profundo. Se prioriza el sacar un prototipo que pueda ser usado, con el objetivo de verificar si es lo que se buscaba. Pero por el camino se están dejando de lado aspectos tan importantes como la seguridad de los datos: recordemos que las primeras versiones de Whatsapp enviaban los mensajes en claro, por lo que cualquiera que accediese al un servidor de la app podía leer toda la información enviada por los usuarios, los cuales no habían sido advertidos de este hecho, y de haberlo sido probablemente no hubiesen usado la aplicación.
Lo siento, pero si esto es el progreso «no lo quiero».
No tienes que dejar necesariamente la seguridad de lado…
Hola Javier, tengo una fábrica de software ya hace unos años y cómo te lo has de imaginar venimos del modelo clásico, hemos hecho varios intentos para incluir la agilidad en nuestros procesos pero termina en el modelo clásico siempre. Creo que lo pertinente como tu lo mencionas es un tema de cambio de cultura para poder adoptar la agilidad como filosofía a la hora de desarrollar software. me encuentro bastante inquieto por el tema de la agilidad sin embargo encuentro un cabo suelto que no se cómo afrontar, cómo vender un proyecto en un modelo ágil?, hoy en día primero vamos levantamos unos requerimientos y aplicamos métodos como puntos de función para dimensionar el tamaño del software y transformarlo a horas hombre con las que definimos un costo del proyecto y le sumamos la utilidad esperada y así dar una cifra cerrada al cliente modelo al que nuestro mercado está acostumbrado, las dos grandes preguntas que tengo son: cómo sería el modelo de costos en un modelo ágil? y cómo vender un proyecto trabajando con agilidad?
Hola,
Tema profundo y largo para un comentario, déjame a ver si tengo un rato y lo hago post…
Saludos