¿Qué es la gestión de proyectos? Lo que he aprendido sobre ella.

Mis 20 años de experiencia con diferentes empresas en desarrollo de software y mis 40 años de edad en el trato con personas, clientes, gestores de proyectos, me han ido revelando unos principios que siempre se cumplen y quiero compartir algunos de ellos con todos vosotros:

1) Nadie parte sabiendo cómo debe ser exactamente el producto que desea crear. Siempre se parte de un "quiero algo parecido a esto pero con aquello otro" y el resultado final dista bastante de las expectativas iniciales creadas, sea por características muy diferentes a las pensadas inicialmente o por su extrema dificultad.

2) Justo en el momento en el que puedes afirmar que has terminado un producto, y se inicia su etapa de soporte, es cuando ya se encuentra desfasado y necesita evolucionar: por lo que ofrece y dicta el mercado en ese momento, por las nuevas tecnologías disponibles, porque los problemas que resolvía han dejado de ser difíciles de resolver o las prioridades del cliente son muy diferentes.

3) Puedes hacer evolucionar un producto según dos filosofías: iterativa, vía SCRUM, o rupturista, comenzando desde cero. En la iterativa el buen diseño del producto, la formación del equipo y una excelente documentación, son clave para la mantenibilidad y ampliación a muy largo plazo. En la rupturista puedes tomarte ciertas licencias porque el ciclo de vida será corto, pero con el riesgo de verte obligado a rehacerlo completamente en muy breve espacio de tiempo. Es importante no confundir el desarrollo iterativo con ofrecerle al cliente un producto beta permanentemente incompleto, inestable y con fallos.

El modelo en cascada solo es útil para sistemas y problemas a resolver que son muy estables en el tiempo. La variabilidad que puede tener una aplicación de compra online es infinitamente mayor que la de un software que monitoriza la temperatura en una central nuclear, siendo lo segundo mucho más importante.

Haz prototipos de forma rupturista, pero no inviertas más de 6 meses en ellos. Crea producto de forma iterativa con la experiencia obtenida de los prototipos pero tómate el tiempo que sea necesario para que sea un buen producto. ¿Cuánto tiempo? Por ejemplo Microsoft lanza una nueva versión de su sistema operativo cada 3-5 años y Ubuntu crea una nueva distribución cada 2 años.

4) No es sencillo crear un producto flexible, modular y tolerante al cambio. Se necesita talento, conocimiento, experiencia, organización y recursos. Muchos productos se crean según las expectativas que tiene el equipo de desarrollo respecto a su propio ciclo de vida: "Esto en 5 años estará obsoleto, no vale la pena invertir tanto tiempo en hacer X", "En 2 años me marcho de la empresa, ya verán entonces cómo solucionan el problema"...

Hay dos vías: 

a) El de bajo coste a corto plazo, pero muy alto a largo, por la alta rotación en el equipo, asumiendo que tendrás que reconstruir el producto una y otra vez. 

b) El de coste alto a corto plazo, pero medio a largo, por el esfuerzo de fidelizar y formar al equipo enfocándose en la solidez del producto.

5) Todo desarrollador siempre prefiere ser creador de un producto nuevo a convertirse en mantenedor de algo creado originalmente por otros. Este sentimiento prevalece más cuanto más joven es el equipo, también cuanta más experiencia en tecnologías e innovación necesitan aportar a su currículum. Obviamente ese sentimiento pesará en las decisiones técnicas. Cuidado con los arquitectos o líderes técnicos muy jóvenes, su prioridad será demoler y construir desde cero para probar nuevas tecnologías, dejando su impronta, más que el valor o la viabilidad del producto en si.

7) Los desarrolladores no son buenos estimando tareas. Bien porque sobreestiman o infravaloran sus capacidades y la magnitud de los problemas a abordar, o bien porque como seres vivos sintientes que somos, un día puedes dar el 150% pero al siguiente puede que no llegues ni al 50%. Las estimaciones deben realizarse en base a datos, estadísticas, métricas, la experiencia previa del gestor de proyectos respecto a esas tareas, pero nunca puede considerarse la estimación de los desarrolladores algo más que una leve orientación. Esto me lleva al siguiente punto.

8) Querer ser imprescindible, decidir y hacer de todo, va en contra de la productividad y la calidad. Leonardo Da Vinci era único entre millones y vivió en el siglo XV. Fue a la vez pintor, anatomista, arquitecto, paleontólogo, artista, botánico, científico, escritor, escultor, filósofo, ingeniero, inventor, músico, poeta y urbanista.

En el mundo sólo el 2% de la población tiene altas capacidades mientras que el 98% restante no. Esto debería dar a entender que hay que ser humilde y aceptar las propias limitaciones.

No puedes trabajar 12 horas al día gestionando proyectos, gestionando personas, documentando, diseñando interfaces, definiendo producto, desarrollando, testeando, desplegando, validando... ni hacerlas todas bien al mismo tiempo. Es más, seguro que no llegas para hacer bien ninguna de ellas.

Incluso dopado de sustancias el cerebro humano no está preparado para la multitarea, ni tan siquiera el cerebro de las personas más inteligentes. Eso ya lo sabía el Henry Ford del siglo pasado. Especialización: foco en tu responsabilidad. Menos es más.

9) Muchas personas cambian de vehículo cada cinco años, de teléfono cada año, e incluso de pareja cada trimestre. Las empresas están formadas de personas. Los productos son utilizados por personas. Nunca creas que lo que en determinado momento es útil, funciona bien, o es lo comúnmente aceptado, lo seguirá siendo en el largo plazo. Adaptación al cambio.