“Faça certo, contra a vontade do cliente” - como é chamado? [fechadas]

Conhecemos a situação ideal de negociar correções de especificações com o cliente, fazendo com que as especificações façam o que o cliente queria, não o que disseram ou pensaram que queriam. Isso é negociar, explicar.

Às vezes, não conseguimos convencer o cliente. Somos forçados a produzir quebrado, conforme projetado. Isso, chamado "demonologia" por mérito dos magos convocando demônios e demônios cumprindo seus desejos muito literalmente, causando a morte do mago como resultado, é outra abordagem que deixará o cliente muito insatisfeito quando perceber seu erro e, claro, tentar culpar o desenvolvedor.

Agora, apenas enfrentei uma abordagem muito diferente: o cliente criou especificações simples que não respondem a algumas ressalvas críticas e não está disposto a corrigi-las, admitir os erros óbvios e aceitar as correções sugeridas. O produto fabricado com essas especificações será gravemente quebrado e possivelmente poderá custar vidas humanas. Ainda assim, é tarde demais para desistir completamente do contrato. O contrato tem cláusulas punitivas para isso, que não podemos realmente aceitar.

A decisão do chefe? Fazemos o trabalho corretamente e mentimos ao cliente que o fizemos de acordo com as especificações. Os algoritmos em questão estão ocultos o suficiente sob a superfície, o produto fará o trabalho muito bem, não falhará na situação de ressalva e, a menos que alguém se esforce demais, nunca descobrirá que não o quebramos conforme solicitado.

Existe algum nome comum para essas táticas de execução de especificações?

O (s) requisito (s) em questão é um requisito defeituoso, ausente ou derivado? Importa. Se o requisito estiver ausente ou puder ser derivado de outro requisito, é simples dizer que é um requisito derivado e que você está cumprindo os termos do contrato. E não há razão para esconder isso.

Se o requisito contradizer um requisito, como você validará o sistema sem uma alteração nos requisitos? A razão mais provável para o governo não querer alterar os requisitos é "você cobrará mais deles". Se você já está implementando sem nenhum custo extra, há poucas razões para eles se oporem.

Finalmente, como esse é um trabalho do governo, haverá uma trilha de papel para todos esses tipos de decisões, se você quiser. Se os funcionários governamentais responsáveis ​​pelo seu projeto não concordarem verbalmente com a alteração dos requisitos, você poderá registrar formalmente uma variação dos requisitos. Tenho certeza de que qualquer solicitação de variação usando termos como "vida em risco" terá ZERO possibilidade de ser rejeitada. De qualquer forma, não há motivo para "esconder" que você não está cumprindo os requisitos, pois isso pode resultar em danos punitivos à sua empresa, mesmo que você esteja tentando fazer a coisa certa. Nesse caso, a coisa certa é escalar formalmente o problema e garantir que sua empresa esteja protegida. Não é para esconder o que você está fazendo do cliente, porque isso também está errado,

Eu não sou um advogado. Você não deve agir nem se abster de agir sobre quaisquer opiniões que eu forneça.

A liberação de um produto que poderia colocar vidas em risco devido a uma falha de design (e não como uma parte necessária de sua operação) que você conhece provavelmente colocará o lado errado da legislação de saúde e segurança, além de expor sua organização a reivindicações e custos legais. Na maioria dos territórios e situações, a lei da terra anula qualquer contrato que você possa ter, de modo que essa deve ser sua prioridade.

Em outras palavras: esclareça sua posição legal específica antes de continuar.