Los 36 Errores Clásicos de los Proyectos de Desarrollo de Software

fracaso

Podemos definirlos como los lugares comunes del fracaso del desarrollo software. No está de más conocerlos y re-conocerlos en tus proyectos para que puedas evitarlos y re-evitarlos.

No te creas a salvo de ellos, no pienses que nunca te tocaron, no creas que por tu metodología o tecnología no te llegarán a ocurrir: si no haces planes para evitarlos te tocaran.

La lista es una recopilación del gran Steve Mcconnell que desarrolló en su famoso libro Rapid Development todo un clásico de la gestión de proyectos de desarrollo de software y que te recomiendo desde aquí.

La lista está agrupada en 4 grupos en función de a que está relacionado el fracaso: las Personas, los Procesos, el Producto o la Tecnología.

¿Con cuál te quedas?

Relativos a las Personas

1. Motivación inadecuada. El equipo no está suficiente o adecuadamente motivado.
2. Personal inadecuado. Las personas no están preparadas adecuadamente para el proyecto.
3. Inadecuada gestión de los empleados problemáticos. No se gestiona correctamente el impacto de los empleados problemáticos en el resto del equipo ni en el proyecto.
4. Heroicidades. Surgen héroes que son los que se echan a la espalda el proyecto ignorando al resto.
5. Incorporar más personas a un proyecto retrasado. Un caso clásico, lo que se consigue es que el proyecto se retrase aún más debido a la curva de aprendizaje y a la dedicación del personal actual a formarlos.
6. Oficinas abarrotadas y ruidosas. Baja la productividad y entorpece el desarrollo del proyecto.
7. Roces entre los desarrolladores y el cliente
8. Expectativas poco realistas. Llevan a que haya roces entre el cliente y los desarrolladores.
9. Falta de un patrocinador del proyecto eficaz
10. Falta de compromiso por parte de los interesados
11. Falta de participación del usuario
12. Anteponer decisiones políticas sobre el objetivo del proyecto
13. Pensamiento ilusorio. Actuar pensando lo que nos gustaría que ocurriese en lugar de pensar en lo que es más probable que suceda.

Relativos al Proceso

14. Planificaciones excesivamente optimistas
15. Gestión de los riesgos insuficiente
16. Fallo de los proveedores
17. Planificación insuficiente
18. Abandono de la planificación bajo presión
19. Desperdiciar el tiempo antes del kickoff del proyecto
20. Acortar las tareas de alto nivel. Generalmente las tareas que no generan código pero que su reducción tiene un impacto importante en las fases posteriores.
21. Diseño inadecuado
22. Reducción de las tareas de control de la calidad
23. Insuficientes controles desde la dirección del proyecto. Se establecen desde la dirección del proyecto pocos controles que permitan detectar los problemas a tiempo y realizar acciones correctivas.
24. Se prepara el producto para su liberación demasiado pronto o demasiadas veces. Se realizan las tareas de pruebas de rendimiento, impresión de la documentación final, etc. demasido pronto o con demasiada frecuencia.
25. Omitir tareas de estimación necesarias
26. Planificar pensando en que recuperaremos el retraso acumulado más tarde. Si en el primer hito de entrega nos retrasamos 1 mes, volvemos a planificar pensando que ese tiempo lo recuperaremos más tarde.
27. Programar a cualquier precio. Se piensa que codificar a cualquier precio es un método más rápido de desarrollo, hecho que se demuestra que es un error.

Relativos al Producto

28. Añadir requisitos no solicitados por el cliente. Conocido como gold-plating.
29. Corrupción del alcance. Añadir, cambiar, modificar contínuamente los requisitos del proyecto sin importar en que fase del desarrollo nos encontremos.
30. Los desarrolladores añaden características no solicitadas. Durante la codificación se añaden características que no se solicitaron por parte del cliente.
31. Negociaciones de tira y afloja. Se concede un retraso en la planificación (asumiendo un error en la misma) pero a cambio se añaden nuevos requisitos (por lo que se comente un nuevo error).
32. Desarrollo enfocado a la investigación. Cuando el proyecto debe desarrollar algoritmos o métodos que nunca antes se han utilizado en lugar de desarrollo de software estamos en una investigación y las estimaciones de las investigaciones no están tan claras ni definidas.

Relativos a la Tecnología

33. Soluciones mágicas (silver-bullet). Confiar demasiado en que una nueva tecnología, metodología, lenguaje, plataforma, etc. resolverá grandes problemas de un plumazo.
34. Sobreestimación del ahorro por la utilización de nuevas herramientas o métodos. Obtener el máximo rendimiento de una nueva herramienta o método lleva un tiempo entre que aprendemos a usarlo (curva de aprendizaje) y lo usamos de la forma correcta.
35. Cambiar las herramientas en mitad del proyecto
36. Falta de automatización del control del Código Fuente