Barrapunto

Cuando tu vas a comprarte un coche, el del concesionario te dice: "lo tendras en 3 meses" y casi con toda seguridad lo tienes en 3 meses. Cual es el problema, que en la informática, es como si el que va a comprar el coche te dice... "quiero el coche esta tarde" y el del concesionario le dice.. "por supuesto" entonces es cuando empiezan los problemas

El problema, dependiendo del proyecto, se puede llamar comerciales, y la falta de realismo de las planificaciones :). Se vende el oro y el moro, y que va a estar listo en un tiempo que luego no se cumple. Lo peor es que la realimentación de proyectos no se mete en las nuevas planificaciones.

De todas maneras, en todas partes cuecen habas. Mira lo que le pasó a Airbus con el A380 y a Boeing con el 787 por poner un ejemplo, de dos industrias donde está estandarizado y documentado hasta el par de apriete de un tornillo de un asiento.

Creo que estamos mezclando dos cosas que en mi opinión son distintas. Por una parte el tema del coche en 3 meses; el concesionario te lo puede asegurar porque tienen una cadena de producción que conocen y que controlan perfectamente, y para ellos la fabricación de un nuevo coche no supone ningún riesgo tecnológico. Les puede suponer un riesgo logístico, pueden tener problemas con la distribución... pero no te están desarrollando/investigando elementos del coche.

Sin embargo el desarrollo/investigación es el que plantea problemas (p.e. el desarrollo de los aviones que has comentado) porque es algo que no se conoce (nadie lo ha hecho antes) y vas a tener que solucionar problemas tecnológicos de toda índole según vayan apareciendo. Algunos se podrán prever, pero otros simplemente aparecerán porque lo que se está haciendo no es sencillo y hay muchas cuestiones que resolver.

IMHO, creo que el problema del desarrollo del software es que no se tiene clara la diferencia entre desarrollo/fabricación y desarrollo/investigación, porque en la mayoría de los casos siempre va a haber un componente de ambos. Humildemente pienso que el cliente ni el comercial jamás están en condiciones de caracterizar un nuevo proyecto, y sólo alguien con mucha experiencia (técnica) se podría acercar, aunque indudablemente se podrá equivocar (y se equivocará). Si una empresa siempre hace proyectos del mismo tipo, sería importante que aprendieran de sus proyectos anteriores para que cada la parte desarrollo/fabricación fuera más importante que desarrollo/investigación, pero tal y como están las cosas eso es otra historia.

Lo que me gusta de las metodologías ágiles es que implican al cliente en el desarrollo, y que éste puede conocer en todo momento el estado del proyecto y la dificultad técnica que está teniendo. Otra cosa es lo que ha comentado alguien en otro comentario, que hay clientes que se las trae floja el desarrollo y sólo quieren el producto en X tiempo... en ese caso siempre habrá conflicto porque desarrollar software casi nunca es fabricar software.

No viene mucho al caso, pero ya que lo has mencionado, en el A380 uno de los retrasos importantes fue que porque en un sitio usaban Catia V4 y en otro V5, al pasarse los diseños, se perdió información, y en este caso hubo problemas con el cableado.

Con el 787, hubo problemas en los ensayos de carga estática del ala con cargas relativamente pequeñas, lo que obligó a rediseñar parte de una sección del fuselaje. Además han tenido diversos problemas de integración, probablemente también porque Boeing tiene menos batallas que Airbus en un modelo de fabricación tan distribuido.

En el A380 en los ensayos de carga estática un el ala se quedó en caga última un pelín por debajo del factor de seguridad, y también se tuvieron que hacer pequeños retoques.

Pero si te fijas, esto son problema de la fase de diseño, que pueden ser muy diversos y la estandarización no tiene por qué resolverlos, mientras que en el ejemplo del coche se habla de producción, que es una cosa diferente y no debe confundirse el diseño. Eso sí, en todas las etapas y campos, los directivos y comerciales son un problema adicional más que otra cosa.