Historias androides 3 – Juanito no llegaba a las releases a tiempo 🚆
Era jueves por la tarde y Juanito, uno de los desarrolladores Android de la startup, iba como loco pidiéndole a Mauricio, el backender, que hiciera unos cambios de última hora en las respuestas que se enviaban desde el servicio de la API.
Este contenido está restringido.
HAZTE PREMIUM
para difrutar de los audios y vídeos exclusivos.
Al día siguiente, viernes, había que hacer una nueva release.
Que por cierto, no sé a qué mente brillante se le había ocurrido que ese era un día estupendo como otro cualquiera para sacar los updates de la app.
De hecho, llevaban un par de semanas desde el lanzamiento del MVP a producción y aún ni siquiera se habían planteado tener un sistema de integración continua.
Por otro lado, estaba Nacho, el otro Android Developer de la startup.
Él estaba más relajado.
Se había ocupado en hacer las cosas que más valor iban a aportar a la release.
La diferencia entre ambos, no es que uno hubiera trabajado más horas que el otro.
Lo que era diferente es que Juanito se había centrado en dejar superchulas unas animaciones que le habían pedido; y Nacho, había puesto foco en lo más relevante antes de ponerse con los detalles.
Que por cierto, también le habían pedido hacer unas animaciones parecidas.
Llegó el viernes y a Juanito no le había dado tiempo de implementar la funcionalidad.
Por lo tanto, no pudo mergear los cambios a la rama principal. 😐️
Pero es que realmente, ni siquiera estaba mostrando aún los datos reales de backend por pantalla…
Nacho, que no tenía sus animaciones ni empezadas, sí que pudo mergear sus cambios.
Eso salió a producción, ya que esas animaciones realmente no eran algo fundamental, sino más bien un nice to have.
La regla del 80 20 viene a decirnos que:
Con el 20% de nuestro esfuerzo, hacemos el 80% del trabajo.
El 20% del resto de la faena, nos cuesta el 80% de nuestro empeño.
Usa esta directriz cuando te pongas a hacer… casi te diría que cualquier cosa. 😉
Y te pongo otro ejemplo aparte del de las animaciones.
Si hay que hacer un test AB para validar una nueva funcionalidad, trata de dejar fuera el 20% de lo que se haya propuesto que no sea realmente relevante y preveas te va a consumir gran parte del tiempo.
Y ese 20% ya lo completarás cuando se demuestre que es un experimento exitoso.
Si es que es el caso… 😎
El experimento cumplirá su labor, que es validar la idea.
Y no malgastarás recursos.
¡Hey! Y esto coméntalo en la reunión que hagáis de kickoff (o equivalente) de ese experimento.
No tomes tú la decisión unilateralmente sin comentarlo con tus compañeros. 😅
Haz visible lo invisible. 😉
Y de cualquier modo, en el caso de que trates de implementar el 100% del experimento, empieza implementando el 80% de lo más relevante de este.
Así minimizarás los riesgos y será más probable que entregues a tiempo.
Y ya como supertip, lo primero de todo, ponte con las cosas que te haga falta colaborar con tus compañeros.
Como por ejemplo, hacer unas llamadas al backend.
Si hay algo que haya que perfilar, le darás un margen de tiempo precioso a tus colegas para ir retocándolo mientras tú sigues haciendo otras cosas en paralelo.