Cada vez estoy más escéptico con el tema de la planificación de proyectos. No me refiero a hacerla, revisarla periódicamente, rehacerla, que es "relativamente sencillo" (ni de coña, hace falta mucha disciplina y experiencia). Me refiero a hacer una planificación que luego se cumpla.
Quizás gente con experiencia en planificaciones puede planificar más o menos correctamente un proyecto que dure unos meses y con unos pocos programadores (dos, tres, quizás cuatro). Pero, en nuestro caso, estamos hablando de varios proyectos con funcionalidades similares, pero lo suficientemente distintas como para requerir modificaciones, todos en paralelo, con alrededor de treinta programadores en total y plazos de entrega de uno a tres años.
Cualquier cosa que leas de planificación que te dice que hagas tareas muy granulares, del orden de tiempo estimado de uno o dos días por tarea. Si echamos unas cuentas, treinta programadores durante dos años, con tareas de 1 día, son aproximadamente …. ¡¡Buff, ni me atrevo a calcularlo!!.
Obviamente, no se puede calcular a priori todas esas tareas. La solución supuestamente es fijar pequeñas entregas cada uno o dos meses, dividir a la gente en grupos y planificar las tareas para esos dos o tres meses. Estupendo. ¿Y el resto del proyecto? ¿Y las demás entregas?. Por supuesto, todas ellas están fatalmente planificadas, porque ni se han detallado lo suficiente, ni se tiene muy claro que es lo que se tiene que hacer. ¿De qué sirve tener perfectamente planificado el primer mes o reajustar la planificación del primer mes si no se sabe nada fiable del resto del proyecto?
Al final da la impresión de que lo que hay que hacer es tener claro qué cosas son importantes y dedicarse a ellas primero, dejando lo secundario para el final por si da tiempo. Al final es algo así como "estará lo que dé tiempo a hacer en plazo y el resto no se hace", por lo que efectivamente es importante hacer lo más importante primero para que al menos eso esté. Pero ninguna planificación nos dirá a priori cuántas de esas cosas van a estar hasta que estemos ya muy cerca del final.
Quizás hay que dividir el plazo total entre las funcionalidades a implementar y hacer entregas cada uno o dos meses con esas funcionalidades. Pero para que se cumpla el plazo total, va a haber que pasado el tiempo de la primera entrega, dejar las funcionalidades que entren en ella como estén y pasar al segundo grupo. Por supuesto, en cada momento habrá que decidir si se continúa con las que no se han acabado (a costa de quitar otras) o se dejan como están para seguir con las siguientes. En cualquier caso, NO es una planificación para que se cumpla, sino es más que nada saber cómo se va para asumir el retraso y quitar cosas.
Cada vez estoy más decepcionado con este tipo de cosas.
En mi opinión se debe dividir el proyecto en funcionalidades más pequeñas contenidas en si mismas, es decir, que por si mismas puedan ser catalogadas como un proyecto. Y desarrollar cada una de ellas como un proyecto independiente. Cada una de las funcionalidades no debería necesitar más de cinco programadores. El problema que tienes es la gestión del número de proyectos en paralelo ya que si tienes treinta programadores con mis cuentas necesitas 6 proyectos en paralelo.
Pero ya tienes la factoría de software. Subcontratas 6 proyectos a la factoría de software y lo único (es un decir) que tienes que hacer es gestionar.
Aún así es complicado, pero que sería de la vida sin los retos.
La verdad que el tema de las planificaciones, sobre todo en proyectos largos, yo ando muy desengañado desde hace tiempo.
La combinación de «estima cuánto te costará hacer las tareas X e Y, el proyecto tiene que estar para el día D» habla por sí sola; luego se hacen horas para llegar, se entrega un producto lleno de bugs, se asumen retrasos, se recorta funcionalidad o todo a la vez :(.
Mi humilde opinión es que se debería empezar repensando la forma en que se venden los proyectos, este es un tema al que no veo una solución fácil.
Sí, estoy empezando a pensar que es mejor no planificar nada en cuestión de tiempos. Es mejor dividir en muchas tareas y subproyectos, ordenarlas por importancia e ir haciendo según ese orden, hasta donde se llegue.
Casi habría siempre que pensar: entregamos la semana que viene. De todo lo que queda por hacer ¿qué es lo más importante para hacerlo esta semana? y ponerse a ello.
Se bueno.