Empresas tentando tomar decisões técnicas

Muitas vezes, encontramos cenários em que a empresa promete a um cliente um novo recurso. A empresa promete que o recurso seja implementado de uma maneira específica. Esses detalhes técnicos prometidos pelo negócio geralmente são ruins. Infelizmente, o cliente agora está definido e deseja que esse recurso seja implementado da maneira descrita pela empresa.

No final, a empresa deseja apenas que esse recurso seja concluído sem levar em consideração a qualidade e a capacidade de manutenção. Existe uma boa maneira de recuar? Como podemos explicar à empresa que fornecer detalhes técnicos antes da coleta dos requisitos é uma má idéia?

Essa é uma questão organizacional. Se os superiores não entenderem isso, não há muito o que fazer. Tente explicar o problema para seus chefes não técnicos, mas não se surpreenda quando não chegar a lugar algum.

É um problema comum para desenvolvedores que trabalham em empresas que não são de desenvolvimento que, por qualquer motivo, vendem software.

Não é uma tática agradável, mas você pode simplesmente espancá-los com provas. No início de um projeto, anote exatamente por que ele falhará (porque os detalhes técnicos eram ruins) e envie por e-mail para as pessoas relevantes. Continue enviando um e-mail para eles o tempo todo e, quando o projeto acabar com um desastre com os clientes irritados, cite os e-mails que você enviou em todas as oportunidades. Isso pode gerar má vontade, mas não há realmente nenhuma boa maneira de tentar corrigir um problema sistêmico como esse.

Do ponto de vista do desenvolvedor, esse é um dos dois tipos de falha, quando se trata de escrever especificações. A outra coisa que pode acontecer é quando as vendas fazem grandes promessas e, depois, recorrem à TI para especificar o projeto e entregar um artigo que pode ser transformado em cotação.

O problema é que muitas vezes essa é a maior parte do trabalho. Muito provavelmente, o código real está apenas implementando os detalhes da abordagem apresentada em uma especificação bem projetada.

Ao mesmo tempo, as vendas acham difícil cobrar preliminares, como o desenvolvimento de especificações. Ainda não estamos na cama com o cliente, e é estranho pedir dinheiro por eles para descobrir quanto dinheiro lhes custa.

É por isso que a maioria dos projetos "novos" com novos clientes acaba sendo líder em perdas. Se você é LUCKY, usa esse primeiro projeto para treinar o cliente em como ser um cliente e pode começar a ganhar seu traseiro no segundo projeto ou o contrato de manutenção no primeiro.