¿Por qué los grandes proyectos de TI tienden a fallar o tienen grandes costos / excesos de programación? [cerrado]

Siempre leo sobre proyectos de transformación o integración a gran escala que son un desastre total o casi total. Incluso si de alguna manera logran tener éxito, el costo y el cronograma es enorme. ¿Cuál es la verdadera razón por la que los grandes proyectos son más propensos al fracaso? Puede utilizarse ágilmente en este tipo de proyectos o el enfoque tradicional sigue siendo el mejor.

Un ejemplo de Australia es el proyecto de nómina de Queensland, donde cambiaron los criterios de éxito de la prueba para entregar el proyecto.
Vea algunos proyectos más fallidos en esta pregunta SO ( en Wayback Machine )

¿Tienes alguna experiencia personal para compartir?

La razón principal es un aumento en el alcance , que el libro "El programador pragmático" describe como:

• hinchazón
• emplumador
• requerimiento de fluencia

Es un aspecto del síndrome de la rana hervida.

La idea de varios métodos "ágiles" es acelerar la retroalimentación y, con suerte, corregir la evolución del proyecto a tiempo.

Pero la otra razón es la administración de versiones : si no está preparado para lanzar el proyecto (por imperfecto que sea), es probable que falle (porque se lanzó demasiado tarde, con demasiadas funciones con errores y es más difícil de arreglar / actualizar / mejorar).

Eso no significa que tenga que tener una fecha de lanzamiento fija, pero eso significa que debe poder en todo momento crear una versión en ejecución de su programa, para poder probarlo / evaluarlo / liberarlo.

La publicación del blog " Los proyectos tardíos llegan tarde un día a la vez " contiene muchos más ejemplos:

Sé que lo que debería ser 'Conseguir real' sería flexionar el alcance y mantener fija la fecha de lanzamiento, pero eso no funciona si hay una funcionalidad acordada que no se puede completar a tiempo.

Es por eso que no abogamos por las especificaciones o la "funcionalidad acordada". Esa es la raíz del problema: decir que sabe todo sobre lo que necesita y cómo se implementará incluso antes de pintar el primer píxel o escribir la línea de código. .

Cuando predices un futuro rígido en un presente flexible, estás en problemas. Los futuros rígidos se encuentran entre las cosas más peligrosas. No dejan espacio para el descubrimiento, el surgimiento y los errores que abren nuevas puertas.

Por lo general , se subestima la complejidad del proyecto .

Steve McConnell (de la fama "Code Complete") tiene una lista de los errores clásicos .

Algunas personas han elegido algunas prácticas de desarrollo ineficaces con tanta frecuencia, con resultados tan predecibles y malos que merecen ser llamados "errores clásicos" ...

Esta sección enumera tres docenas de errores clásicos. He visto personalmente cada uno de estos errores cometidos al menos una vez, y los he cometido yo mismo ...

El denominador común en esta lista es que no necesariamente obtendrá un desarrollo rápido si evita el error, pero definitivamente obtendrá un desarrollo lento si no lo evita ...

Para facilitar la referencia, la lista se ha dividido entre las dimensiones de velocidad de desarrollo de personas, procesos, productos y tecnología.

Personas

# 1: Motivación socavada ...

# 2: personal débil ...

# 3: Empleados con problemas no controlados ...

# 4: Heroica ...

# 5: Agregar personas a un proyecto tardío ...

# 6: oficinas ruidosas y abarrotadas ...

# 7: Fricción entre desarrolladores y clientes ...

# 8: Expectativas poco realistas ...

# 9: Falta de patrocinio efectivo del proyecto ...

# 10: Falta de participación de los interesados ​​...

# 11: Falta de entrada del usuario ...

# 12: Política colocada sobre la sustancia ...

# 13: ilusiones ...

Proceso

# 14: Horarios demasiado optimistas ...

# 15: Gestión de riesgos insuficiente ...

# 16: Falla del contratista ...

# 17: Planificación insuficiente ...

# 18: Abandono de la planificación bajo presión ...

# 19: Tiempo perdido durante el front-end difuso. El "front end difuso" es el tiempo antes de que comience el proyecto, el tiempo que normalmente se pasa en el proceso de aprobación y presupuesto ...

# 20: Actividades ascendentes con cambios cortos ... También conocido como "saltar a la codificación" ...

# 21: Diseño inadecuado ...

# 22: Garantía de calidad a corto plazo ...

# 23: Controles de gestión insuficientes ...

