Olá pessoal,
No post de hoje vou falar sobre qualidade externa e interna de quando vamos desenvolver um produto. Tá, não se preocupe porque vou explicar com mais detalhe durante o post, porém responda a pergunta a seguir, se a resposta for sim, então já sabe o assunto que vamos tratar.
Algum cliente seu já pediu para você reduzir um pouco a sua estimativa para entregar alguma tarefa?
Se sua resposta foi sim, é disso que vamos falar:
como convencer o cliente que a qualidade não é negociável?
Lets go…
Starting
Como vocês, que tem acompanhado o blog e meu twitter, puderam ver, tenho me dedicado ao mundo Agile, mas o que vou falar aqui não está só ligado ao Agile, mas foi onde eu consegui perceber isso de forma mais face-to-face com o cliente e de certo modo foi onde houve menos questionamentos por parte dele e até uma aceitação de mudanças sem muita discussão. Eu sempre sofri com esse mal (desde da época de freelance), do cliente pedir para mudar uma estimativa, porém ele não queria mudar o escopo dele e sabemos que isso não é nada bom. Mas, como contornar a situação sem gastar muito tempo? Para isso é preciso ter duas coisas bem claras em mente:
- Qualidade externa: aquilo que o cliente vê, tem acesso, que é o front-end, lentidão, etc.
- Qualidade interna: aquilo que o cliente não tem acesso, tais como: refactoring, covertura de testes, code clear etc.
Quando o cliente pede para reduzirmos a estimativa ele está afetando a qualidade interna, algo como: “Sei que você tem a melhor equipe, com os melhores profissionais, será que não dá para fazer em 1 ou 2 dias a menos (isso aqui dá -16 hrs de trabalho, o que é muita coisa)?”
Normalmente não dá para mudar isso, pois nós sabemos do impacto. E como resolver isso?
Resposta ao cliente
Podemos perguntar ao cliente se o escopo não pode ser alterado, que aquela parte onde temos as mensagens iterativas com o usuário não poderia ficar para o futuro e que por agora trataríamos com mensagens mais simples possível, por exemplo. Ou mudar o nível de importância, assim isso impactará em outras e saberemos o que deve ser entregue primeiro e isso forçará o product owner mover o backlog. Mas abrir mão da qualidade interna é algo que não deve ser feito, pois já sabemos dos problemas que vamos encontrar e o cliente não vai levar em conta essa redução de estimativa quando os problemas surgirem, principalmente se estes afetarem o “bolso dele”. Pense: “uma vez que se penetra que uma base de código se deteriore, é muito dificil recuperar a qualidade mais tarde”.
Um sistema com alta qualidade interna pode ainda ter baixa qualidade externa, porém um com baixa qualidade interna raramente terá uma qualidade externa alta, ou seja, não dá para construir algo bom se a base está pobre, então daí que dizemos que a qualidade interna simplesmente não é negociável.
Vou ficando por aqui. Espero que tenham gostado do post.
Abracos, see ya!
