Contratar o Desenvolvimento com Base em Métricas

Este artigo procura mostrar que a contratação do desenvolvimento de sistemas com a utilização de pontos de função (ou outra métrica) não pode ser realizada exclusivamente com base em dados de terceiros, ainda que publicados em fontes internacionais respeitáveis. Antes da contratação, é imprescindível a implantação de um programa de métricas que permita ao cliente estabilizar o seu processo de desenvolvimento e conhecer a sua própria produtividade. Com base neste conhecimento, poderão ser procuradas melhorias e obtidas junto do mercado. Uma grande ajuda pode ser conseguida através da troca de experiências com empresas semelhantes, tanto para contratantes, quanto para contratados. As melhores práticas de contratação só podem ser conseguidas com o concurso de ambas as partes, num clima do tipo "ganha-ganha".

Uma forma muito popular de contratação de serviços de desenvolvimento de sistemas é denominada nos Estados Unidos por body shop (loja de corpos). Em português tem-se utilizado a expressão locação de mão-de-obra. Nas operações de tipo body shop, a empresa fornecedora aloca um profissional a uma empresa cliente, cobrando por isso um valor mensal. Esta é uma operação com um risco muito baixo para o locador, pois no caso do profissional alocado não satisfazer o pretendido do cliente, o que se faz é simplesmente substituí-lo. O risco dos projetos não é compartilhado pelo locador de mão-de-obra, que não precisa de participar no pesadelo que costuma ser a gestão dos projectos de tecnologias de informação (TI).

Evidentemente, há soluções intermédias, nas quais o fornecedor divide a gestão dos resultados com o cliente. No entanto, estas soluções não podem ser consideradas estritamente como body shop. No body shop propriamente dito, não existe o comprometimento do fornecedor de mão de obra com os resultados. Por essa razão, é natural que as empresas procurem soluções alternativas para a contratação do desenvolvimento de sistemas.

Desde há alguns anos a esta parte, algumas grandes empresas resolveram enveredar pela contratação do desenvolvimento de sistemas baseado em métricas de software. Nessas contratações, o objecto produzido através do contrato - programa, sistema, documento, etc. - é quantificado e pago através de alguma medida objectiva, realizada com base no próprio objecto gerado. Teoricamente, esta é uma solução ideal, pois o que é pago é o resultado, ao invés dos recursos utilizados na sua geração. O problema desta abordagem passa a ser a escolha, a medição e a interpretação da métrica a ser utilizada na quantificação dos serviços contratados.

No caso do desenvolvimento de sistemas, o principal item que se procura medir é o software produzido através do respectivo contrato. Há contratos específicos para o desenvolvimento de um único sistema, bem como outros destinados ao desenvolvimento e manutenção de diversos sistemas, programas e outros artefactos. Este último tipo de contrato é por vezes denominado "guarda-chuva", por abrigar uma grande variedade de serviços.

As métricas mais utilizadas para a medição de software, tanto no mundo académico, como na indústria, são as linhas de código e os pontos de função. As linhas de código possuem a grande vantagem da medição automática, através de programas de computador. Tal não é possível com os pontos de função, embora algumas ferramentas tentem realizar essa tarefa, com graus variáveis de sucesso.

Por outro lado, é difícil estimar linhas de código no início de um projecto, quando ainda não se tem definida a arquitectura. Além disso, a quantidade de linhas de código varia com a linguagem utilizada e, o que é pior, com o próprio estilo de programação da equipa. Estas dificuldades têm contribuído para a crescente disseminação dos pontos de função, regulamentados e periodicamente actualizados pelo International Function Point Users Group (IFPUG), uma organização sem fins lucrativos com sede nos Estados Unidos.

Os pontos de função permitem medir a funcionalidade de um sistema independentemente da técnica utilizada na sua implementação. Desta forma, os pontos de função são independentes da linguagem de programação e da plataforma utilizada. Funcionam como a medida de um imóvel em metros quadrados: um apartamento de 100 metros quadrados terá os mesmos 100 metros quadrados, independentemente do local onde se encontre, numa zona mais barata ou mais cara, com materiais de primeira ou com materiais mais baratos, mobilado ou vazio.

De igual modo, um sistema com 500 pontos de função terá esse mesmo tamanho, seja ele implementado através de COBOL/CICS e DB2 em mainframe, em Delphi com Oracle em uma arquitetura de três camadas, ou como uma aplicação Web utilizando Java, Solaris e Sybase.

Ao medir uma aplicação utilizando pontos de função, os elementos considerados são componentes visíveis e reconhecidos pelo utilizador, tais como arquivos lógicos, transações de entrada e de saída, e consultas efectuadas. A visão lógica e centrada no ponto de vista do utilizador garante a independência relativamente à implementação.

Na contagem de pontos de função, é necessário exercitar o processo de abstracção utilizado para identificar os componentes contáveis no modelo do sistema, conforme descrito pelo utilizador ou registado na documentação existente. Uma vez determinado o tamanho funcional do sistema, o próximo passo é dispor de um método para obter o custo do serviço de desenvolvimento a partir do tamanho em pontos de função.

