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:
- 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.
- 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
- 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.
- 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.
- 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
- Abrir el correo y rezar para que no haya muchos marrones ese día.
- Atender marrones, gente y reuniones que me vienen antes de que haya acabado de leer el correo
- 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
- Más gente, más reuniones y más marrones
- 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.
Vuelvo a lo que comentaba ayer. En los últimos proyectos en los que he trabajado (hace un año exactamente que no participo en un proyecto de desarrollo), el cliente tenía especificaciones para un proyecto mediano, el cual dividía en fases con objetivos para cada fase, con lo cual el proyecto se dividía en proyectos más pequeños de aproximadamente dos meses de duración y cuatro programadores.
Ahora que estoy en Caixa Galicia hace aproximadamente lo mismo. Crean las especificaciones de un proyecto grande pero lo dividen en varios mucho más pequeños. Y a partir de ahí subcontratan estos proyectos.
No sé si es la mejor solución ya que implica problemas para la gente que diseña porque muchas veces no conoce ni siquiera que el proyecto es más grande de lo que tiene entre manos y se hacen diseños poco extendibles. Pero ese no sería tu problema porque sabes el tamaño y lo que tienes que hacer es conseguir dividir el problema adecuadamente. Ahí está el quiz de la cuestión.
Saludos,
Buenas Rodrigo.
Habiendo gente suficiente se puede hacer perfectamente lo que comentas. Aunque tendremos que hacer algo parecido, es nuestro caso no podemos/deberíamos aplicarlo tal cual. Como te comento muchos proyectos son similares y no puedes poner grupos separados a hacer casi lo mismo. Los «expertos» en un tema deben participar en todos los proyectos que lleven ese tema, cada uno con sus exigencias de plazos. Si hubiera gente de sobra, no importaría formar más «expertos» en ese tema y dividirlos en grupos por proyectos, incluso aunque repitan código o hagan dos veces lo mismo. Pero como te comento, no es el caso.
Esta claro, de todas formas, que no podemos estar todos a todo a la vez. Tendremos que hacer subproyectos-tareas y dedicarnos cada uno sólo a una de ellas y olvidarnos de que existen las demás, independientemente de lo que nos «presionen» por arriba. Eso sí, la tarea a elegir en cada momento debe ser la que más prisa corra.
¡¡Vaya!!. Que institucionalizamos el ir «apagando fuegos» 😉
Se bueno.