Errores comunes en la ejecución de proyectos de TI

¿Quién no ha incurrido en estos errores? Si ya llevas algún tiempo desarrollando, seguro has sufrido por alguno de ellos.

La lista de errores más frecuentes encontrados en la ejecución de los proyectos de TI:

Errores relacionados con la gente

• Miembros del equipo desmotivados
• Falta de capacitación de la gente involucrada en el desarrollo
• Personas problemáticas en el equipo
• Agregar más programadores a un proyecto ya retrasado
• Oficinas ruidosas y aglomeradas
• Fricciones entre quienes desarrollan y el cliente
• Expectativas poco realistas
• Falta de un líder efectivo para el proyecto
• Falta de participación del usuario
• Falta de acuerdo antes que el desarrollo de inicio
• Las “Ilusiones”

Errores relacionados con los procesos

• Planeación demasiado optimista
• Falta de administración de riesgos
• Falla en los contratos
• No hay suficiente planeación
• Abandono del plan bajo presión
• Pérdida de tiempo al inicio del proyecto
• Saltarse las tareas iniciales
• Diseño no adecuado
• Falta de supervisión por parte de los responsables
• Falta de estimaciones adecuadas
• Errores relacionados con el producto
• Requerimientos excesivos
• Cambio de requerimientos
• Developers muy meticulosos

Errores relacionados con la tecnología

• Síndrome de la panacea
• Sobre-estimación de las ventajas del uso de una nueva herramienta
• Cambio de herramientas a mitad del proyecto
• Falta de un control de código fuente automático

Seguramente ya hay muchos mas.

Y ahora algunas de las razones por las que se incurre en estos errores:

Errores relacionados con la gente

Miembros del equipo desmotivados. Es casi imposible encontrar gente que se enamore de todos los proyectos.
Falta de capacitación de la gente involucrada en el desarrollo. «La gente que va comenzando es la que cobra menos, ¿Y por qué no meter solo becarios?» ¡Típico!
Personas problemáticas. Dime si no has estado junto al tipo que cree saber más que el líder de proyecto, pero no lleva más de unas semanas en un proyecto real (los de la escuela no cuentan). O bien, gente que simplemente no está bien con la vida ¡Y se dedicó a programar!
Agregar más programadores a un proyecto ya retrasado. Y como además no es necesario capacitarlos, explicarles las reglas de negocio, explicarles lo que quisieron hacer los otros programadores (que seguro ya no se acuerdan o ya ni están).
Oficinas ruidosas y aglomeradas. «Son programadores, no personas y solo necesitan una PC delante de ellos y unas mesas de madera»
Fricciones entre los developers y el cliente. ¡Esa manía de que la gente de TI de creer que siempre sabe lo que el cliente realmente necesita!
Expectativas poco realistas. Nunca falta el que quiere que le fabriquen un Word y pagar solo lo que cuesta el CD pirata.
Falta de un líder efectivo para el proyecto. Bueno, la gente de TI no nació para administrar proyectos, ¡Por eso programa! Pero casi nadie respeta a un líder de proyecto que no ha programado, por eso debe ser una especie de super administrador-programador-buena-gente.
Falta de participación del usuario. El usuario solo quiere sentarse y que su programa funcione y que no le quite tiempo para entrar al facebook.
Falta de acuerdo antes que el desarrollo de inicio. Y es que, ¿Cómo podemos estar de acuerdo con todas las tonterías que el cliente pide?
Las “Ilusiones”. El usuario piensa que le darán un automóvil, el líder de proyecto cree que solo le dará tiempo para hacer una bicicleta, los programadores tienen problemas para construir las ruedas de unos simples patines, y al final el usuario va a terminar caminando, como siempre lo ha hecho (el usuario es el incauto que trabaja para el que contrató a tu empresa, le vas a quitar tiempo y al final harás mas difícil su trabajo)

Errores relacionados con los procesos

Planeamiento demasiado optimista. ¡Claro! Hacemos un módulo por día y el último integramos todo.
Falta de administración de riesgos. ¿Alguien conoce a los que se dedican a administrar esas cosas?
Falla en los contratos. Lo bueno de usar plantillas de World es que todas incluyen las letras chiquitas donde no nos hacemos responsables de errores o vicios ocultos después de seis o más meses. Que es más o menos el tiempo en el que la base de datos se irá al carajo.
No hay suficiente planeamiento. Muchas veces solo se tiene el texto que viene en la propuesta comercial.
Abandono del planeamiento bajo presión. Sobre todo cuando le dices al usuario que hacer un facebook o un twitter es normalmente más caro que hacer una simple página web.
Pérdida de tiempo al inicio del proyecto. Y cuando pasa el pánico y comienza la negación.
Saltarse las tareas iniciales. Nunca analizas y nunca diseñas, ¡Esa es tarea de ñoños!
Diseño inadecuado. ¡Porque así me enseñaron en la escuela y los profesores son gente muy capacitada que lleva años en la industria del desarrollo de sistemas!
Falta de supervisión. Porque el gestor y el líder llevan como veinte proyectos al mismo tiempo y todavía no terminan otros que ya se entregaron. Y por supuesto los programadores se pueden enseñar solitos sobre lo que el cliente quiere.
Falta de estimaciones. ¡Para que! Si solo es la autoestima de los programadores lo que se va al carajo cuando fallan los proyectos.

Errores relacionados con el producto

Requerimientos excesivos. Si no está clara la propuesta el cliente te va a meter todas las funcionalidades que pueda y si puede hacer todo su trabajo, mejor.
Cambio de requerimientos. Porque claro, el mercado cambia constantemente y hay que ser competitivos y ajustarse a esos cambios. Pero la verdad es que, es hasta que el usuario comienza a usar el sistema, que se da cuenta de que nadie tenía idea de lo que se tenía que hacer realmente.
Developers muy meticulosos. Todos los programmers somos obsesivos compulsivos, es lo que nos metió en esto desde un principio.

Errores relacionados con la tecnología

Síndrome de la panacea. ¡Claro! Hay que usar Struts, Spring y Hibernate…  siempre y ya con eso quedan bien todos los sistemas.
Sobre-estimación de las ventajas del uso de una nueva herramienta. Como cuando usas una de esas herramientas de business intelligence o un CMS, que según el vendedor, harán prácticamente todo lo que el cliente te pida.
Cambio de herramientas a mitad del proyecto. Si no funciona Struts usa JSF, porque es mejor, si no funciona tampoco pues usa Spring MVC, porque es más simple, si no funciona mete Flex, porque se ve bien, si no funciona…  y así.
Falta de un control de código fuente automático. Te apuesto que eso si no te lo enseñaron en la escuela. Y que difícil es entender y  usar subversión y que todos tus compañeros lo usen, la primera vez.