Uma saída simples, mas não recomendável, é estabelecer um custo fixo para cada ponto de função gerado, isto é, um preço por ponto de função. Acontece que o custo de um ponto de função vai variar segundo diversos factores, dificultando o estabelecimento de um preço único por ponto de função. Na nossa analogia anterior, o ponto de função equivaleria ao metro quadrado, enquanto que o preço por ponto de função equivaleria ao preço por metro quadrado.

Torna-se fácil perceber que não é possível estabelecer um único preço por metro quadrado para todos os tipos de imóveis, independentemente da localização e do acabamento utilizado. Do mesmo modo, não podemos ter um único preço por ponto de função para todos os sistemas, independentemente da plataforma, linguagem, etc. Estes são factores que irão afectar a produtividade da equipa de desenvolvedores.

O esforço despendido num serviço de desenvolvimento é o número de horas gasto para realizá-lo, o qual pode ser dado por E = F x T, onde E é o esforço em horas, F o tamanho em pontos de função e T a taxa de entrega em horas gastas por ponto de função. A taxa de entrega é o inverso da produtividade. Conhecido o número de horas E, o custo pode ser obtido multiplicando-se E pelo valor unitário da hora: C = E x H, onde C é o custo do serviço, E é o esforço e H é o valor unitário da hora.

Vemos então que, além do tamanho do sistema em pontos de função, precisamos de conhecer a taxa de entrega e o valor unitário da hora para que possamos ter o custo. O tamanho em pontos de função pode ser determinado por um contador de pontos de função experiente. O valor da hora é conhecido do mercado, mesmo porque já é intensamente utilizado nos contratos do tipo body shop. Resta conhecer a taxa de entrega, que reflecte a produtividade. No entanto, talvez sejam poucas as empresas que conhecem bastante bem a sua própria produtividade.

Não há estatísticas conhecidas para a taxa de entrega (horas por ponto de função) ou para a produtividade (pontos de função por pessoa por mês) das empresas portuguesas que produzem aplicações orientadas para o negócio. Poucas empresas mantêm algum tipo de programa de métricas e, quando o fazem, nem todas utilizam uma medida padrão que permita comparações com outras empresas, que é o principal benefício na utilização dos pontos de função.

Neste contexto, torna-se necessário o estabelecimento de programas de métricas que permitam aos clientes e fornecedores conhecerem a sua própria produtividade. Mas porque razão uma empresa cliente quereria conhecer sua própria produtividade? Não bastaria conhecer a produtividade das melhores empresas do mundo e exigir esse mesmo nível dos fornecedores? Talvez sim, no caso da aquisição de uma mercadoria, ou de um serviço totalmente independente do ambiente do cliente. Mas não é esse o caso.

No desenvolvimento de sistemas, as demoras, as dificuldades e as indefinições dos utilizadores poderão afectar fortemente a fase de concepção ou análise. Os processos internos e as tecnologia utilizadas pela área de TI do cliente poderão, por sua vez, ter um grande impacto na fase de elaboração ou projecto. Os procedimentos de aceitação e a forma adoptada para a gestão das mudanças de alvo também direccionarão os riscos da fase de construção ou programação. Finalmente, a localização geográfica e o cronograma dos utilizadores irão determinar o tempo para a transição ou implantação do sistema.

Para que uma empresa possa exigir, realisticamente, uma determinada produtividade de um fornecedor, é preciso que ela tome como ponto de partida a sua própria produtividade, procurando melhorias sucessivas ao longo da parceria resultante da contratação. O conhecimento da própria produtividade é, neste caso, o principal objectivo do programa de métricas a ser implantado.

É muito comum as pessoas procurarem números de terceiros, que possam substituir as medições acima indicadas. As perguntas mais comuns são do tipo: "em quantas horas se faz um ponto de função num ambiente cliente/servidor, utilizando VB com SQL Server?", ou "quantos pontos de função faz um programador COBOL por mês?". É claro que tais números existem nas estatísticas internacionais. O problema é saber se os mesmos números se aplicam ao seu caso? Há uma grande probabilidade de que não.

A variabilidade do processo de desenvolvimento de sistemas é muito grande. Diferentes empresas vão utilizar diferentes metodologias. Muitas empresas não utilizam qualquer metodologia de forma consistente, embora quase todas disponham de alguma. Quando uma metodologia padrão é utilizada, os projectos, por sua vez, são diferentes entre si. Mesmo quando os projectos são comparáveis, muitas vezes as equipas não o são.

Resumindo, o fenómeno que se deseja estudar - o desenvolvimento de sistemas - é tão variável que desafia a definição. Se, ainda assim, aceitarmos que todos os que escrevem sobre desenvolvimento de sistemas estão a tratar da mesma coisa, teremos que considerar a questão das medições. Para obter a produtividade, precisamos de medir o tamanho e o esforço despendido.

