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