Excelência em métricas: evitando o mundo invertido

Independente de como um projeto de desenvolvimento de software foi contratado (preço fixo, tempo e materiais, etc.) ou como foi gerenciado do ponto de vista da metodologia (Agile, Waterfall, Prince2), ao final, um software será criado. Este produto, terá um custo específico, um tamanho, diferentes indicadores de qualidade e um conjunto de fatores, independente do contrato ou dos métodos, que ajudarão a determinar, se, por exemplo, o custo está adequado ao produto final.

É essencial que se faça uma distinção clara entre os conceitos de “produto” e “projeto”, lembrando que o objetivo de um projeto é criar um produto, um serviço ou alcançar um determinado resultado. Embora a diferença entre ambos os conceitos seja clara, na perspectiva das métricas, pode não estar tão óbvio: a mesma métrica (ou indicador) pode ser associada a significados diferentes, aplicados em ambos os termos. O tamanho de um projeto pode ser entendido, por exemplo, por sua duração (tempo) ou esforço do projeto. Sua qualidade pode ser avaliada considerando-se o quão bem ou mal este projeto foi gerenciado e se um conjunto de indicadores foi cumprido ou não. O tamanho ou a qualidade de um produto (que foi criado em um projeto), por sua vez, são conceitos totalmente diferentes, distante da perspectiva do projeto.

Projetos, produtos e métricas

Podemos armazenar e gerenciar dezenas de métricas do projeto, mas as métricas do projeto sem métricas do produto fornecem às vezes indicadores isolados, perdendo-se informações mais estratégicas. Pode-se determinar se o esforço investido no projeto foi consistente com a estimativa do projeto. Da mesma forma, é possível estabelecer se o cronograma do projeto foi cumprido e se foi melhor do que o esperado. Há muitas outras métricas extremamente úteis, que nos dizem se um projeto está aderindo a um conjunto de regras e indicadores pré-estabelecidos. Mas, infelizmente, eles não fazem muito mais do que isso.

No entanto, se adicionarmos um conjunto de questões aparentemente simples, os resultados podem ser totalmente diferentes: o esforço planejado ou a qualidade esperada e acordada é consistente com o que deveria ser? Os diferentes KPIs são consistentes e fornecem resultados e conclusões confiáveis?

É necessário ir além dos aspectos do projeto e ter uma visão mais ampla das métricas e indicadores de projetos, considerando fatores que são extremamente valiosos e fazem sentido em termos cotidianos e práticos – com uma série de conclusões estratégicas ao nível do CIO, com uma projeção no nível da empresa (internamente) e outra ao nível do mercado (externamente). Reunir todos esses aspectos em diferentes níveis é uma ótima oportunidade para melhorar os conhecimentos adquiridos com as métricas, os resultados e as conclusões. E se aplica a projetos, produtos, aspectos financeiros, indicadores competitivos que afetam uma empresa ou expectativas futuras de estratégias.

Existem tantos indicadores e KPIs que podem ser aplicados, mas ainda há questões-chave que precisam ser abordadas. Mesmo que gerenciemos dezenas de métricas, será que medimos de maneira realista a produtividade, a qualidade e o custo do produto, entre outros? Podemos comparar os resultados com outros projetos desenvolvidos em diferentes tecnologias, usando diferentes ferramentas de desenvolvimento, metodologias ou sob diferentes tipos de contratos, e descobrir os motivos pelos quais alguns são melhores que os outros? Existe alguma maneira de determinar por que alguns projetos funcionarem melhor do que outros? Podemos usar métodos padrão e reconhecidos para estabelecer comparações entre nossa empresa e outras em nível nacional, ou entre diferentes setores, ou talvez em todo o mundo?

Para responder corretamente estas questões, seria necessário abordar uma série de aspectos. O primeiro dos quais é que essa informação precisa ser realista e os números registrados devem estar corretos. Muitas vezes, o fato de recompensar (ou mesmo punir) equipes ou pessoas, ou criar rankings e distribuir determinados personagens internamente, pode contribuir com uma espécie de “engenharia dos números”. Uma espécie de “Photoshop de números”, como quando uma fotografia de alguém é tirada e depois é retocada porque a pessoa não gosta dos cabelos ou de outros detalhes. Se os números não são os reais, quaisquer métricas e conclusões derivadas serão erradas e não terão sentido; será apenas uma apresentação ou painel atraente com gráficos, mas com um conteúdo talvez longe da realidade.

Então, depois que a informação foi registrada corretamente, com honestidade e integridade em todos os níveis, um dos desafios é analisar os conceitos de “por que” e “como” ser mais competitivos e criar um melhor produto e / ou serviço ao cliente. Por que esse conjunto de projetos resultou em menores níveis de produtividade do que outros? Como a nossa qualidade se compara internamente ou externamente com os indicadores padrão? Como nossos clientes podem obter o melhor valor agregado de nossa empresa? O que aconteceria se…? Essas perguntas e respostas são fundamentais para melhorar, para atingir níveis mais maduros de estimativa, para medir as melhorias, ROIs e ter scorecards estratégicos nos níveis de CIO.

Denominador comum incorreto: o mundo invertido

É curioso que, muitas vezes, na indústria de software, o tamanho do produto nem sempre é medido, sendo muitas vezes vinculado equivocadamente ao custo ou ao esforço investido no desenvolvimento do projeto. Por exemplo, um projeto de 5000 horas pode criar um produto menor do que outro projeto de 3500 horas, mesmo que haja um critério de qualidade similar para ambos. É por isso que o tamanho do produto deve ser considerado como um dado. Sem entender o tamanho, outras métricas, como por exemplo a qualidade, irá fornecer apenas o número de erros (embora o conceito de erro possa ser um tanto frágil). Se tomarmos o tamanho do produto como o tamanho do projeto (horas, por exemplo), todas as conclusões subsequentes podem estar erradas. Além disso, às vezes, os piores projetos (aqueles que precisam de mais tempo para criar uma determinada funcionalidade com o mesmo nível de qualidade) serão os melhores do ponto de vista da qualidade, porque o esforço será maior. Não é a mesma coisa um projeto de 5000 horas que tenha 25 defeitos, do que um projeto de 3500 horas (ambos tecnicamente são os mesmos, mas o primeiro é menos eficiente) com 25 defeitos. Em parte, é algo como o mundo de cabeça para baixo.

Outras vezes, o tamanho do produto pode ser vinculado, incorretamente, às linhas de código (LOC: Lines Of Code) do mesmo. Alguns podem achar que ter um número maior de linhas de código (mesmo que algumas linhas sejam desnecessárias) faz com que o projeto pareça ser mais produtivo ou mesmo com melhor qualidade. Isso é similar ao caso de confundir o tamanho do produto com o tamanho do projeto, o que beneficia injustamente aqueles que criaram um produto com 700 mil linhas de código e não aqueles que criaram o mesmo produto, com o mesmo nível de qualidade, desempenho e segurança com apenas 300 mil linhas de código. Novamente, 10 defeitos em 700 mil linhas de código (LOC) não é a mesma coisa que ter 10 defeitos em 300 mil. O primeiro projeto pode parecer ser melhor, mas o produto do ponto de vista das funcionalidades para o cliente, será o mesmo. Obviamente, essa mesma lógica pode ser aplicada quando o tamanho estiver associado ao número de programas, ou ao número de processos, número de pessoas envolvidas no projeto, à duração do projeto, etc. É, novamente, o mundo invertido.