Quantas vezes já ouvimos essa frase não é mesmo? Inclusive já esperamos por ela quando é apresentado um erro ou algo parecido. E é de comum acordo que bug é bug. Mas uma coisa que vem acontecendo cada vez mais são as chamadas ‘mudanças de escopo’ em pele de bug.
Por exemplo, seu cliente te pede o relatório X. Você especifica os requisitos, faz um rico detalhamento funcional. Para ele a especificação de requisitos está perfeita. Após o desenvolvimento e testes, chega a hora do cliente validar a solicitação. É aí que começam os problemas. Seu cliente começa a reportar bugs e mais bugs. Você para e pensa: “Como os testers deixaram passar tantos erros?” Mas, uma rápida analisada nas descrições dos bugs, e voilá. Na verdade, o que está sendo reportado como bug são mudanças de escopo, indo desde o layout de tela (cujo protótipo o cliente recebeu e aprovou previamente) até a inclusão de novas regras de negócio. É preciso ter bom senso, lembre-se, o cliente tem sempre razão. Mas, se permita perguntar: O cliente tem sempre razão, mas ele sabe o que quer?
Essas mudanças de escopo não são proibidas. Mas deve ficar claro o que é realmente bug e o que é mudei de ideia em forma de bug. Seu objetivo deve ser deixar o cliente sempre satisfeito. Como em todo processo de desenvolvimento com o mínimo de maturidade, jogar limpo faz bem a saúde. Evidencie essas mudanças. Não se deixe levar pelo famoso “vou te quebrar esse galho”, afinal, só macaco gordo quebra galho. Se seu cliente não ficar satisfeito, é porque seu processo ainda não está claro para ele. Explique o que for preciso e quantas vezes for preciso. Comunique-se.
E não deixe que seu cliente, na sua razão, venha a te trocar por outro fornecedor por falta de comunicação.
Um abraço e até a próxima.
You must be logged in to post a comment.