El otro día me me enfrenté a una situación dentro de un proyecto que no deja de ser el día a día, pero me apetece compartirla con vosotros. La cosa fue que un bug en producción nos sorprende antes de entregar a cliente.
Os pongo en contexto.
Resulta que trabajo desde hace tiempo en un proyecto muy grande, continuo en el tiempo durante muchos años.
El producto está desplegado y lo utilizan más de un millón de personas.
Periódicamente se desarrollan nuevas funcionalidades o ampliaciones del producto en las que esta fase o sub-proyecto suele durar un par de meses.
Hola, soy un bug bloqueante en producción
Pues la cosas está en que justo antes de una de estas entregas a cliente con nuevas funcionalidades nos sorprende en producción un bug bloqueante.
Entonces, oh! problema… ¿cómo hacemos frente a las dos cosas?
El jefe de proyecto nos reunió a mi como responsable de pruebas y al equipo de desarrollo para valorar las opciones.
Teníamos dos días para que desarrollo analizara el problema, diera la solución y se realizaran las pruebas de verificación.
¿Qué opciones tenemos?
- 1. Entregar el proyecto por un lado y el bug urgente por otro. Esta opción es más cara que si metemos en el proyecto el bug bloqueante de planta. Pero también más segura, ya que no haces depender una cosa de la otra.
- 2. Entregar los parches de software con las nuevas funcionalidades más el arreglo del bug. De esta manera se ahorra una entrega (tiempo y dinero) pero se añade riesgo al proyecto de las nuevas funcionalidades.
¿Qué es lo aconsejable en este caso?, ¿hacemos todo lo posible por entregar la solución del bug aprovechando la entrega a cliente de las nuevas funcionalidades? o ¿se hacen las cosas con más tiempo y sin prisas entregando por separado?
¿Cómo lo ves tú?, ¿cómo orientarías este caso?
Solución…
Pues como te podrás imaginar, la respuesta más adecuada a este caso, es …. Depende.
Depende mucho del bug. Tanto de la complejidad de implementar la solución, como de la complejidad de cubrir las pruebas de verificación.
Depende también de la prisa que tenga el cliente. Si este bug hace que pierdan millones de euros al día… la situación sería diferente de si es simplemente algo cosmético.
En nuestro caso, por la naturaleza del problema y por la situación del cliente se optó por introducir la solución en la entrega con la nueva funcionalidad.
Hizo falta un compromiso por parte de desarrollo y por nuestra parte de actuar con rapidez.
Se vio claro y se optó por la solución menos conservadora.
En este caso, desde el punto de vista de pruebas, tuve que tener en cuenta dos cosas:
- Valora si se podía hacer frente a las pruebas necesarias para la verificación con los recursos disponibles.
- Y muy importante, hacer ver el riesgo que introducía en el proyecto meter la solución a un bug con el tiempo justo para desarrollarlo y el tiempo justo para probarlo. Había que ser consciente de que si optábamos por esta opción y algo de lo entregado no funcionaba teníamos muy poco tiempo de reacción para otra re-entrega.
Si todo salía bien podía dar tiempo a entregarlo todo, pero si algo se torcía (desarrollos que no funcionan o problemas de maqueta para probarlo), podíamos quedarnos sin la solución al bug y poniendo en peligro la entrega de las nuevas funcionalidades.
Al final todo salió bien, los desarrollos funcionaron a la primera y las pruebas salieron bien sin muchas complicaciones.
Pero eramos conscientes que esto podía complicarse… Que es lo realmente importante, si tomas la decisión más arriesgada tienes que saber a qué te enfrentas si algo sale mal.
Sin mucho más me despido, espero que esta pequeña reflexión te haya parecido interesante, y estaré encantado de que compartas tu punto de vista en los comentarios.
¡¡Muchas gracias por pasarte por aquí!! y… ¡¡Feliz búsqueda de defectos👾!!
Deja una respuesta