Eu acredito em adiar requisitos ruins. Mas também acredito que, quando você dá o seu melhor para explicar por que eles são ruins e ainda os querem, você concorda e faz seu trabalho.
Por exemplo, tive pessoas que desejam requisitos mutuamente exclusivos de algo que o aplicativo já faz. Se eu fizer isso, isso será 100% garantido. Então, eu envio o requisito de volta e digo a eles que isso violará essa outra regra de negócios que já temos em vigor e eles também querem mudar essa regra? Frequentemente, o pequeno grupo que cria um requisito específico não tem acesso à visão geral do que o restante do aplicativo pode fazer. Na maioria das vezes, quando eu enviei um desses de volta, o cliente percebeu que a regra inicial era mais crítica e decidiu que a mudança que eles desejavam não valia a pena. Quando eles decidiram fazer a alteração, fizeram isso depois de consultar as pessoas que pressionaram o requisito inicial.
Às vezes, apenas fazer perguntas de esclarecimento fará com que vejam que o problema não é tão simples quanto eles pensavam. Às vezes, você quer perguntar por que eles querem algo e chegar à necessidade real que está impulsionando a mudança. Depois de entender isso, geralmente é mais fácil ver uma solução alternativa que funciona para você como desenvolvedor e atende às suas necessidades. Se você pode apresentar essa solução em termos de como ela atenderá melhor às necessidades deles do que a sugestão original, você aumentou muito suas chances de aceitar sua alteração.
Às vezes, quando uma mudança cria estragos em um nível básico no seu design, basta fornecer a nova estimativa de horas que a mudança levará para que seja desativada. Se você combinar isso com uma avaliação de risco que indique em que funcionalidade crítica você pode estar introduzindo novos bugs e diga a eles que serão necessárias seis semanas de esforço dedicado por três pessoas, de repente não será mais tão importante.
Mas às vezes você diz a eles que essa não é uma boa ideia e por que, e eles ainda dizem: "Pena que precisamos disso". Você ganha alguns e perde alguns e, às vezes, as necessidades da empresa realmente mudaram e o aplicativo deve acomodar isso. Uma vez finalizada a decisão, não é mais o momento de questionar o que você está fazendo e o tempo de fazê-lo. Se você documentou suas objeções, você ainda deve estar em um bom lugar quando exceder o orçamento e causar erros novos e mais interessantes. E eles podem até estar mais dispostos a ouvi-lo na próxima vez que você criar um histórico de estar certo nesse tipo de coisa.
A chave para vencer muitas dessas discussões (ninguém vence todas elas) é o primeiro a criar um histórico de conhecimento do que você está falando. Em seguida, envie um documento escrito que indique as preocupações que você tem (muitos gerentes são adversos ao risco, é mais provável que eles não desejem que alguém tenha um documento que os comprove errado mais tarde, para que prestem mais atenção ao que você coloca por escrito) e finalmente para garantir que eles entendam todos os custos (não apenas horas, mas riscos de segurança, introdução de novos bugs, prazos ausentes etc.) de fazer a alteração. A mudança não é gratuita e eles precisam entender isso. A próxima chave é fazer isso como um adulto e não como uma criança chorona ("mas eu não quero usar ... porque não gosto"). Faça um argumento comercial para não fazer isso e você terá muito mais em adiar um requisito ruim.