Un día común y corriente en un proyecto altamente exigido, llámese altamente exigido a ese proyecto que es un dolor de “##@)($#)”, ese proyecto que solo recordarlo te da nauseas de lo malo que fue, se acerca un PM (Project Manager) a enriquecer un requerimiento que estaba más confuso y tan nublado como la contaminación de la Ciudad de México.
Y bueno solo se acercó a el equipo para decirnos que el requerimiento estaba incompleto y que estaba todo mal, que justo todos sabíamos que estaba incompleto solo que él pensaba que no lo sabíamos.
Esto es algo que me hace recordar con mucho aprendizaje puesto que, un proyecto malo que ya no es rentable, hace que todo vaya mal (ley de Murphy), porque cualquier cosa que uno desarrolle simplemente no cumplirá las expectativas de un requerimiento altamente complejo y sin un análisis previo.
Esto me quedó muy claro y al equipo seguro también, de lo complicado que es llevar un desarrollo atrasado, con cero análisis y el cliente molesto por no cumplir con tiempo todo lo que se le prometió.
Suelo pensar que estar en un proyecto malísimo es como un tabú, todos hemos tenido alguna experiencia realmente mala en la industria pero pocos se atreven a mencionarlo, como si fuera algo malo, sin embargo para mí ha sido mi mayor experiencia, simplemente por que se cuando no cagarla.
Parte del problema es que se subestima los requerimientos, alguien dió un presupuesto (Llámese gerente) el cual sin un análisis previo, se le dijo al cliente:
“Eso lo entregamos en 6 meses”
Lo cual ya en la práctica era imposible y termina mermando al equipo, porque existen las siguientes opciones:
- Se le exige al equipo que se ponga la camiseta y trabajé durísimo para cumplirlo (Horas extra sin paga y fines de semana, también sin paga).
- Se incrementa al equipo un mayor número de personas, perdiendo su rentabilidad.
Obvio un gerente elige la primera, por supuesto. Quien va a querer perder rentabilidad por cagarla frente al cliente.
Y luego los PMs realmente no es un juicio a la manera que ejercen, pero hay que ser críticos y explorar un requerimiento no cuesta nada, es más es parte de su trabajo (Junto a un analista), NO PUEDES dirigir un requerimiento a un equipo de desarrollo si ni siquiera entiendes lo que dijo un stakeholder.
Luego el GAP, las brechas sin analizar, ni siquiera saber en qué punto del proyecto te encuentras por que se re-trabaja tanto que las iteraciones ya ni existen, ni son claras, sumado a falta o poca comunicación.
Si te a pasado esto y al final los exponentes más arriba de ti, esperan o te dicen que es tu culpa o culpa del equipo de desarrollo, recuerda esto:
“Basura entra, basura sale (GIGO)”
No somos genios, ni magos, solo desarrolladores y realmente esforzarnos recae en cada uno de nosotros, pero si todo lo que llega a tus tableros son literalmente requerimientos basura, que se requieren para ayer, es imposible.
Esto es un revulsivo para evitar errores, al final ser críticos y en algún postmortem discutir y entender los errores para no cometerlos de nuevo.