intive Argentina Blog

Guía práctica para lidiar con un proyecto de mierda

A todos nos toca. Nadie se salva. Nos excede. No lo deseamos, pero, a veces, nos es ineludible. Entonces, ¿qué hacemos? En este artículo nos proponemos sentar algunas bases para alivianar algo que, mientras menos cotidiano nos sea, mejor: cómo lidiar con un proyecto que, técnicamente, es una mierda. Para hacerlo, responderemos algunas cuestiones…

 

¿Qué hace que un proyecto sea una mierda?

Para detectar que un proyecto es una mierda, debemos estar atentos. Más allá de eso, aquí enumeramos algunos tips para reconocerlo:

  • Tiene mal diseño de arquitectura. O, ¡peor!, ¡ninguno!
  • Tuvo cambios funcionales grandes, a veces contradictorios durante su desarrollo, lo que hizo que haya módulos
  • con enfoques distintos.
  • No posee un mínimo de documentación.
  • Sus procesos repetitivos no están automatizados.
  • Su código es de mala calidad.
  • No representa ningún desafío.
  • Requiere tecnologías viejas y/o poco interesantes.
  • Posee poco (o ningún) testing.
  • Tiene mucho acoplamiento.

 

¿Qué hacemos si tenemos que trabajar en un proyecto de mierda?

Trabajo es trabajo. Entonces, antes de arrancarnos los pelos o darnos la cabeza contra el teclado, es mejor ser operativos. ¿Qué hacer para no colapsar?

desesperacion

Veamos:

  • Entender y documentar todo lo que podamos.
  • Realizar tests.
  • Hacer análisis ABC para la deuda técnica.
  • Buscar desafíos técnicos.
  • Demostrarle al cliente la importancia de la mejora técnica.
  • Evitar eso de que “código que funciona no se toca”.
  • Exigir tiempo para invertir en mejorar lo que no está bueno.
  • Admitir que el proyecto, originalmente, es una mierda.

 

¿Cómo evitar que los proyectos de mierda aparezcan?

Además de estar atentos para detectar que un proyecto es una mierda, si estamos lo suficientemente despiertos -en ocasiones-, podemos llegar a evitar que aparezcan. Les dejamos algunos tips:

  • Tener en cuenta que son culpa de todos: desde PL, líderes técnicos hasta devs.
  • ¡Realizar tests!
  • Entender bien el negocio.
  • Consultar el diseño en caso de que no conozcamos la tecnología.
  • Pensar que lo que estemos haciendo van a continuarlo otros.
  • Convencer al cliente de su equivocación si impulsa una arquitectura y/o tech que no consideremos correcta.

A veces no podremos evitarlo. Otras sí. En ocasiones nos encomendarán uno. Pero, al menos, ahora contamos con esta guía práctica, que nos permitirá encarar un proyecto de mierda más relajados de otro modo, incluso, con la posibilidad de convertirlo en uno bueno. Y así, ¡trabajar relajados y celebrar!

 

Lucas Simonelli

Fue Líder Técnico en intive – FDV, donde trabajó desde febrero de 2014. Antes, también en la empresa, se desempeñó como desarrollador de software. Es Ingeniero en Sistemas graduado de la Facultad de Ingeniería de la Universidad de Buenos Aires.

Deja un comentario