Como medir qualidade de código? Criatividade para bolar algum tipo de solução?
Qualidade do Trabalho
O que entende-se por qualidade de trabalho neste artigo não é a versão de qualidade que sistemas de qualidade pregam. Os sistemas ISO, LEAN, Six-Sigma e afins são todos sistemas de qualidade de processo, com a expectativa de que isto garanta a qualidade do produto, ou seja, que as peças produzidas sejam, de fato, as peças que se queria produzir. Algo na linha do teste de verificação e muito útil para fábricas.
Não interesse o quanto um Departamento de Qualidade argumente, eles só lidam com qualidade de processo. Não dá para usar estes indicadores para medir a qualidade de trabalho, qualidade técnica, de código fonte, por exemplo, usando indicadores usados para medir os processos de P&D. Departamentos de P&D e Inovação precisam de processos bem documentados, seja para gestão de códigos fonte, para solicitar novas amostras e etc. Isso é uma coisa, porém, isso não tem muito a ver com a qualidade dos resultados que este departamento obtém.
Esta série, por exemplo, resulta em um processo de medida de performance que pode ser auditado com uso de sistemas qualidade de processo.
Qualidade de trabalho é diferente de qualidade de processo. Li uma vez a definição desta diferença que fez todo o sentido:
Uma Ferrari é uma obra de arte, um carro quase artesanal. Um produto de qualidade indiscutível, mas cada Ferrari é única, o que remete a um processo sem muita qualidade. Já um lote de Fuscas podem ser todos idênticos, o que denotaria uma grande qualidade de processo… Já a qualidade do produto… Bem, um Fusca é um Fusca.
Costumo dizer que qualidade de produto é um adjetivo: bom, ruim, maravilho, estúpido, incompleto…
A Qualidade como Medida de Performance
Quando avalia-se um trabalho em termos de qualidade, o que se busca, na verdade, é usar este adjetivo para medir como está a entrega, como está o conteúdo intelectual e o quão criativo é uma determinada solução. Medir criatividade não é fácil.
Também não é fácil medir a qualidade de implementação de uma solução: todo desenvolvedor tem forte tendência a achar que o formato com que ele resolveria determinado problema como sendo o jeito correto; os demais estão errados. Costumo nesse caso, citar a necessidade de manuais de boas práticas: se está de acordo com as boas práticas e não está tecnicamente errado e, mais importante, funciona bem e é estável, então está correto.
Com base nisso, novamente se recorre a percepção do gestor para avaliação. Quando este, por questões de formação, não puder fazer tal avaliação, pode-se recorrer a outras estratégias:
- Avaliação do grupo sobre o indivíduo,
- Avaliação cruzada,
- Avaliação dos Colegas Senior,
- Terceirização da avaliação.
Há várias maneiras para um gestor avaliar como está o trabalho técnico (produto) feito pelos integrantes do seu time.
Métricas para Avaliação de Qualidade
Trabalhos errados, com defeitos e etc não podem ser avaliados sob uma ótica de qualidade. Serão avaliados sobre uma ótica de prazo: se ainda há o que fazer, não está pronto, mesmo que o prazo tenha terminado. Precisam ser corrigidos e se descumprirem prazos, é tema para outra métrica, pontualidade.
Para trabalhos que estejam funcionando a ponto de serem entregues, um bom conjunto de perguntas para avaliação é:
- É fácil de ser lido por outros membros do time?
- É fácil de ser mantido?
- Está bem comentado e documentado?
- O trabalho é escalável – ou pode ser usado em outras soluções?
- Está de acordo com os manuais de boas práticas?
- Qual o sentimento geral sobre o trabalho?
Para todas estas perguntas, aplica-se a mesma regra de avaliação, sugerida neste artigo. E assim, se chega a mais um bom indicador de performance, individualizado e que pode indicar ao gestor quais os talentos técnicos que ele possui em sua equipe, quais aqueles que possuem maior proficiência e quais precisam ser desenvolvidos.
