Fallos más comunes en proyectos de desarrollo

23 octubre, 2010

Gestión, Tecnología

Cuando empecé a programar hace muuuuchos años, cayó en mis manos un libro de Steve McConnell, sobre la gestión de proyectos.

En este libro se enumeraban la lista de errores clásicos en los proyectos en la época de los 80/90, y es curioso, en todos los proyectos en los que he estado, se han cometido al menos el 50% de los errores que indicaban.

Pues bien, Steve ha seguido manteniendo la lista, y la actualizó en el 2008, la podéis descargar en la página de su empresa http://www.construx.com/, hoy los he repasado, y como siempre, tienen toda la razón del mundo.

Recomiendo la lectura de este documento a todos mis becarios, y a toda persona en general, y siempre me dicen lo mismo, que efectivamente han visto esos errores en muchos proyectos.

Pero os voy a contar mis errores favoritos, de mi propia cosecha, que coinciden en cierto modo con los de este estudio. Antes de seguir, mucho de estos errores los he cometido yo mismo, y los sigo cometiendo…. son difíciles de evitar.

Trabajar con intermediarios es como pedirle a Chuck Norris que vaya al supermercado a comprar una docena de huevos

Este es el error más común y más grave de todos los que conozco. Cuando se trabaja en un proyecto grande, con suficiente documentación, siguiendo una metodología de calidad, este error tiene un impacto mínimo, pero en proyectos pequeños, el impacto es enorme.

Hasta ahora, en todos los proyectos en los que hemos tenido un intermediario, hemos hecho algo totalmente diferente a lo que el cliente esperaba, por que el intermediario, en lugar de contarnos lo que quería el cliente, nos contaba su solución a lo que el cliente quería, que por supuesto, no tenía nada que ver.

Cada vez que me llaman para un proyecto de este tipo, lo rechazo, pero últimamente me engañan, me dicen que son para ellos, y al final, son para otros….

El impacto en este tipo de proyectos, suele ser un retraso, como mínimo, igual al tiempo estimado al principio, y en algunos casos x4 veces más.

Si te gusta el riesgo, salta en paracaídas, pero si trabajas conmigo…

Soy un obseso del riesgo, y la última vez que hice una planificación de riesgos me echaron del del proyecto por pesado. Lo fuerte, es que me echaron mis compañeros y el cliente, aún me acuerdo de aquella frase …. “y si tiene problemas de rendimiento, se le pone más hierro y punto…..”

Y llegó el día de poner aquel proyecto en explotación, una web para 2.000 usuarios, que necesitó un cluster de máquinas AIX, cuando el fallo era realmente tonto, y se podía haber solucionado de otra forma.

Pues esto pasa siempre, algunas veces son los analistas, otras veces los programadores, pero siempre se desarrolla bajo la esperanza de que todo va a salir bien, pero cuando falla, te encuentras a una empresa perdiendo 20.000 euros/día por un error en la importación de datos.

Los riesgos son muchos, rendimiento, control de errores, comunicación entre sistemas, perdida de datos, seguridad, etc…

Convergencia excesivamente prematura: Esto lo terminamos el viernes….

Cuando un proyecto es muy grande, o existe una gran presión sobre su fecha de finalización, suele aparecer una convergencia del proyecto prematura, hay una sensación en el aire de que el proyecto está acabado, cuando realmente está a un 80%.

Esto suele ocurrir en proyectos donde no existe una especificación del sistema, o donde se dejan ciertas cosas para el final….

Cuando el equipo da por acabado el proyecto, hay gabinete de crisis, y se encuentra con un desarrollo que se alarga un 20%, pero el problema, es que el equipo está desilusionado, que no hay planificación ni detalle de lo que queda, con lo cual, este 20% se puede convertir en un 40% en muchos casos.

Héroes y Villanos

En todas las empresas de tamaño medio/grande hay un héroe, una persona capaz de hacer sola el proyecto entero, pero que sin embargo, en medio del proyecto se entretiene, con una librería nueva de Jquery que es capaz de hacer que el botón de login cante una canción de Lady Gaga….. es la verdad, los héroes son muy importantes pero hay que atarlos cortitos, separarlos del proyecto en muchos casos, y encargarles tareas extremadamente complicadas, pero acotadas. Un héroe es capaz de acabar el solito con toda la planificación de un proyecto, por ejemplo, si la por rehacer enterito el J2EE, por que no le gusta la implementación de Sun…. (Caso Real). Pero en otras ocasiones, un héroe puede hacer el trabajo de 10 personas, normalmente, cuando son proyectos o herramientas internas, es ahí, donde deben estar los héroes.

Por otro lado tenemos lo villanos, esas personas, que minan la moral de sus compañeros, que hacen un código que aparentemente funciona, pero que después es un coladero, un villano, se empeña en poner el botón aceptar en el lado contrario que el resto del equipo de trabajo, por que sí, por que el tiene razón y el resto está equivocado.

Al héroe, hay que cuidarlo y aislarlo, y al villano, mandarlo a la competencia….

B3 o la teoría de lo bueno, bonito y barato…

Aunque Steve lo llama expectativas irreales, en España, yo lo llamo B3, por que la realidad es que los clientes lo quieren todo, a precio de nada, y por mucho que lo intentes, no pueden entender por ejemplo, que se tarde más tiempo en montar una tienda online, que en construir una casa. Es una realidad, en la mente de una persona 1.0, no cabe ese concepto, no se puede abstraer al coste de un desarrollo, pero ni siquiera para mi, ese concepto entra en mi mente, las herramientas de las que disponemos los programadores a menudo son 1.0, cada vez que cogemos ritmo y productividad en un entorno, llega algún gracioso, e inventa un lenguaje nuevo, una tecnología nueva, o un nuevo sistema operativo, y volvemos a perder productividad.

El Santo Grial

Aún recuerdo el proyecto en el que mi jefe apareció con una caja debajo de la mano… “con este componente hacemos el proyecto en la mitad de tiempo…”, aquel componente nos provocó un retraso de un 100% sobre la peor de las estimaciones, el desconocimiento de la herramienta, los bugs, las constantes perdidas de datos, nos hicieron plantearnos varias veces abandonar la herramienta.

En el siguiente proyecto, compramos otro componente similar, lo probamos antes de comenzar el proyecto, y ganamos bastante tiempo.

No existe el Santo Grial, la incorporación de herramientas novedosas, se debe hacer antes del proyecto o en un prototipo a parte, nunca incorporarlas en medio del proyecto.

Comments are closed.

Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies