La subida a producción es un momento muy importante para el equipo software. A partir de ese momento , se pone nuestro trabajo a disposición de los usuarios para que lo puedan utilizar. Si aplicamos Scrum en un contexto no tecnológico, sería el momento en el que entregamos el trabajo para la persona que desea recibirlo. A partir de ahí, se producen varios cambios. Por un lado, ahora nos van a evaluar, sobre todo la primera que subamos, y pasamos de la nada a la novedad, por tanto, es el momento de máximo feedback. Por otro lado, empezamos a compaginar lo ya existente con nuevo desarrollo, así, la manera de relacionarnos con los clientes cambia, ¿arreglo esa incidencia o me dedico a la nueva funcionalidad que queremos lanzar? Además, podremos empezar a medir el uso que nuestros clientes hacen de nuestro producto, los medidores empiezan a cobrar sentido.
El paradigma tradicional es esperar hasta el final, gastar todo el dinero para acabar lanzando un producto completo que enamore al usuario. Esperar hasta el final es un riesgo ya que, si te has equivocado, no lo vas a saber hasta etapas tardías en la que es más costoso arreglar las cosas o ya no te queda presupuesto para rehacerlo. Por eso, es importante que hagamos subidas periódicas para saber si nuestro software va por el buen camino. Sin embargo, hay muchos más beneficios cuando un equipo sube de manera contínua en el tiempo, los vamos a analizar.
Subir a producción nos permite obtener feedback temprano
El motivo más importante para subir a producción pronto es validar el impacto que tiene nuestro trabajo con respecto a los usuarios. Siempre hablamos de que Scrum maximiza el valor, siendo este concepto a criterio del usuario. Por tanto, hasta que un usuario no lo tiene delante, no sabremos si hemos creado valor.
Un equipo Scrum que funciona es aquel que pivota sus decisiones en base al impacto que tiene su software en los usuarios. ¿Les ayuda a mejorar sus vidas? Fíjate, en la mayorías de aplicaciones exitosas que usamos todos los días, se van incorporando mejoras a base de peticiones de los usuarios.
El videojuego de triunfó gracias a su construcción iterativa e incremental
El 21 de Diciembre de 2017 es el día oficial en el que el juego PlayerUnknown’s Battlegrounds salíó a producción. A tan solo 10 días de acabar el año, fue el videojuego más jugado en la plataforma Steam en 2017. ¿Cómo fue posible? El estudio que lo creó era pequeño, y con poco reconocimiento. No podían permitirse el lujo de invertir muchos millones durante mucho tiempo para crear un videojuego, y rezar para que los usuarios lo apreciaran y pagaran por él. Decidieron un cambio de estrategia. Sacaron una primera versión del juego muchos meses antes, y le dijeron a los usuarios que “propusieran mejoras”. De esta manera, los propios jugadores podían solicitar mejoras que se iban creando de manera iterativa y que permitía al estudio ofrecer un producto que tuviera éxito en el tiempo.
De esta manera, un pez pequeño es capaz de superar al grande. Muchas grandes empresas siempre comentan que tienen que incorporar una mentalidad de startup. El ejemplo del PUBG y su capacidad de adaptación es incompatible con la mentalidad de control de costes y de foco en el trabajo de las personas, y en el resultado de su trabajo. Inspeccionar y adaptar para convencer a tus usuarios y mantenerlos enganchados, ahí está la clave.
Subir a producción elimina incertidumbre
El segundo motivo por el que una subida a producción temprana nos puede ayudar es la eliminación de incertidumbre. En muchos equipos en los que he participado, cuando dejábamos para el final las pruebas y la subida, encontrábamos muchos impedimentos inesperados que lo convertían en un infierno. Hay un gran trabajo oculto que desaparece cuando hacemos una subida, y esto nos permite ser más realistas para gestionar las expectativas de nuestros usuarios. Incluso, aunque estemos en el paradigma de “éxito por entrega en fecha”, el resolver la subida pronto nos da información real de lo que puede suponer el trabajo que nos queda por hacer.
Aunque lo que subamos (Integración) no se lo demos a los usuarios (Delivery), el hecho de haber recorrido todo el camino: máquinas que no conocemos, documentación mal redactada, integración con otros departamentos, managers que no responden… Todo esto se elimina “llegando a producción”.
El avance minimiza la tensión con los clientes
Otra de las ventajas que conseguimos al subir a producción de manera contínua es la sensación de avance. El hecho de que poco a poco estamos construyendo un productoayuda a transmitir la idea de avance, y esto suele tranquilizar a un cliente. Recordemos que en la estrategia tradicional, al cliente lo hacemos partícipe al principio, en la fase de definición. Una vez estamos construyendo un producto, solemos dejarlo de lado hasta casi la fase final.
El hecho de que, cada vez que nos sentamos con un cliente, este pueda ver un avance y evaluarlo, nos permite relajar tensiones. Esto no es garantía de éxito, ya que muchos clientes necesitan un software en fecha y, aunque vean avance, su expectativa está intacta.
Subir a producción para medir el software terminado
Uno de los principios del desarrollo ágil de software es utilizar el software terminado como principal medida de progreso. Para un equipo, el hecho de avanzar con funcionalidades acabadas también le genera sensación de progreso y suele ser positivo. Además, podemos medir nuestra capacidad de entrega y eso nos ayuda a proyectar fechas de delivery o hitos que tengamos que afrontar.
“Medir software terminado” solo se puede hacer cuando la estrategia de nuestro equipo es la de subir a producción de manera contínua. Cada vez que tenemos funcionalidades terminadas, podemos medir nuestro avance real. Hay equipo que miden puntos de historia o software construído, pero si no está en producción, puede haber trabajo oculto que nos estemos dejando fuera: pruebas, integración con otros sistemas, despliegues…
Una manera de medir software funcionando es medir el número de PBIs por Sprint que terminamos. Además, estos PBIs deben cumplir la DOD que garantice que no dejamos trabajo sin hacer.
Generamos presión “positiva” si tenemos que subir a producción
El hecho de dejar las cosas para el último momento genera un agobio en los equipos. En entornos tradicionales donde el éxito es llegar a producción en una fecha, la única opción que nos queda es bajar la calidad. Esto redunda en retrabajo, y en no sentirnos orgullosos del resultado de nuestro producto o del servicio que este presta.
Sin embargo, hay una manera más positiva de generar confianza en el equipo. Si sabemos que haremos una subida y que se primará la calidad al alcance, muchos equipos se motivan por el hecho de tener que terminar cosas que van a ser útiles. Al hacerlo de manera contínua, podemos generar la sensación de equipo unido prestando servicio y siendo capaces de cumplir nuestro propósito.
Los equipos más maduros que he podido acompañar son aquellos a los que les importaba el resultado de su trabajo. La mejor manera de conseguirlo es subir a producción cada poco tiempo y, así lograr que, de verdad, los usuarios puedan evaluarnos y nuestro trabajo adquiera sentido.
Y tú, ¿cada cuánto subes a producción?
