O setor de desenvolvimento de uma empresa muitas vezes é visto como o setor operacional, onde pessoas passam seu tempo construindo sites, sistemas, apps etc. Os prazos e as especificações são previamente debatidos por um grupo X de pessoas, e quando isso é decidido, essas informações são entregues aos programadores, que por fim apenas digitam sem parar regras de negócio em uma linguagem X ou Y, como máquinas programadas apenas para vomitar códigos.
Sabemos que isso é verdade em grande parte das empresas, mas não deveria ser. Antes de um programador iniciar uma tarefa, houve muita pesquisa, diversos testes, forks de projetos parecidos, conversas na hora do café e mais pesquisa. A ideia não é apenas entregar mais um software, mas entregar software de boa qualidade, testado e escalável.
Apesar de se tratar da área de exatas, programação exige criatividade. Não da maneira que a maioria das pessoas estão acostumadas. Não estamos sentados em algum lugar pensando em um “jingle chiclete” ou em um slogan marcante… Não que isso não seja importante, porque é. Mas esse tipo de criatividade é diferente das que executamos no nosso dia a dia.
Mas, ainda assim, em muitas empresas nesse Brasilzão afora continuam considerando programadores como máquinas digitadoras. Ao longo dos anos somos avaliados por número de atividades entregues e o temido e maçante apontamento de horas, por entregas antes ou depois da deadline e demais números que não fogem do convencional e conservador. Não digo que essas métricas não devam ser utilizadas, mas sim que devem ser questionadas e avaliadas de acordo com o perfil da equipe. Quem nunca temeu a hora de estimar uma tarefa?
Indicadores tradicionais costumam apontar resultados apenas do período de início e final de desenvolvimento, mas acaba pecando em medir resultados que nem sempre são colocados na conta do time, como número de erros reportados por clientes, ou então tempo despendido em manutenção/melhoria da feature por outro dev. Muitas vezes, um programador se sente acuado ou até motivado em gerar um bom indicador, que passa a focar apenas em melhorar seus gráficos, e não na qualidade do seu trabalho. Frases como “Se retornarmos apenas os dados que precisamos, a consulta melhorará X% em performance.” são substituídas por “Retorna tudo aí, são só alguns milissegundos, daqui a pouco a gente precisa de algo a mais, daí já tá pronto”.
Essas práticas, apesar de serem implementadas para medir resultados, podem apenas mostrar dados que não condizem com a realidade da equipe e com seu potencial, além de que se forem implantadas de maneira estritamente rigorosa, acabam minando toda a criatividade de sua equipe de programadores.
Toda metodologia de projetos cita a implantação de indicadores como uma boa prática, mas sempre alertam para conferir se os indicadores são a melhor solução para medir a performance de seu time.
Devemos ser flexíveis e ponderar, aonde o desenvolvedor contribui para a empresa além do tradicional código, como em questão de motivação e confiabilidade, qualidades que dificilmente seriam consideradas nestes indicadores, mas que são de suma importância para o time.
Espero que um dia essa mentalidade de linha de produção de software acabe, e que todo profissional de TI tenha liberdade para contribuir com seu ambiente de trabalho, agindo de maneira criativa, pró-ativa e inovadora, sem se sentir pressionado por números frios.