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

34

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?

Pratik
fuente
10
Una cosa curiosa sobre este problema es que generalmente obtienes respuestas completamente diferentes de los desarrolladores y de los gerentes.
mojuba el
3
@mojuba Soy ambos, y respondí. Espero que eso no resulte en un diagnóstico de trastorno de personalidad múltiple.
Tim Post
1
Ágil es mejor cuando el cliente no sabe lo que quiere. Las empresas generalmente no están dispuestas a gastar las enormes cantidades que tienden a entrar en los periódicos en proyectos mal definidos.
Tangurena
1
Esto no es exclusivo del mundo del software.
Trabajo
1
El fracaso masivo de proyectos como este parece suceder más en las instituciones gubernamentales que en las industrias privadas, o al menos parece estar en las noticias con más frecuencia.
Bratch

Respuestas:

34

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.

VonC
fuente
1
Estoy marcando esto como respuesta, aunque también hay buenos puntos en otras publicaciones. Estoy de acuerdo en que el enfoque en "Administración de versiones" para grandes proyectos es muy importante.
softveda
29

Por lo general , se subestima la complejidad del proyecto .

Amir Rezaei
fuente
2
+1: aunque podría haber dicho subestimado
Ken Henderson
@ Confundido Me gusta " subestimado " . ¡Nunca supe que ese término era tan viejo!
Mark C
Luego agregaré a mi pregunta "¿Por qué se subestima la complejidad?". La estimación del alcance y la complejidad es parte de SDLC. Entonces, subestimarme es un síntoma, no una causa.
softveda
2
Hay muchas razones para subestimar. Señalaré algunas: en un proyecto complejo, un cambio muy pequeño puede tener un impacto muy grande. Entonces se podría decir que esto no fue un pequeño cambio, de hecho, fue un gran cambio. Sin embargo, existe la mentalidad de que si algo es muy fácil de implementar, no debería ser un gran problema. De hecho, un pequeño cambio en la lógica empresarial puede tener un gran impacto ya que el proyecto es complejo. Otras causas: falta de presupuesto que conducen a menos tiempo en "Análisis y Diseño". Mentalidad de "prueba y error" en lugar de dedicar más tiempo a "Análisis y diseño". Falta de competencia.
Amir Rezaei
2
@Pratik, la complejidad a menudo se subestima porque los programadores (incluido yo mismo) son notoriamente malos para evaluar la complejidad de un proyecto. Esto probablemente se deba a que cuando piensa por primera vez en un proyecto, solo ve el esquema general, pero no ve los miles de pequeños detalles que se esconden justo debajo de la superficie. Por ejemplo, cuando se me presenta un nuevo proyecto web, tengo que resistir el instinto de pensar: "eso es fácil: simplemente reuniré una base de datos y un código Javascript de front-end. Debería terminar en aproximadamente una semana". Pero, por supuesto, nunca es tan fácil.
Charles Salvia
18

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 ...

mosquito
fuente
Por cierto, felicidades!
Mark C
14

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

JohnFx
fuente
Pero, ¿por qué las "malas estimaciones" siempre tienden a ser estimaciones demasiado bajas?
romanoza
En mi experiencia, dos cosas. La persona que solicita el presupuesto trata de negociar y la persona que lo ofrece se inclina ante la presión. En segundo lugar, la persona que da la estimación no reconoce cuánto tiempo flotante está involucrado en el cambio de tareas y la comunicación. Además, trabajan bajo la falsa suposición de que el trabajo es todo programación, pero hay mucho tiempo de comunicación de gestión de proyectos que debe tenerse en cuenta.
JohnFx
12

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.

revs mcotton
fuente
No puedo entender la oración, "Tengo una creencia firme ..." - ¿debería la segunda parte leer "2 meses y $ 2M ..." en su lugar?
Mark C
6

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.

usuario281377
fuente
+1 por el sesgo de optimismo. Conozco algunos proyectos que se encuentran en varios tipos de problemas, y todos ellos comparten esa falla. Sin embargo, a menudo, porque comenzaron con una estimación razonable, pero el cliente dijo "solo lo haremos por un millón de dólares menos", y la gerencia del contratista eligió obtener N-1 millón de dólares en lugar de obtener cero, a pesar de que no tenían razón para pensar que podrían entregarlo.
Tom Anderson el
4

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.

Tim Mensaje
fuente
3

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 .

usuario2567
fuente
3

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.

Fernando
fuente
Yo estoy totalmente de acuerdo. Siempre existe una gran incertidumbre sobre el cronograma y el costo de los grandes proyectos. Es parte del desarrollo de software, IMO. Incluso los proyectos pequeños no son tan fáciles de estimar con precisión.
ConnorsFan
3

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.

Wayne Conrad
fuente
2

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 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).

Tangurena
fuente
2

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 .

Michael Riley - AKA Gunny
fuente
2

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.

Rublo de Ron
fuente
1

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.

ChrisF
fuente
1

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.

Charles E. Grant
fuente
1

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?

Loren Pechtel
fuente
Es posible que puedan estimar adecuadamente, pero prefieren obtener la oferta y luego buscar costos y sobrecostos en lugar de perder la oferta. Por supuesto, esto selecciona para vendedores deshonestos.
David Thornley
Una estrategia común es ingresar al costo con un equipo de alta calidad. Una vez que se gana el contrato, se puede ganar dinero con el control de cambios y el mantenimiento (este último generalmente es mucho mayor que el proyecto original) y sustituyendo personal menos costoso.
Michael Grazebrook
0

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.

JB King
fuente
0

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.

SingleNegationElimination
fuente
Eso no es cierto. Muchos proyectos ágiles son sustanciales. En mi entrenamiento Scrum, señalaron que es sabio tener historias arquitectónicas y prototipos desechables en los primeros sprints. Tampoco se limitan al software: mi entrenador había ejecutado un proyecto para construir un helicóptero y sistemas de armas asociados.
Michael Grazebrook
0
  • 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.

Joeri Sebrechts
fuente
0

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.

Brian Carlton
fuente
0

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.

Erik Reppen
fuente