# 24: convergencia prematura o demasiado frecuente. Poco antes de que se programe el lanzamiento de un producto, hay un impulso para preparar el producto para su lanzamiento: mejorar el rendimiento del producto, imprimir la documentación final, incorporar los ganchos del sistema de ayuda final, pulir el programa de instalación, eliminar la funcionalidad que no será listo a tiempo, y así sucesivamente ...

# 25: omitiendo las tareas necesarias de las estimaciones ...

# 26: Planeando ponerme al día más tarde ...

# 27: Programación de código como el infierno. Algunas organizaciones piensan que la codificación rápida, suelta y lista para usar es una ruta para un desarrollo rápido ...

Producto

# 28: Requisitos de chapado en oro. Algunos proyectos tienen más requisitos de los que necesitan desde el principio ...

# 29: Característica de arrastre ...

# 30: Revelador dorado. Los desarrolladores están fascinados por las nuevas tecnologías y a veces están ansiosos por probar nuevas características ..., ya sea que se requiera o no en su producto ...

# 31: Empújame, tira de mí negociación ...

# 32: Desarrollo orientado a la investigación. Seymour Cray, el diseñador de las supercomputadoras Cray, dice que no intenta exceder los límites de ingeniería en más de dos áreas a la vez porque el riesgo de falla es demasiado alto (Gilb 1988). Muchos proyectos de software podrían aprender una lección de Cray ...

Tecnología

# 33: Síndrome de bala de plata ...

# 34: Ahorros sobreestimados de nuevas herramientas o métodos ... Un caso especial de ahorros sobreestimados surge cuando los proyectos reutilizan el código de proyectos anteriores ...

# 35: Cambio de herramientas en medio de un proyecto ...

# 36: Falta de control automatizado del código fuente ...

Proyecto más grande = Más complejidad
Más complejidad = Más incertidumbres
Más incertidumbres = Más difícil de estimar
Más difícil de estimar = Estimaciones
malas Estimaciones malas = Exceso de costos

Culpo al proceso de licitación. Recompensa al grupo que puede hacer que el trato se vea más barato / más rápido en papel.

Las personas que hacen las ofertas no quieren perder su tiempo si no tienen posibilidades de ganar, por lo que sus estimaciones normales quedan en suspenso. Conozco personas que han especificado conmutadores normales en lugar de conmutadores POE para ahorrar $ 80. Pero el proyecto necesitaba POE porque tenía cámaras IP. Es necesario gastar esos $ 80, pero ahora está fuera de la especificación.

Tengo la firme convicción de que un proyecto de $ 2,000,000 de 2 meses aún tomará $ 2,000,000 de 2 meses, sin importar cuántas ofertas reciba. Si cree que hacerlo bien es costoso, espere y vea lo caro que es hacerlo mal.

Una posible razón es que las estimaciones se basan en proyectos más pequeños, suponiendo un crecimiento lineal en el costo con el tamaño del proyecto, cuando en realidad el crecimiento de los costos es, por ejemplo, cuadrático debido a la complejidad creciente, mayor duración del proyecto (más tiempo para cambios de requisitos), etc. difícil, y cuanto más grande es el proyecto, más difícil resulta estimarlo correctamente.

Otra razón son las estimaciones sesgadas de optimismo: para ganar la licitación, se utilizan las mejores estimaciones para calcular el precio. Cuanto más grande es el proyecto, menos probable es el mejor de los casos. Las reglas de licitación hacen que sea probable que el oferente más optimista obtenga la aceptación, por lo que incluso si 5 vendedores hacen una estimación realista y el 6º es demasiado optimista, el optimista gana la licitación y falla más tarde. Entonces esta es una especie de selección negativa.

El costo no excluye el cronograma a los ojos de la "gestión", que es una distinción importante que hacer. Como sabemos, "nueve mujeres no pueden tener un bebé en un mes" , sin embargo, se sorprendería de cuántas personas piensan que los problemas disminuyen en profundidad en relación con la cantidad de dinero que se les arroja. La mala gestión de proyectos, que a menudo se manifiesta en forma de microgestión, es la causa principal de la mayoría de los proyectos de estancamiento (en mi experiencia). La microgestión se activa cuando la 'gerencia' se da cuenta de que algo se está saliendo de control y no tienen idea de por qué.

Cuando esa no es la causa, el resultado esperado del proyecto probablemente no era sostenible para empezar. En mi experiencia, si el período de tiempo de un proyecto es demasiado corto, la gente tendrá tanto miedo de cometer errores que resultarán en un 'doble trabajo' que no harán nada de nada.

