A priorização da busca pela eficiência é uma preocupação dos tempos de paz. Os efeitos das novas tecnologias na transformação digital promove comportamentos de vida ou morte; o seu negócio, como você conhece, pode simplesmente deixar de existir. Esse tipo de comportamento é típico de tempo de guerra.
Há uns 30 anos tenho trabalhado com a medição da produção de software, em especial de unidades de produto por meio de pontos de função e, mais recentemente também com o SNAP. Normalmente, fazendo isso com o propósito de relacionar os resultados dessa medição com o esforço ou custo. O resultado disso permite planejar, prescrever ou avaliar o desempenho na dimensão da eficiência, mesmo quando ainda não se sabem os detalhes do design ou implementação do produto.
São aplicações, que vão desde a estruturação de um portfólio de projetos para períodos que vão de um a cinco anos até a auditoria nas entregas de fábricas de software no contexto de contratos corporativos públicos e privados. Se pararmos para pensar, percebemos que todas essas ações estão vinculadas à dimensão da eficiência nos resultados em sua essência. Elas estão vinculadas a potencializar o menor uso de recursos na produção do máximo de resultados; ou melhor, unidades de produto. Faço essa correção, porque haver muito software não implica em haver proporcionalmente um impacto nos resultados, que é a dimensão da efetividade na gestão do desempenho.
O que verificamos ao longo dos últimos 20 anos foi o sacrifício da efetividade – a do impacto nos resultados – em função da busca pela eficiência operacional. Um dos motivos para isso é a dificuldade em se medir a contribuição das partes avaliadas individualmente na dimensão que mede o impacto nos resultados. Nessa busca pela eficiência operacional – e também pela alienação dos desenvolvedores de forma que a administração se tornasse deles mais independente – processos de fábrica foram introduzidos em uma produção de software, que compartilha muito mais fatores com o artesanato do que com a engenharia. O resultado é a demora de até um ano para modificar o nome de um rótulo em um botão.
Em tempos de guerra, é possível ter esse tempo de espera? Quanto vale “desperdiçar” para se obter isso mais rápido? A minha percepção sobre o estado das coisas hoje em dia é de que haja um refluxo, se comparado ao fluxo nos últimos 20 anos, da importância de processos, métricas e indicadores. As métricas passam a ser empíricas e subjetivas de forma que seja impossível auditar. Como alguém do negócio audita um story point? O próprio termo história de usuário varia de canto para canto desde um épico, descrevendo todo um fluxo operacional, até uma atividade de projeto tratada, equivocadamente, como um requisito do produto. E ninguém se preocupa com isso… desde que funcione. Muitas vezes, nem mesmo se esse objetivo “funcione” custe muito mais, que poderia custar.
Meu propósito não é discutir méritos ou deméritos nessa minha percepção de como as organizações têm se comportado diante da transformação digital. O meu propósito é definir um contexto para compartilhar a visão de como a medição padrão ISO, como as métricas do IFPUG ou do COSMIC, podem contribuir.
Em uma ótica lean, tudo o que não estiver agregando valor ao produto ou serviço deve ser retirado do processo. Fazendo para alguns executivos a pergunta sobre onde eles estariam dispostos a pagar até 1% do custo atual do desenvolvimento para obter um melhor resultado, 100% deles me respondeu: PRAZO.
Nessa mesma linha de minimizar e idealmente eliminar o que não agrega valor ao produto ou serviço, percebo o desperdício de muito tempo na resolução de divergências de medição em minúcias. Se passarmos a considerar o processo elementar como unidade; diminui-se o custo de medição em menos da metade e os resultados são – ainda assim – muito melhores e comparáveis do que outras unidades como quantidade de histórias de usuário ou story points.
Por fim, o uso das métricas funcionais não deveriam ser usados na granularidade de um sprint ; usando a terminologia do SCRUM para um ciclo curto de desenvolvimento de entre duas e quatro semanas. Confesso, que nesse nível de granularidade, não vejo a menor necessidade de uma unidade de produto, seja ela qual for. Se o desenvolvedor não consegue estimar de maneira direta um trabalho pontual de até uma semana, então há um problema de gestão, cuja solução não são as métricas de software.
A minha recomendação é que a medição de unidades de produto seja no nível de uma nova release do produto. Antigamente, eu também citava a granularidade do projeto; mas vejo hoje, que no contexto descrito, o paradigma do projeto deveria ser abandonado e, em seu lugar, adotada a lógica de um produto vivo, que evolui contínua e organicamente ao longo do tempo e conforme há ciclos de experimentação, feedback e aprendizado pela comunidade usuária.
Voltando a questão do valor; o que se mede, se promove. Considerando, que o prazo seja a dimensão de maior valor, nada melhor que relacionar a quantidade de processos elementares com o prazo da release. A quantidade de processos elementares pode ser usada diretamente, ou utilizar um fator de comparação com pontos de função para fins de alavancar a comparabilidade dos resultados, por exemplo, cada 01 processo elementar equivale em média a 06 PF. O prazo da release pode ser expresso em dias corridos, porque é mais fácil de obter. A métrica resultante cumpre o papel de um cycle time no nível de uma release, passível de planejamento e monitoramento por elementos externos do time de desenvolvimento.
Se você tem problemas com a gestão do desempenho no cenário que descrevemos, a FATTO tem soluções criativas para ajudá-lo a definir a solução e operar as atividades necessárias para que a mesma seja implementada.
Autor: Carlos Eduardo Vazquez
