Finalmente, después de unas semanas de votación, y 171 votos, os dejo en este post los resultados de la encuesta sobre “los errores que perjudican más a un proyecto software”. Los resultados están ordenados por porcentaje de votos obtenidos, y al final de cada resultado podéis encontrar la posición que dicho problema ocupó en la encuesta que hizo McConnell en el 2008.
- Saltarse la calidad software (pruebas, inspecciones, etc.) para intentar que el proyecto vaya más rápido (61%) (posición 3 en la lista de “most damaged clasic mistakes” de McConnell)
- Abandonar el plan de proyecto cuando aparecen problemas de fechas (entrando en un codifica y prueba) (38%) (posición 9)
- Fijar el calendario de proyecto sólo en función de objetivos de negocio (36%) (posición 5)
- Crear planificaciones demasiado optimistas (34%) (posición 2)
- Iniciar un proyecto con expectativas que no eran realistas (30%) (posición 1)
- Gestionar erróneamente los cambios en los requisitos (26%) (posición 7)
- Gestionar insuficiente los riesgos (21%) (posición 10)
- Tener a los desarrolladores asignados a demasiadas tareas (18%) (posición 6)
- Guiarse por ilusiones (balas de plata, etc.) en vez de por la realidad (11%) (posición 4)
- Trabajar en oficinas ruidosas (5%) (posición 8 )
Ya comentamos que no pretendíamos un estudio altamente riguroso, pero si altamente interesante, e interesantes han sido, quizás más que los resultados, que eran de esperar, las diferencias con la encuesta que hizo McConnell (“Software Development’s Clasic Mistakes 2008”), cuyos votantes eran principalmente de EEUU.
Es curioso como en nuestra encuesta el problema de “Iniciar un proyecto con expectativas que no eran realistas” está en la posición 5 y en la encuesta de McConnell ocupó la posición 1. O que “Saltarse la calidad software (pruebas, inspecciones, etc.) para intentar que el proyecto vaya más rápido” esté en la posición 1 de nuestra encuesta y que ocupase la posición 3 en la de McConnell. Que «Abandonar el plan de proyecto cuando aparecen problemas de fechas (entrando en un codifica y prueba)» esté en la posición 2 de nuestra encuesta y en la 9 (de 10) en la de McConnell.
- Diario: cómo Javier Garzás evita quedarse obsoleto estudiando a un X10 con IA-Esteroides - 7 noviembre, 2024
- Si creas Historias de Usuario con IA ¿A quién pertenecen? ¿A ti o la IA? El mono Naruto te lo explica - 31 octubre, 2024
- HistorIAs de usuario y como a Maximiliano lo ENGAÑABAN con la IA y como una viejuna historia del 1500 le salvó - 24 octubre, 2024
Pingback: Bitacoras.com
Y curioso también es que en esta encuesta (española), estemos más «concienciados» de la importancia de la calidad (61% de votos), y se siga sin prestarle la debida atención. Pero bueno, el reconocerlo ya es un paso 😉
Sí, muy interesante (como era de esperar) el resultado de la encuesta que, a pesar de no ser una muestra muy significativa, expresa la opinión de 171 profesionales que del sector.
Para las diferencias halladas, puede haber también una causa de desfase temporal, la de EEUU se hizo hace 3 años y en ese periodo pueden cambiar ciertas condiciones y sensibilidades.
Llaman poderosamente la atención las dos primeras votadas, la calidad (nº 1) y lo de abandonar el Plan del proyecto cuando no se cumplen fechas. Así que le concedemos mucha importancia a la calidad en el desarrollo y a la planificación (porque puede parecer que ambas vayan, a veces, desligadas. Si te centras en hacer las cosas con mucha calidad, te de igual la planificación y no es así…).
Una cosa que me sorprende (y gratamente) es que «crear planificaciones muy optimistas» queda relegado a un 4º puesto (2º en la de EEUU). Muy interesante…
Enhorabuena por la iniciativa Javier, muy interesante.
Pd. Felicidades por tus 4 años de blog, me parece de lo mejor que veo cada día.
@Alfonso: Gracias Alfonso
perdón solo un detalle, pruebas e inspecciones, son técnicas para asegurar la calidad del producto, pero la calidad (según por ejemplo lo entiende CMMi), abarca mucho más, por ejemplo abandonar el plan de proyecto es justamente no seguir una de las áreas de proceso de CMMi en nivel 2.
Diría que es dificil disociar calidad de estos «mistakes». Tanto en el proceso de desarrollo como en el producto.
Por otra parte (comento desde Argentina, pero lo mismo tal vez les suceda allí), creo que aquí la importancia de la calidad ha llegado «más tarde» si se quiere que en U.S, por lo que probablemente, estemos sesgados en la votación por el cambio que implica en un proyecto usar técnicas de V&V (validación y verificación) ,o tener dentro de un plan de proyecto el plan testing (y no «hacerlo a como se pueda si es que se puede y hay tiempo» ).
Creo que seguramente es más grave para un proyecto iniciarlo con espectativas que no eran realistas, pero tal vez sea una lección aprendida, y lo estemos bajando de lugar porque hoy por hoy, se está tratando de mejorar en otro aspecto.
Me gustaría hacer la misma encuesta en 3 años.
saludos!