Desenvolvendo um recurso cujo único objetivo seja removido? [fechadas]

Qual é o nome do padrão no qual colaboradores individuais (programadores / designers) desenvolveram um artefato com o único objetivo de servir como um desvio para que o gerenciamento possa remover esse recurso no produto final ?

Este é um folclore que ouvi de um ex-colega que trabalhava em uma grande empresa de desenvolvimento de jogos. Nessa empresa, é sabido que a gerência intermediária é pressurizada para "fornecer insumos" e "fazer alterações" no produto, caso contrário correm o risco de serem vistos como não contribuindo para o projeto. Essa situação atrasou muitos projetos devido a essas "entradas de gerenciamento" supérfluas.

Em um projeto da empresa acima, os artistas e desenvolvedores criaram um personagem animado supranumerário que aparece em todas as cenas e se destaca como um polegar dolorido. Eles o projetaram de tal maneira que ele pode ser facilmente removido antes do jogo ser lançado (foi quando os jogos ainda eram vendidos na mídia física e não em um produto para download). Obviamente, a gerência votou para remover a animação. Do lado positivo, a gerência não introduziu alterações desnecessárias que atrasariam o projeto porque demonstraram que forneciam insumos construtivos ao produto.

Esse padrão de processo tem um nome entre os programadores de jogos que trabalham em empresas, mas eu esqueci qual era o nome real. Eu acredito que é algo de pato . Qualquer um pode ajudar a apontar o nome e, talvez, alguma referência bastante credível de como o padrão se desenvolve?

É chamado de pato , de uma lenda que supostamente vem do Battle Chess da Interplay:

Isso começou como uma parte do conhecimento corporativo da Interplay. Era sabido que os produtores (uma posição na indústria de jogos, aproximadamente equivalente aos PMs) tiveram que fazer uma alteração em tudo o que foi feito. A suposição era que, inconscientemente, eles sentiam que, se não sentissem, não estavam agregando valor.

O artista que trabalhava nas animações da rainha para o Battle Chess estava ciente dessa tendência e apresentou uma solução inovadora. Ele fez as animações para a rainha da maneira que achou melhor, com uma adição: deu à rainha um pato de estimação. Ele animou este pato através de todas as animações da rainha, fazendo-o bater nos cantos. Ele também tomou muito cuidado para garantir que nunca se sobrepusesse à animação "real".

Eventualmente, chegou a hora do produtor revisar a animação definida para a rainha. O produtor sentou-se e assistiu a todas as animações. Quando terminaram, ele se voltou para o artista e disse: “Isso parece ótimo. Apenas uma coisa: se livrar do pato.

Simplesmente vejo isso como gerenciamento validando seu próprio objetivo em um projeto, estendendo o trabalho programado o máximo possível ou criando um trabalho ocupado sem sentido para manter as pessoas ocupadas ou trabalhando.

Eu já vi isso pessoalmente em cinco tipos diferentes:

• Projetos governamentais - Muitas vezes, se o projeto de um gerente ficar com pouco orçamento ou tempo, ele será ruim para ele / ela no futuro. Eles podem receber elogios por um bom trabalho, mas correm o risco no futuro de que seu orçamento seja reduzido no próximo ano, se não puderem justificá-lo. Por causa de como o orçamento funciona no governo, é por isso que os projetos do governo buscam utilizar o máximo possível do orçamento designado.

• Um gerente possivelmente obsoleto, com uma equipe grande e responsabilidade por software que é relativamente fácil de manter ou gravar. O perigo é real no mundo corporativo de que, quando tentarem perder peso, procurarão os gerentes de nível médio com a menor responsabilidade real e sairão daí. Eles sentem que, ao superestimar e criar escopo desnecessário, protegem suas posições.

• Algumas empresas de software são basicamente os clubes Good Ol 'Boy, onde possuem softwares simples ou herdados que cercam um mercado lucrativo e de nicho. Normalmente, o dinheiro é relativamente fácil, as ambições, relativamente baixas, e todos os gerentes são melhores amigos que tentam validar o objetivo uns dos outros enquanto levam para casa grandes salários. É impossível espaço para avanço nessas empresas, a menos que você esteja conectado. Muitas vezes, tentam validar sua própria importância, criando um trabalho ocupado sem sentido em um problema já bem resolvido.

• Alguma linguagem de contrato requer lançamentos regulares e melhoria contínua no software. Para um problema bem resolvido, encontrar recursos exclusivos e novos pode ser difícil ou impossível. Muitas vezes, trabalho ocupado será atribuído, talvez para adicionar algo e depois removê-lo na próxima versão.

• O gerente está legitimamente preocupado em manter a equipe unida, por culpa ou apenas tentando ser legal. Ele tentará validar o propósito de sua própria equipe para mantê-los empregados sob ele.

Meu chefe chamou isso de "estratégia da fonte". Ele projetou uma nova ala de computadores para uma universidade com uma enorme fonte na frente. A asa foi aprovada, mas sem a fonte, exatamente como planejado.

Isso foi há 50 anos, então isso não é novidade.

Em alguns projetos em que trabalhei, os denominamos "barracões de bicicleta" como um aceno ao termo problema do barracão de bicicleta . Esse termo veio de uma passagem do livro A Lei de Parkinson , descrevendo as usinas nucleares como sendo tão complicadas que os gerentes teriam medo de tocar em qualquer coisa, mas um barracão de bicicleta é tão simples que todos precisam se mexer e mexer com ele para dar a aparência de " gerenciando "coisas.