Esta es la razón por la cual la administración debe estar poblada por programadores experimentados que tienen un historial de equipos líderes que produjeron proyectos exitosos. Tal persona podría decir "De ninguna manera podríamos hacer eso de manera responsable" a pesar de los posibles ingresos, y no estaría en la administración por mucho tiempo, por lo que muchos de nosotros (en última instancia) respondemos a MBA en lugar de PHD.

Perdí la cuenta de la cantidad de compañías para las que he trabajado donde un no programador estaba a cargo de contratar programadores. Una vez tuve una entrevista en la que el gerente de contratación no quería hacer nada más que hablar sobre un evento deportivo reciente (creo que fue un partido de fútbol). Si la persona que tiene a su cargo se inspira más en un entrenador de la NFL que Knuth, el proyecto irá al tanque.

De vez en cuando, te encuentras con algo bien planeado, bien entendido, realista y aparentemente sencillo. Por alguna razón, seis meses después del desarrollo, todo se revirtió. Sucede. Rara vez, sin embargo, es que la causa subyacente de un proyecto se convierta en un barril de cerdo glorificado.

Aún así, tengo que admitir que ... si ves las noticias, es posible que veas un accidente ocasional de motocicleta o un choque de trenes. Nunca escuchas sobre los millones de motocicletas o trenes que llegan a tiempo todos los días sin incidentes. Lo mismo ocurre con los proyectos. Claro, es interesante ver una autopsia pública de algo que salió muy, muy mal, pero casi nunca escuchas sobre cosas que salieron realmente bien. Creo que los proyectos hundidos siguen siendo la excepción, no la norma.

La mayoría de las veces una combinación de dos o más de los siguientes:

• problema de colaboración entre departamentos
• política ... demasiada política ...
• equipo equivocado
• programación poco realista
• cambio de alcance sin la metodología adecuada
• informaciones faltantes

Bonito libro sobre el tema: Marcha de la muerte .

La gente tiende a pensar que el desarrollo de software es un proceso predictivo, que intenta medir y estimar las cosas con un año de anticipación. ¡Esto no es posible! El software de construcción no es fabricación de pernos.

Siguiendo la misma "tendencia", intentan hacer un gran análisis (nuevamente un año antes) pensando que cubrirán todas las posibilidades y, más tarde, convirtiendo al programador en simples mecanógrafos. ¿Cómo es que uno piensa que esto podría funcionar? Este tipo de comportamiento solo conduce a malas estimaciones y mucha burocracia.

Cuanto más grande sea el proyecto, más probable es que esté trabajando para una organización grande. Cuanto más grande es la organización, más capas de administración. Cuantas más capas de gestión, más difícil es para las malas noticias ("no podemos tener lo que queremos por lo que podemos pagar") para formar parte de la cadena de mando. Cuanto menos probable sea que las malas noticias lo conviertan en la cadena de mando, más probable será que se acepte un plan de fantasía y luego se demore mucho después de que se sepa que es insostenible.

Los proyectos de software de todos los tamaños "tienden a fallar" o "tienen costos excesivos". No escuchas sobre el costo abrumado en el negocio a la vuelta de la esquina, pero sí escuchas sobre cosas como el sistema FBI Virtual Case o el sistema de manejo de equipaje del aeropuerto de Denver. Por lo tanto, haré la afirmación de que no todos los sistemas grandes fallan, ni todos los sistemas grandes tienen excesos de costo / programación.

Me he encontrado con grandes sistemas que llegaron a tiempo (el cronograma se movió una y solo una vez durante el proyecto) y según las especificaciones (no tenía acceso a la información presupuestaria ya que éramos solo 1 de muchos proveedores). Uno que todavía me impresiona (y he escrito un poco sobre esto en este sitio) fue un gran sistema integrado de administración de clientes para un gran cliente financiero (en los primeros 100 de la lista Fortune 500). Calculo que gastaron alrededor de $ 100k / día (durante más de un año) en los salarios de las personas durante las llamadas de conferencia.

En el caso del sistema de manejo de equipaje, los gerentes de software dijeron que "basado en proyectos de este tamaño y complejidad, tomará 4 años construir y depurar este sistema". Los gerentes de ventas y ejecutivos dijeron que "el aeropuerto abre en 2 años, le dijimos al cliente que tomará 2 años, por lo que tiene 2 años para hacerlo". La prueba para ver si usted es un programador o un mal administrador es una respuesta simple a la siguiente pregunta: "¿el sistema de manejo de equipaje se retrasó o llegó a tiempo?"

Si el cliente sabe exactamente lo que quiere (y muy pocos saben), estará muy lejos en el camino para mantener los costos y el tiempo bajo control (y estas son las personas que tienden a deslocalizar bastante bien). Si su proyecto tiene que cumplir con todas las características posibles con las que sus clientes pueden soñar, y cada departamento tiene poder de veto cuando sus ladrillos de oro se agregan al proyecto, entonces está condenado a fallar desde el principio (como el FBI Proyecto VCF).

