La cruda realidad

Cuando no se ha podido acometer un desarrollo de un proyecto de software o se ha acometido pero no con la calidad deseada y la unica conclusion posible (o almenos la mas plausible) es que no ha dado tiempo suficiente tambien lo que se esta diciendo es que EL EQUIPO X NO HA PODIDO LLEVAR A CABO EN UN TIEMPO Z EL DESARROLLO DEL PROYECTO DE SOFTWARE. Es decir, se esta aceptando una limitación de las personas que forman el equipo; pero es curioso porque nunca se enfoca asi. Si le preguntas a un miembro del equipo sobre porque no ha podido hacer esto asi o porque su parte desarrollada contiene tantos fallos entonces el te contestara algo como:

- Es que con el tiempo que tenia solo podia hacerlo asi.
- Es que con el tiempo que tenia no se podia probar mejor.

Pero nunca (o al menos casi nunca) se obtiene la respuesta de:

- Es que con el tiempo que tenia solo he sabido hacerlo asi.
- Es que con el tiempo que tenia no he podido probar mejor.

Es distinto ¿verdad?

Llegados a este punto merece la pena puntualizar que esta entrada del blog no es para que los componentes del equipo de desarrollo piensen que son malos. Esta entrada es para comprender que es muy importante conocer la capacidad real de cada uno de los miembros del equipo de desarrollo. De que cada miembro del equipo conozca sus limitaciones.

Como individuo, es dificil admitir limitaciones porque nuestros propios mecanismos de defensa no nos permiten ver dichas limitaciones. Cuando no se ha podido acometer un desarrollo de un proyecto de software o se ha acometido pero no con la calidad deseada, si se le pregunta a un miembro del equipo de desarrollo cual es el fallo, parece que se forma automaticamente dos bandos donde en uno estan todos los miembros que tuvieron la culpa del fracaso y otro grupo donde estan todos los inocentes que querian hacerlo de otra manera. Y el miembro consultado siempre esta en el segundo grupo.  

Esto es la cruda realidad. Y mas sobre la cruda realidad, los miembros del equipo de desarrollo (en la gran mayoria de los casos) no cambia. No mejora su rendimiento ni acepta mejor sus limitaciones. Este aspecto es duro pero es mejor aceptarlo y trabajar con lo que se tiene.

Poner limites

Siempre que no se cumple con un proyecto (con un desarrollo de software) o se cumple pero no con la calidad deseada aparecen todo tipo conclusiones:

- No se hizo bien esto.
- Esto no tendriamos a haberlo hecho. Tendriamos que haber hecho lo otro.
- No nos cordinamos bien.
- etc..

Cuando todas estas explicaciones son bastante dificiles de mantener siempre está la respuesta mas obvia: NO HABIA SUFICIENTE TIEMPO.

El tiempo (como ya he comentado en entradas anteriores) es la unidad de medida basica de todo. Al decir que no ha habido tiempo suficiente para llevar a cabo un desarrollo tambien se esta diciendo de forma implicita que EL EQUIPO X NO HA PODIDO LLEVAR A CABO EN UN TIEMPO Z EL DESARROLLO DEL PROYECTO DE SOFTWARE (un proyecto que tiene una carga Y). Esta conclusion es muy importante porque nos permite establecer una metrica de capacidad para el equio de desarrollo. Podemos utilizar distintas formulas como:

Si Y es 1000 de carga
Si X tiene 10 personas                                                  
Si Z es un total de 2848 horas (1 año de trabajo)

Productividad maxima por persona = 1000/(2848*10) = 0,03

Si sabemos que la productidad media del equipo es 0,03 se deberia usar este dato para futuros desarrollos ya que si en un futuro se quiere acometer un desarrollo se deberia saber que con este equipo no se puede obtener mas productividad que 0,03. Pensar que si cambio esta tecnica, o sigo esta metodologia, etc.. puedo llegar es engañarse a si mismo. Con el mismo equipo la productividad (en el mejor de los casos) sera 0,03