¿Desarrollar una función cuyo único propósito sea eliminar? [cerrado]

¿Cuál es el nombre del patrón en el que los contribuyentes individuales (programadores / diseñadores) desarrollaron un artefacto con el único propósito de servir como un desvío para que la administración pueda eliminar esa característica en el producto final ?

Este es un folklore que escuché de un ex colega que solía trabajar en una gran empresa de desarrollo de juegos. En esa compañía, es bien sabido que la gerencia media está presionada para "dar aportes" y "hacer cambios" al producto, de lo contrario corren el riesgo de ser vistos como no contribuyentes al proyecto. Esta situación ha retrasado muchos proyectos debido a estos "insumos de gestión" superfluos.

En un proyecto en la compañía anterior, los artistas y desarrolladores crearon un personaje animado supernumerario que aparece en cada escena y sobresale como un pulgar dolorido. Lo diseñaron de tal manera que se pueda quitar fácilmente antes de que se envíe el juego (esto fue cuando los juegos todavía se vendían en medios físicos y no como un producto descargable). Obviamente, la gerencia votó para eliminar la animación. En el lado positivo, la gerencia no introdujo cambios innecesarios que hubieran retrasado el proyecto porque han demostrado que proporcionaron aportes constructivos al producto.

Este patrón de proceso tiene un nombre entre los programadores de juegos que trabajan en empresas, pero olvidé cuál era el nombre real. Creo que es pato, algo . ¿Alguien puede ayudar a señalar el nombre y quizás alguna referencia creíble de cómo se desarrolla el patrón?

Se llama pato , de una leyenda que supuestamente proviene del Ajedrez de batalla de Interplay:

Esto comenzó como una pieza de la tradición corporativa de Interplay. Era bien sabido que los productores (una posición en la industria del juego, aproximadamente equivalente a los PM) tuvieron que hacer un cambio en todo lo que se hizo. Se suponía que inconscientemente sentían que si no lo hacían, no estarían agregando valor.

El artista que trabajaba en las animaciones de la reina para Battle Chess era consciente de esta tendencia, y se le ocurrió una solución innovadora. Hizo las animaciones para la reina de la forma en que sintió que sería mejor, con una adición: le dio a la reina un pato mascota. Animó a este pato a través de todas las animaciones de la reina, lo hizo aletear por las esquinas. También tuvo mucho cuidado para asegurarse de que nunca se superponga con la animación "real".

Finalmente, llegó el momento de que el productor revisara el conjunto de animación para la reina. El productor se sentó y observó todas las animaciones. Cuando terminaron, se volvió hacia el artista y le dijo: “Eso se ve muy bien. Solo una cosa: deshacerse del pato.

Simplemente lo veo como una gestión que valida su propio propósito en un proyecto extendiendo el trabajo programado el mayor tiempo posible o creando un trabajo ocupado sin sentido para mantener a la gente ocupada o trabajando.

He visto esto personalmente en cinco tipos diferentes:

• Proyectos del gobierno: muchas veces, si el proyecto de un gerente ejecuta un presupuesto o tiempo insuficiente, entonces le resultará malo en el futuro. Pueden recibir elogios por el buen trabajo, pero corren el riesgo en el futuro de que su presupuesto se reducirá el próximo año si no pueden justificarlo. Debido a cómo funciona el presupuesto en el gobierno, esta es la razón por la cual los proyectos del gobierno apuntan a utilizar la mayor cantidad posible de su presupuesto asignado.

• Un administrador posiblemente obsoleto que tiene un gran equipo y la responsabilidad del software que es relativamente fácil de mantener o escribir. El peligro es real en el mundo corporativo de que cuando intentan perder peso, buscarán a los gerentes intermedios con la menor responsabilidad real y avanzarán desde allí. Sienten que al sobreestimar y crear un alcance innecesario protegen sus posiciones.

• Algunas compañías de software son básicamente clubes Good Ol 'Boy donde tienen un software simple o heredado que acorrala un mercado lucrativo pero nicho. Por lo general, el dinero es relativamente fácil, las ambiciones son relativamente bajas y todos los gerentes son mejores amigos que intentan validar el propósito de los demás mientras se llevan a casa grandes cheques de pago. El espacio para el avance es imposible en tales compañías a menos que esté conectado. A menudo intentarán validar su propia importancia creando un trabajo ocupado sin sentido en un problema ya resuelto.

• Algunos términos del contrato requieren lanzamientos regulares y mejoras continuas en el software. Para un problema bien resuelto, encontrar características únicas y nuevas puede ser difícil o imposible. A menudo se asignará trabajo ocupado, tal vez para agregar algo y luego eliminarlo principalmente en la próxima versión.

• El gerente está legítimamente preocupado por mantener al equipo unido, ya sea por culpa o simplemente tratando de ser amable. Intentará validar el propósito de su propio equipo para mantenerlos empleados debajo de él.

Mi jefe lo llamó la "estrategia fuente". Diseñó un nuevo ala de computadora para una universidad con una fuente masiva en el frente. El ala fue aprobada pero sin la fuente, exactamente como estaba previsto.

Eso fue hace 50 años, así que esto no es nada nuevo.

En algunos proyectos en los que he trabajado, los hemos llamado "cobertizos para bicicletas" como un guiño al término problema de cobertizo para bicicletas . Este término proviene de un pasaje del libro La Ley de Parkinson , que describe las plantas de energía nuclear como tan complicadas que los mal administradores tendrían miedo de tocar cualquier cosa, pero un cobertizo para bicicletas es tan simple que todos tienen que vacilarse y jugar con él para dar la apariencia de " gestionando "cosas".