Historia de mi primer proyecto fallido y mis aprendizajes en gestión de proyectos

🤔 ¿De qué se trataba el proyecto?

Mi enfoque técnico principal ha sido en frontend.  Durante años trabajé en una web-app para gestión de práctica médica (agenda, expendiente médico y más).

Hace unos 5 años, tuve la oportunidad de proponer y liderar un proyecto.

Tenía 6 semanas para hacer que un app compleja y crítica para los usuarios, de capacidades offline.

Pero todo se tornó extraño, cuando me dí cuenta de que iba a ser líder de un equipo de 1 persona (yo) y el 5% de otra (Diseño de Producto).

No pintaba bien, pero decidí intentarlo de todos modos.  Al final la vida es de experiencias ¯\_(ツ)_/¯

El proyecto transcurrió entre expectativas confusas, perseguir el 5% de ayuda de alguien y efectivamente hacer que nuestra app funcionara sin internet.

💡¿Qué salió mal? ¿Qué haría diferente?

Al cabo de 6 semanas, efectivamente fue posible ingresar a nuestra app y recargar la página aún sin internet.

Pero el proyecto fracasó.  Por estas razones:

#1 Expectativas

6 semanas era tiempo suficiente para establecer fundamentos.  Bases para entregar valor progresivamente.  Al cabo de seis semanas, nuestra app podía cargar sin internet, pero nada más.

No había agenda, no había sincronización entre usuarios, etc.

¿Qué haría diferente?

Decir que no.  O al menos ser muuuy realista sobre lo que realmente se puede lograr.  No hace daño.

#2 Proyecto "técnico", que no era técnico

El código necesita mantenimiento, mejoras y demás.  Nacen nuevas tecnologías, que ameritan actualizaciones.

¿Qué haría diferente?

Este no era uno de esos casos.  Implicaba pensar en una experiencia disinta para los usuarios y muchos escenarios que no existían.

No nos alcanzaban los roles para entregar algo así.  Se necesitaba más ayuda.

#3 Estabilización

Entregamos a producción al filo de las 6 semanas.  El rendmiento del app se vio afectado, así que deshabilitamos el feature para corroborar.

Sí encontramos una afectación, pero descubrimos un bug no relacionado que afectaba mucho más.  Peeero, durante el proceso, no quedó tiempo para habilitar la funcionalidad de nuevo.

¿Qué haría diferente?

Asegurarme de tener suficiente tiempo para estabilización antes de hacer release.

#4 Enfoque

Mi reacción inicial al ver que no nos alcanzaban las manos, fue ir a escribir código como si no hubiera mañana.

No comunicación, no actualizaciones constantes.  Solo código.

¿Qué haría diferente?

Empezar por la comunicación.  Aunque no tuviera un equipo, había gente fuera pendiente del resultado.

Si no les digo que algo anda mal, pensarán que nada anda mal.

Fallé como líder, no por no tener un equipo; sino por no adaptarme.

--

Bottom line, es un punto trascendental al ganar senioriy.  Comprender que un proyecto dentro de un equipo es más que un output.

Si entre tu equipo y el objetivo hay un precipio, hay que empezar por construir un puente.

Parece obvio, pero a veces no lo es.

Toca aprender a sacar la cabeza del agua.