¿Por qué fallan los proyectos de software?

Hoy, en el Microsoft Users Group de Argentina, Patricia Scalzone y Leticia Medela, de Vemn Sistemas, dictan una sesión sobre por qué fallan los proyectos:

Jornada de Soluciones

El temario es:

Escenario: ¿Por qué fallan los proyectos de software?

Solución: Entre las diferentes causas que llevan al fracaso de un proyecto de software, la tecnología no es la determinante. Esta sesión se focalizará en presentar técnicas y herramientas adecuadas para prevenir esa situación, tomando  ALM (Application Lifecycle Management) como referencia.

Hay otros temas, como migrando a SOA, mejorar la calidad del software, y la implementación de un portal CMS, usando DotNetNuke.

Pero me gustaría hoy enumerar rápidamente algunas de las causas por las que fallan los proyectos de software. No será una lista original en contenido, y seguramente Uds. podrán aportar otras causas o explicar mejor alguna de las que presente. Sin poner una prioridad, veamos algunas causas:

No se tiene en claro qué hacer: los requerimientos son difusos, se toman mal, y terminamos haciendo algo que el cliente no necesitaba ni quería. No se entiende cuál es el problema a solucionar, el problema de negocio, el valor que nuestro entregable debe aportar al cliente. Se piensa más en detalles técnicos que en lo que realmente importa.

El cliente participa una vez cada seis meses: no se habla con el cliente, se trata de evitarlo. Se lo considera más un “enemigo” que parte del proyecto. Cada vez que entregamos un avance de la solución, nos damos cuenta que lo que entregamos no era lo que el cliente esperaba.

Gente no dedicada al proyecto: se lanza el proyecto, pero la gente que lo lleva adelante se dedica mientras tanto, a otros proyectos sin terminar, soporte de cliente, mesa de ayuda, a mover máquinas de un lado a otro por cualquier causa.

La gente de ventas prometió el oro y el moro: pasa en muchas consultoras. Por un tema de comisiones, o de posicionamiento en el mercado, se ofrece una solución “inflada” que no corresponde con lo que podemos hacer.

No conocer y entender la tecnología: hay que conocerla y ENTENDERLA. No sólo es saberse de memoria los namespaces de .NET, o la configuración de Spring: hay que entender para qué está cada cosa que usamos.

Usar mal la tecnología: hay quienes creen que usando J2EE y patrones todo queda solucionado: seguridad, escalibilidad, etc, sin detenerse a pensar en qué afecta la tecnología y las decisiones de diseño en lo que quieren lograr.

Cualquier problema lo arreglamos con más gente: en vez de encarar el problema de raiz. Agregar más gente a un proyecto con problemas, es como hechar querosene al fuego.

Equipo malfuncional: en el equipo hay gente que no sabe trabajar en grupo, tenemos “prima donna” que hacen lo que quieren, en vez de hacer lo que el proyecto necesita.

Cambios para mañana: viene alguien, de ventas o de gerencia, pidiendo cambios para el viernes, y estamos en la tarde del jueves.

Falta de recursos: se nos pide desarrollar el próximo Youtube + Facebook, con una máquina IBM XT de una diskettera.

Complicar la solución: para comunicar unos datos a otra aplicación, adoptamos un ESB, dos sistemas de cola de mensajería, una base de objetos, dos relacionales de última generación, y cuatro especificaciones de web services, aplicando transformaciones XSLT ante cada paso. Tal vez una simple programa hubiera dado el mismo resultado.

Falta de coordinación y cooperación: en un proyecto grande, hay varios equipos, posiblemente de distintas consultoras, resolviendo distintas partes del proyecto. Lo que un equipo hace, lo necesita otro, pero coordinan mal la entrega y prueba de las partes. Los equipos no se ven como colaboradores: cada uno hace lo suyo, y si otro equipo tiene problemas, consideran que no es problema de ellos. También pasa esto entre personas de un mismo equipo.

Uds. tendrán otros ejemplos a aportar.

Las metodologías ágiles ayudan a mitigar varios de estos problemas, o por lo menos, a ponerlos de manifiesto antes de que sea tarde. Hay problemas que van más allá de la metodología, que se tienen que resolver a nivel de la dirección de la empresa.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com/

This entry was posted in 3463, 6791. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *


*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>