Não se trata de metodologias, mas de comunicação com um cliente.
Tive muitas situações em que os clientes queriam adicionar constantemente novos recursos a um projeto não concluído e fiquei surpreso por aumentar o custo geral e os atrasos. Sendo o contexto e a personalidade desses clientes diferentes, foram necessárias abordagens diferentes, mas posso tentar isolar algumas diretrizes e conselhos:
- Certifique-se de que um cliente tenha acesso às informações gerais necessárias para entender por que uma alteração em um requisito pode afetar tanto o custo quanto o atraso . Em outras palavras, publique alguns artigos sobre essas coisas, explicando o que uma pessoa não técnica talvez não saiba.
Por exemplo, para a maioria das pessoas, é totalmente estranho que uma mudança que considerem pequena possa ter um grande impacto no projeto e ser muito cara (veja o exemplo na minha pergunta ). Se eles pedirem para fazer algumas alterações, e toda vez que você lhes disser, sem explicar nada, que eles teriam que pagar milhares de dólares quando esperassem de graça ou por algumas dezenas de dólares, provavelmente pensariam que você é apenas roubando seu dinheiro. Isso é especialmente verdade, já que alguns programadores antiéticos e empresas de software desenvolvem produtos não mantíveis (portanto, você não pode pedir para alterá-lo mais tarde por um desenvolvedor normal) e, em seguida, pede que você pague muito por cada modificação.
- Assegure-se de que um cliente tenha entendido por que a mudança específica que ele deseja tem impacto no custo . Para isso, você pode fornecer a ela os links para seus artigos (consulte o ponto anterior), ou apenas resumir, de maneira não técnica, o que é necessário para fazer uma alteração solicitada.
Essas explicações também são uma boa ideia, pois permitem que seu cliente tenha uma melhor compreensão do produto e da mudança. Em alguns casos, alguns de meus clientes acabaram dizendo que a mudança que eles queriam não era muito inteligente e que eles o fariam de outra maneira. Você também pode sugerir coisas. É muito apreciado por alguns clientes (aviso: outros odeiam) e mostra que você sabe do que está falando (em comparação com o macaco de código que acaba de traduzir os requisitos em código, sem pensar muito nas possíveis abordagens) .
- Garanta que um cliente não possa fazer o que quiser, a menos que tenha certeza. Para algumas pessoas, a única maneira é bloquear os requisitos definitivamente antes de começar a codificar . Caso contrário, é um desastre, e o projeto nunca terminará . Para outros, é apenas uma boa idéia nunca ver um projeto não terminado (em geral, meus clientes têm acesso ao produto não terminado muito cedo, para que possam fazer comentários / ajustes também).
Por exemplo, eu tinha um cliente que, depois de enviar requisitos "finais", enviou, em média, dez e-mails por dia com dez alterações de requisitos, passando por pequenas modificações ("Você pode alterar a largura da borda da zona do meio na página inicial?" de três a seis pixels? ") para as mudanças que afetaram todo o projeto (após dois meses de desenvolvimento, uma semana antes do lançamento:" Finalmente, acho que o ASP.NET é uma má idéia. Você poderia mudar para o PHP, por favor? " )
Portanto, para esse cliente , fomos obrigados a bloquear todos os requisitos antes de escrever o código. Foi escrito no contrato. Nenhuma alteração foi aceita antes do lançamento final.
Finalmente, não foi tão ruim, pois curiosamente nos permitimos ser muito organizados: o projeto foi lançado de acordo com os requisitos antigos e, alguns dias depois, começamos a próxima versão do zero com um conjunto completamente diferente de requisitos.