Algunas de las razones son las habituales son las siguientes
- Una pobre planificación, desde no estar seguros de que es lo que se tiene que hacer para que se termine el proyecto hasta.
- La falta de estándares de rendimiento que solo nos permite arrojar estimaciones basadas en la experiencia.
- La falta de una estructura organizada de proyectos.
- La falta de un uso de herramientas de versionamiento (ademas no utilizar uno es llamar a los problemas)
- El no conocer como es el entorno de producción produce retrasos si bien no significativos son retrasos innecesarios.
- La falta de conocimientos en las tecnologías a utilizar, siempre se disfruta aprendiendo.
- Falta de cooperación
- Nivel bajo de cultura informática
- Cambio en los requerimientos
Los cambios en los requerimientos son de lo peor (e igual inevitable) que te digan y ¿no se puede agregar un elemento a la lista? (solo para revisar que alguien harcodeó esa lista y otros hay un gran numero de métodos que hacen operaciones en esa lista que solo consideran los elementos que se muestran y no se encuentra en ninguna parte de la base de datos) puede ser hacerte pasar un mal rato (y si accedés un par de noches en vela).
Por supuesto cuando te piden un cambio tu primer instinto será decir si se puede (porque claro son computadoras y casi todo se puede hacer con ellas) pero no hay tiempo, me parece que un mejor enfoque es explicarle al cliente que cuando digo no se puede, no se refiere a que es imposible sino a que no es factible hacer el cambio sin un retraso, que no es una función critica, es mejor evitar decir que si se puede de primas a primeras hay cambios pequeños en un sistema, un orden diferente en una lista u cosas pequeñas por lo demás respetar los requerimientos originales como siempre tratar con los clientes es una de las cuestiones mas difíciles en un desarrollo de software.
Hay un enfoque que me gusta que toman algunas las distribuciones Linux y es que meses antes de un lanzamiento estable se hace un freeze de los paquetes, es decir que no se aceptan otras mejoras que no sean parches de seguridad para el lanzamiento de la versión.
Por supuesto que queremos hacer al cliente feliz (porque nos paga para comenzar y porque ese cambio que sugiere puede que sea critico y de interés para el negocio), pero lo que le interesa es que el sistema esté terminado (y algunos argumentan también que el cliente muchas veces no sabe que es lo que quiere) así que es mejor terminarlo y obviamente es indispensable que el sistema tenga valor para el cliente cosa que no se puede hacer sin un análisis de requerimientos muy trabajado.
