Diario de Programación

Siguiendo con el tema de la planificación me encuentro con más problemas, de esos que en la teoría no salen.

Como he comentado muchas veces, tenemos muchos proyectos, similares y todos solapados en el tiempo. Algunos están finalizando, otros están a mitad de desarrollo y otros están comenzando, preparando prototipos/demos para que los clientes se hagan una idea de lo que van a tener, pero ya configurado para ellos.

Como todos los proyectos son similares, se hacen librerías compartidas y los programadores se especializan en temas. Sería poco eficiente hacer grupos separados por proyectos sin que compartan nada, sin librerías comunes, sin conocimientos reaprovechados.

Y esto prepara dos problemas grandes:

1. Algunos programadores están en las tres fases de los proyectos a la vez. Están manteniendo/depurando su especialidad en los proyectos que están acabando, están desarrollando en medio de otro proyecto y tienen que preparar la demo de su especialidad en un tercer proyecto. Además, los programadores que se encuentran en estos problemas, son precisamente programadores experimentados (han participado en proyectos de dos o tres años que están acabando) y se les carga adicionalmente con la enseñanza de los programadores nuevos.
2. Las librerías comunes siempre están congeladas. Los proyectos que están finalizando no nos permiten grandes cambios en estas librerías. Los proyectos en desarrollo nos piden cambios en ellas y los nuevos proyectos piden a gritos grandes refactorizaciones y replanteamientos de esas librerías. Supongo que nada que no se pueda arreglar con unas ramas de CVS.

y cito en concreto mi caso

1. Incidencias y mejoras pendientes en proyectos casi acabados. O corrijo yo el código o se lo suelto a un novato. Si se lo suelto a un novato, perderé más tiempo en explicarle qué tocar y dónde tocar que en tocarlo yo mismo. Si no se lo suelto, me quedo yo con eso hasta el final.
2. Proyectos en desarrollo, con ganas locas de meterme a codificar algo en ellos, pero totalmente imposibilitado por falta de tiempo. Me refiero a un tiempo relativamente largo en el que pueda programar algo de cierto tamaño todo seguido.
3. Proyectos nuevos, en los que llevo programadores nuevos, especificando y dando algunos esquemas UML de alto nivel para seguir una arquitectura uniforme en todos los módulos. Encima, algunos de los nuevos están en la software factory, en otra ciudad.

Y mi día laboral consiste en

1. Abrir el correo y rezar para que no haya muchos marrones ese día.
2. Atender marrones, gente y reuniones que me vienen antes de que haya acabado de leer el correo
3. Así hasta la hora de comer. Después de comer, si regreso antes que los demás (suele ser el caso), sigo leyendo el correo de por la mañana
4. Más gente, más reuniones y más marrones
5. Me voy a casa con la sensación (y la certeza real) de que no he hecho nada en todo el día y de que lo que tenía planificado lleva exactamente un día de retraso más que ayer.

En fin, últimamente programo más en casa en ratos libres que en el trabajo. Y todavía no acabo de entender cómo tanta charla, tanta reunión y tanto documentito pueden hacer que la cosa vaya más rápida que si yo me pongo a programar como uno más.

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.