Percepción de la realidad.

Aquí está la mejor descripción de este problema que he encontrado. Tree Swing de businessballs.com

Conocí el concepto de "Percepción de la realidad" desde el principio en mi carrera de programación. Por esto estoy verdaderamente agradecido. Creo que esta es la razón principal por la que cualquier proyecto falla, no solo los proyectos de TI .

Una razón de los fracasos es que un gran proyecto suele ser un proyecto de alto perfil e importante para el negocio. Cuando los proyectos y tareas son de alto perfil, alienta a las personas a mentir.

Su jefe quiere que calcule su estado de finalización en el lado alto. Quiere estimar excesos y demoras en el lado bajo. Cuando se encuentra con un problema, no quiere escuchar que agregará tres semanas a la tarea; quiere escuchar que puedes trabajarlo en un par de horas esta noche.

Y así sucesivamente y así sucesivamente.

Estuve en un proyecto hace varios años, para un cliente. Me trajeron después de que se completara la oferta y el plan del proyecto. Existía una presión constante para tomar decisiones cada vez más rápidas y ridículas de reducción de costos, sobrecarga excesiva de personal, sin recursos para ellos; sin escritorios, computadoras, nada.

Finalmente, descubrí que el proyecto se ofertó a los 7 meses y 16 millones de dólares. Calculé en el reverso de un sobre que debería ser de 24 meses y de 50 a 100 millones. Establecí una reunión con mi gerente y su gerente, y presenté mi caso y cómo NO íbamos a acercarnos a tiempo o presupuesto; minimizaron todos los problemas. Al final de la reunión, el CIO llamó y les dijo a ambos gerentes esencialmente lo que dije, con la excepción de la falla en la oferta original.

Tuve la oportunidad de finalizar el proyecto cuando cambiaron las tecnologías a una en la que no estaba capacitado. Hablé con alguien mucho más tarde. El proyecto terminó siendo cancelado cuando estaba a la mitad ... a los 12 meses y 35 millones de dólares.

Los grandes proyectos de alto perfil desalientan a la gente a decir: "esto es un error". Los errores no son tolerados.

Elaborando un poco sobre la respuesta de VonC:

Estos grandes proyectos tienden a tener una mentalidad de "todo o nada". El proyecto, tal como se define, debe lanzarse de una vez, a menudo porque se trata de un cambio de un sistema existente.

Esto significa que los problemas de arrastre de características / requisitos son más difíciles de abordar, por lo que cuando el proyecto se concreta, a menudo se considera que ya no cumple con los requisitos. Esto puede exacerbarse si el sistema existente se ha actualizado o la tecnología ha avanzado mientras tanto.

¿Cuál es la solución a esto?

Realmente no sé, ya que nadie quiere tener dos sistemas ejecutándose en paralelo con un conjunto cambiante de funciones divididas entre los dos.

La complejidad del gran proyecto puede verse enormemente exacerbada por las presiones políticas externas. Un departamento puede tener una idea muy clara y enfocada de lo que quiere en el nuevo sistema, pero luego los departamentos asociados intervienen con docenas de solicitudes en la línea de "Bueno, siempre que lo haga, ¿por qué no lo hace? hacer esta pequeña tarea paralela para nosotros también? Puede comenzar diciendo "No, eso está fuera de alcance", pero luego comienza la lucha política entre los departamentos, y el presupuesto para el proyecto se ve amenazado a menos que todos reciban su parte del pastel.

Durante años, nuestra policía local no pudo buscar placas parciales a través del sistema de vehículos de motor, una característica que parece absurdamente simple. Le pregunté a un amigo qué era tan difícil de agregar esta función, y dijeron que cada vez que proponían cambiar a una base de datos moderna, todos los demás departamentos del estado que tenían alguna interacción con el sistema de vehículos motorizados querían obtener su parte de El sistema también se solucionó. El resultado fue un bloqueo total en la modernización de TI. Finalmente, el estado reunió suficiente capital para hacer un esfuerzo de modernización de todo el sistema, que luego fracasó porque era tan horriblemente complejo.

Un factor que se ha abordado pero que aún no se ha abordado:

Casi todas las fallas dramáticas son contratos que se ofertaron. ¿Qué le sucede a una empresa competente en tal situación? Hacen una estimación realista y, por lo tanto, casi con certeza están subutilizados por alguien que hizo una mala estimación.

Si la empresa no puede estimar adecuadamente, ¿es sorprendente que no puedan construir un sistema correctamente también?

