Pelo menos foi o que o fizeram os designers Todd Camasta e Bruce Schlickbern quando trabalhavam na versão final do jogo Battle Chess (Amiga, PC,Apple II e Nintendo NES) na década de 80.
Quem trabalha em uma grande organização compreende os meandros e difíceis decisões por parte da diretoria quando seus projetos precisam passar por um comitê de aprovação. Muitas vezes esses projetos já finalizados são criticados em algum detalhe ou recebem sugestões irrelevantes que não acrescentam à ideia do projeto. Alguns desses encontros são comandados por muitos “caciques”, o que dificulta ainda mais a finalização de um projeto, fazendo com que o prazo seja postergado, muitas vezes, até que todos entrem num consenso geralmente no último dia do deadline. As razões pelas quais as organizações têm dificuldades em aprovar um projeto são muitas e vão desde um alinhamento correto junto à imagem da organização ou cliente, até por um capricho pessoal, tendendo haver algumas pessoas que só considerarão cumprido o seu trabalho se provocar alguma mudança no plano apresentado. A obvia e apropriada solução seria alterar o processo de aprovação ou substituir a diretoria, com essa visão incorreta, sobre o seu projeto, mas sabemos que esta opção é praticamente impossível, ao alcance de quem têm um trabalho submetido a este tipo de comitê.
E foi neste último sentido que o jogo lançado em 1988 se tornou uma lenda (uma lenda mesmo, uma vez que existem poucas fontes relatando a experiência) nas teorias organizacionais e produtividade pessoal. Battle Chess é um jogo de xadrez no qual as peças são animadas, movimentando-se pelo tabuleiro com estilo próprio e entrando em combate após cada lance. O design gráfico foi inspirado nas sequências de xadrez dos filmes Star Wars, recebendo em sua época diversos prêmios.
Durante a criação do jogo pela clássica produtora Interplay Entertainment, a diretoria de aprovação era conhecida por sempre solicitar algum ajuste antes de deixar o desenvolvimento seguir, causando problemas nos prazos apertados e desentendimentos com a equipe. Diferentemente do esperado, as solicitações eram vagas e sem argumentos, onde não havia nenhum problema no jogo, causando ira na equipe.
A solução desenvolvida foi inserir um problema proposital e visível, aos olhos dos diretores, a fim de desenrolarem os palpites vagos e infortúnios. No caso do jogo Battle Chess, o artista encarregado das animações da Rainha chegou a uma solução bizarra (desesperadora) e inovadora: Nos movimentos da peça ele incluiu um “patinho de estimação”que ficava circulando ao seu redor, agitando as asas quando a Rainha era atingida. A solução destoava completamente da pegada medieval do jogo. Quando as alterações foram encaminhadas para o comitê de aprovação, o diretor responsável disse: “…Gostei de tudo,apenas remova esse pato…”
O termo “just remove the duck” na verdade é oriundo da Lei da trivialidade de Parkinson – 1957, no qual os pormenores são discutidos exaustivamente, terminando sem conclusões ou real contribuição, trazendo como solução, a apresentação um erro proposital de fácil localização para seus avaliadores, dentro de um projeto que necessite de urgente aprovação.
O fluxo organizacional de uma grande empresa é muitas vezes específico, mas a hierarquia e comitês de aprovação são uma constante nestes lugares, sendo às vezes mais fácil o desenvolvedor aprender a contornar barreiras involuntárias, causadas pelos “caciques”, com uma solução criativa, em vez de aguardar que as sugestões sejam alteradas ou removidas por quem os criou, fazendo com que o projeto possa ir adiante, garantindo satisfação para todas as partes. ;)
Talvez você já tenha sido vítima de um “duck” dentro de um projeto e nunca saberá.
POR 
ENG