Estoy tratando de encontrar un ejemplo del fracaso del diseño por comité, es decir, donde la sugerencia de todos tiene el mismo peso y el resultado final es un completo desastre que realmente no satisface los requisitos originales.
El ejemplo podría ser de absolutamente cualquier campo, siempre que sea accesible para una audiencia general.
A pesar de que estoy de acuerdo con David en que el diseño por comité es sarcasmo [y un fenómeno real, también estoy de acuerdo con Michael Hogan :-)], la pregunta es sobre ejemplos (no sobre el término "diseño por comité").
Entonces, echa un vistazo a este artículo .
Hay una lista de proyectos diseñados por comité en la parte "Estudios de caso":
Otros ejemplos:
Además, Fred Brooks escribió sobre algunos ejemplos en su The Mythical Man-Month:
Una pequeña retrospección muestra que, aunque muchos sistemas de software buenos y útiles han sido diseñados por comités y construidos por proyectos de varias partes, los sistemas de software que han entusiasmado a fanáticos apasionados son los productos de una o unas pocas mentes de diseño, grandes diseñadores. Considere Unix, APL, Pascal, Modula, la interfaz Smalltalk, incluso Fortran; y contraste con Cobol, PL/I, Algol, MVS/370 y MS-DOS
Por último, ejemplo de la página wiki " Diseño por comité ":
Un ejemplo de una decisión técnica que se dice que es un resultado típico del diseño por comité es el tamaño de celda del modo de transferencia asíncrono (ATM) de 53 bytes. La elección de 53 bytes fue más política que técnica. Cuando el CCITT estaba estandarizando ATM, las partes de los Estados Unidos querían una carga útil de 64 bytes. Partes de Europa querían cargas útiles de 32 bytes. La mayoría de las partes europeas finalmente aceptaron los argumentos presentados por los estadounidenses, pero Francia y algunos otros resistieron por una longitud de celda más corta de 32 bytes. Un tamaño de 53 bytes (48 bytes más encabezado de 5 bytes) fue el compromiso elegido.
El diseño por comité es un fenómeno real, especialmente en proyectos gubernamentales donde un comité de representantes electos establece y controla las decisiones presupuestarias. El curso SAE 550 de la Universidad del Sur de California , "Arquitectura de sistemas y el proceso político", es un estudio de los esfuerzos de ingeniería que han sido fuertemente influenciados por el diseño por comité.
El curso cubre una serie de estudios de casos de la industria aeroespacial. Para cada estudio de caso, se describen los objetivos iniciales, se puede describir una solución de ingeniería óptima y se explora el impacto de la política en la toma de decisiones de ingeniería. El curso presenta un conjunto de heurísticas de diseño que los ingenieros pueden usar para adaptarse a las realidades del diseño por comité en el proceso político.
Puede valer la pena ponerse en contacto con el instructor del curso para solicitar uno o dos casos de estudio. El estudio de caso del transbordador espacial incluye una discusión fascinante que analiza cómo los requisitos contradictorios de la Fuerza Aérea y la NASA para el tamaño de las cargas útiles de la misión afectaron la bahía de carga del transbordador. Se consideran varios otros factores para explicar cómo el transbordador pasó de ser una plataforma de lanzamiento de alta frecuencia reutilizable a una plataforma de lanzamiento de baja frecuencia.
Estoy tratando de encontrar un ejemplo de la falla del diseño por comité ...
El diseño por comité no es en realidad un método serio. es sarcasmo _ Por lo general, esa frase se usa para describir un proceso de diseño que es extremadamente ineficiente y conduce a una sobrecarga de funciones. Es ineficiente porque toma más tiempo del necesario para tomar decisiones. Conduce a la sobrecarga de características, porque las malas decisiones a menudo las toman personas que simplemente aceptan las ideas de los demás, independientemente del mérito.
Para un problema de diseño que tiene un espacio de solución real, el óptimo local sigue siendo un óptimo. Eso significa que el resultado no debe ser un desastre total (ignorando el hecho de que el comité puede estropearlo).
Sin embargo, si el problema en cuestión requiere enfoques novedosos y asumir riesgos, la solución del comité podría convertirse en una dificultad.
Normalmente, los análisis de compensación detectan los problemas y los hacen evidentes para que todos los entiendan. Y luego es el trabajo del gerente del proyecto (o del diseñador jefe) tomar la solución de bajo riesgo y alta ganancia.
Droide lacónico