Michael Krigsman en ZDNet tiene un blog dedicado a " Fallos de proyectos de TI ", que puede ser de interés aquí.

Otro punto es que con proyectos largos que abarcan años, generalmente habrá actualizaciones para considerar o soluciones alternativas, por ejemplo, ¿podría un proyecto ahora hacerse en la nube versus en el sitio para que algo comience a surgir cada vez más, que al considerar Esto no era un hecho cuando se inició el proyecto. Por ejemplo, si bien uno podría comenzar mientras algo está en 6.0, para el momento en que se realiza la primera fase, bien puede haber un 6.3 o 6.4 fuera y se pregunta cuándo actualizar. Los cambios en el alcance y la funcionalidad deseada, ya sea porque los requisitos no se reunieron correctamente o alguien cambió de opinión, son otros dos puntos que ya se han cubierto bastante.

Puede utilizarse ágilmente en este tipo de proyectos o el enfoque tradicional sigue siendo el mejor.

La razón por la cual los procesos ágiles bien aplicados no parecen sufrir tanto este problema es por una razón simple. No puede iniciar un proyecto grande de manera ágil. Puedes elegir uno u otro.

Con un proceso ágil, nunca estás mirando más allá de una o dos iteraciones hacia el futuro del proyecto. no hay un 'plan' para los próximos 2 años, solo las próximas dos semanas. Cuando su punto de vista es tan corto, debe hacer algunos compromisos. Nunca puede comenzar con un plan para hacer "La última palabra en widgets", para cualquier tipo de widget que esté diseñando. A lo sumo, puede comenzar con "Un widget que puede frob", porque esa es la mayor parte del trabajo que puede realizar en una o dos iteraciones.

Lo bueno de esto es que, después de algunas iteraciones, ya tiene un producto completo y funcional que alguien puede encontrar útil, especialmente aquel cliente que necesita desesperadamente un widget que pueda funcionar y funcionar.

Esencialmente, los proyectos grandes pueden fallar porque apuntan a resolver todos los problemas de todos los clientes potenciales. Un proyecto ágil nunca tiene este objetivo, en lugar de abordar en cada versión solo un problema crítico que podría tener un solo cliente. Sin embargo, después de un buen tiempo, un proyecto ágil podría resolver muchos problemas críticos para muchos clientes.

• No enviar a usuarios reales

Los grandes proyectos tienen una tendencia desagradable a entrar en modo de "infraestructura" durante años, y olvidarse de construir funciones reales para el usuario final y enviarlas. Para cuando se envía, es muy costoso cambiar, y generalmente los cambios conceptuales más grandes terminan siendo solicitados después de que ocurre la primera prueba beta real.

• No estimar con precisión el costo

Si los proyectos parecen superar su retorno de la inversión, se cancelan.

• Falta de control de calidad

Con suficientes defectos, es posible que el impulso hacia adelante caiga a cero, o por debajo. Sin ningún progreso en absoluto, es difícil argumentar por la existencia continua.

Se olvidaron de la Ley de Hofstadter: siempre lleva más tiempo de lo esperado, incluso cuando se tiene en cuenta la Ley de Hofstadter.

Cosas que he visto en el desarrollo web:

• Demasiados cocineros: el principal minorista de B&M, donde el énfasis se desplazó repentinamente a la web. De repente, 20 jefes de departamento están acumulando todas las iniciativas para impresionar al nuevo queso de cabeza. Una vez tuve que implementar nuevos íconos porque a legal no le gustaba el aspecto de los viejos.

• Enfoque excesivo en igualar las especificaciones para lograr los objetivos: "Los íconos de IE6 están ligeramente desvaídos en comparación con los de IE7. Por favor, abandone el trabajo crítico de la fecha de lanzamiento que está haciendo y atienda .05% de nuestra base de clientes para hacer cosas horribles que tomarán días para implementar y ralentizar la experiencia de IE aún más ".

• Malas herramientas elegidas por personas que no son desarrolladores y que ni siquiera pueden molestarse en pedirles consejo a sus desarrolladores internos.

• Desarrolladores malos elegidos por herramientas: "¿Por qué pagar a 20 desarrolladores de Java competentes un salario decente cuando podemos subcontratar a 200 tipos que apenas saben codificar y que saben muy poco para usar el control de versiones?" ya que simultáneamente y con personas en diferentes países, trabajen en los back-end principalmente para 3 aplicaciones grandes.

• Arquitectura defectuosa / rota: capas sobre capas de código de pánico, que se hizo ayer, por personas que fueron despedidas o que ahora son gerentes.