¿Cuándo gestión de proyectos y cuando gestión de desarrollo de software?
Recordemos que un proyecto por definición es "Un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único". Es decir que tiene un principio y fin conocidos, cuando se acaba todos bye y para su casita. Un producto o servicio en cambio es “un conjunto de características o funcionalidades tangibles o intangibles que se desarrollan y evolucionan hasta que se hace obsoleto”.
Entonces no se pueden abordar de la misma forma porque tienen enfoques de duración diferentes, el proyecto no evoluciona sino que se ejecuta y se espera que esté terminado y permanezca así por el resto de su existencia, las obras civiles por ejemplo (puentes, edificios, escuelas...) tienen definido TODO desde su planeación, equipo de profesionales, materiales, maquinaria y herramienta, aspectos tecnológicos, de seguridad...Y es que no quiero ni pensar en un PM a diciendo "vamos a sacar el MVP de este puente y vamos iterando según la respuesta del mercado". ¿Pero cómo? O sea, probamos si el puente si aguanta y le seguimos dando por ahí. Que, si funciona pa los carros, ¿pero se nos cayó 1 trailer entonces toca reforzarle? o que a la mitad del proyecto salga con un "qué pena mr sponsor, le calculamos mal a la distancia, pero nos sentimos bastante confiados con lo que llevamos, el equipo sugiere que salgamos así y en 4 sprints queda solucionado".
En un proyecto de obras las desviaciones no sólo son costosas, sino que son extremadamente riesgosas y pueden costarles la vida a muchas personas, por eso hasta el momento no he visto ninguno que se lleve con scrum o con ningún otro marco ágil y ojo porque se es defensora número 1 de scrum, pero para el desarrollo de software, para investigaciones, estudios de factibilidad entre otras cositas. Pero me perdonarán todos mis amigos, estudiantes, colegas scrum masters a los que se les quedó metido en la cabeza la teoría de que "scrum sirve para todo". El trabajo se puede organizar por iteraciones, pero en un proyecto de obras civiles el desarrollo no se adapta en función de la respuesta del mercado.
Pues ahí se estaba bien confundida teniendo un portafolio de proyectos y productos, y convencida que algunos era más fáciles hacerlos bolita, echarlos a la basura y empezarlos de 0 que tratar de enderezarlos, logré que me aceptaran eso con 2 de los 6 y los otro 4 sí me tocaba agarrarlos como estaban. Esos 4 eran desarrollos de software 2 web apps y 2 aplicaciones móviles y se estaban llevando con Scrum.