A medida dos pontos de função pode ser razoavelmente precisa, se forem utilizados contadores experientes. Por outro lado, os critérios para registo do tempo despendido podem variar bastante. Se não houver um padrão para isso, não teremos como saber quem e o quê foi medido. Por exemplo, foi medido o tempo gasto pelos administradores de dados neste projecto? Foi considerado o tempo do pessoal de suporte? O projecto foi medido desde a primeira reunião realizada para tratar do mesmo? O anteprojecto foi considerado nas medições? A formação dos utilizadores foi incluída? Após a aceitação final do utilizador, ainda houve alguma actividade registrada? Deveria ter havido?

É mais importante ter um único critério consistente do que ficar a discutir se determinado tipo de actividade deve ou não entrar no cômputo das horas despendidas no projecto. Como consequência da grande variabilidade do fenómeno e das respectivas estratégias de medida diferenciadas, as estatísticas internacionais sobre produtividade também variam muito. Isto pode ser verificado através da comparação entre os dados provenientes de três respeitadas fontes de dados sobre as actividades de TI: o International Software Benchmarking Standards Group (ISBSG), Capers Jones e Howard Rubin.

Comparando a produtividade do desenvolvimento, medida em pontos de função por pessoa por mês, veremos que o banco de dados do ISBSG registra cerca de 19 PF, Capers Jones indica 7,5 PF e Howard Rubin chega a 3,6 PF. Isto significa uma variação de quase duas vezes entre Rubin e Jones, e de quase cinco vezes entre Rubin e o ISBSG. Qual destes é o caso da sua empresa? Ou será algum outro? Os dados citados são de 1998.

É inevitável a decepção daqueles que esperam do processo de mensuração de software alguma fórmula mágica ou revelação mística. Exactamente como quando tratamos de metodologias de desenvolvimento, ferramentas CASE ou técnicas de modelação, não há uma solução brilhante que resolva todos os problemas. Como dizem os americanos, "there is no silver bullet". A contratação de software com a utilização de métricas passa primeiro pela implantação de um programa de mensuração, também designado por programa de métricas. As estatísticas internacionais são úteis como ajuda para a validação das nossas próprias métricas e para o posicionamento do nosso processo em relação às demais organizações.

A implantação de um programa de métricas requer um esforço específico da organização. O projecto pode ser efectuado em oito passos, resumidamente descritos a seguir:

1. Documentar o processo de desenvolvimento actualmente utilizado e padronizá-lo (sem tentar a realização de melhorias, mas tão somente a estabilização do processo);
2. Estabelecer os objectivos do programa de métricas (no nosso caso, determinar a produtividade);
3. Definir as métricas necessárias para o alcance dos objectivos pretendidos (por exemplo, tamanho funcional em pontos de função, esforço em horas, qualidade em densidade de erros, etc.);
4. Identificar os dados a serem colectados (por exemplo, horas trabalhadas de cada técnico envolvido, tamanho funcional de cada uma das solicitações de alteração do sistema, erros identificados e suas categorias, etc.);
5. Definir o processo de colecta de dados (identificar os pontos de colecta, periodicidades, formulários ou sistema de colecta, etc.);
6. Obter ferramentas (construir e/ou adquirir as ferramentas que permitam implementar o processo de colecta anteriormente definido); 
7. Criar um banco de dados de métricas (implementar um repositório que possa abrigar, de forma organizada e acessível, todos os dados que virão a ser colectados);
8. Definir um mecanismo de feedback (uma maneira que permita à equipe de métricas receber feedback de todos os participantes do processo).

Existem várias outras formas de se conduzir o processo de implantação de um programa deste tipo. O importante é o comprometimento da gestão e a clara definição dos objectivos do programa, de modo a garantir que as métricas geradas sejam aquelas necessárias e efectivamente utilizadas.

Uma vez implantado o programa de métricas, a organização começará a obter dados de produtividade. Numa organização imatura, ainda no nível um da classificação CMM, é provável que a produtividade varie de forma errática - reflectindo, é claro, o fenómeno que está a ser medido. Gradativamente, será possível separar os projectos por plataforma, ramo de negócio, localização geográfica, perfil da equipa e outros factores que estejam a influenciar os resultados. O tratamento de categorias separadas tenderá a reduzir a variabilidade.

Após a estabilização dos factores mais influentes, será possível estabelecer uma produtividade média para cada categoria definida. Este será o ponto de partida para a obtenção de melhorias junto dos fornecedores. Por exemplo, uma empresa poderia firmar um contrato com um fornecedor, tendo como alvo um aumento de produtividade de 25 por cento no primeiro ano e de 10 por cento no segundo (este é apenas um exemplo; os valores reais só podem ser determinados mediante cuidadosa análise por parte do cliente e do fornecedor).

Baseado no artigo "Contratando o Desenvolvimento com Base em Métricas", de Maurício Aguiar.

Produzido em 2005