Pare de fazer isso!
Hoje recebi uma mensagem através do LinkedIn de um rapaz que não conheço, perguntando algumas questões relacionadas a esforço, produtividade e custo utilizando Análise de Pontos de Função (APF). Quem é da área sabe que este assunto é SUPER recorrente e super controverso. Algumas (muitas) pessoas tendem a não se aprofundar no tema e querer apenas respostas rápidas (não estou dizendo que é o caso do colega que me enviou a mensagem). Infelizmente não existe resposta curta e rápida para isto. Se não quiser resposta superficial, recomendo ler e se aprofundar. E cuidado, pois tem muita gente dando resposta superficial por aí (e perdendo milhões por isso, já vi e calculei de perto).
Aproveito para compartilhar o e-mail que enviei como resposta (com algumas alterações e ênfases, rs) para quem mais se interessar:
Diversos fatores podem impactar o esforço para se desenvolver 1 PF (e consequentemente a produtividade e o custo).
Citando alguns: Metodologia de desenvolvimento (ágil? tradicional?), existência/qualidade/complexidade/estrutura/tamanho da documentação, experiência da equipe, conhecimento do negócio pela equipe de dsv, maturidade da organização e da equipe de dsv, reuso de software, ambiente físico, linguagem de desenvolvimento, utilização de frameworks, uso de componentes, tamanho não-funcional do sistema, etc, etc, etc, etc, etc, etc, ETC!!!!!!!!!!…)
Em relação ao último item citado, lembre-se que APF mede apenas o tamanho funcional do sistema. Os requisitos de qualidade e os requisitos técnicos (conforme ISO/IEC 14143-1) não estão contemplados no tamanho em pontos de função. Leve isto em consideração, pois você pode se deparar com sistemas/manutenções com grande tamanho funcional e pequeno esforço técnico ou sistemas/manutenções com pequeno (ou nenhum) tamanho funcional e grande esforço técnico.
O ideal é utilizar uma metodologia que considere, não só o tamanho funcional medido em APF, mas também os demais requisitos de qualidade e técnicos (pesquise por “COCOMO”) (ou daqui a alguns meses pesquise por “SNAP – Software Non-functional Assessment Process”, que está atualmente em fase de beta-test pelo IFPUG).
A título de referência, neste site você encontrará diversos preços cobrados para o desenvolvimento de 1 PF em contratos públicos:
http://www.fattocs.com.br/editais.asp
Repare que a faixa de valores varia bastante e tem alguns pontos fora da curva. Eu julgo que atualmente, para médias e grandes organizações, um valor razoável está entre R$ 400/PF e R$ 700/PF, dependendo do cenário.
Para produtividade, você também encontrará uma faixa bem grande de valores no mercado, variando de 3hs/PF a até 25hs/PF. Novamente, a título de referência dê uma olhada neste site: http://www.blogcmmi.com.br/engenharia/produtividade-das-linguagens-em-pontos-por-funcao-apf.
O MAIS IMPORTANTE: Se estiver começando a utilizar APF em sua organização, passe a registrar o quanto antes os dados de esforço, produtividade, tamanho funcional, tamanho não-funcional, custo, para cada demanda, começando a formar assim a SUA PRÓPRIA base histórica. Ela é a melhor fonte para tomada de decisão futura. Melhor do que qualquer site ou valor de outras organizações que você encontrar.
Abraços e boa sorte!
PS: Análise de Pontos de Função não é esse demônio todo como algumas pessoas insistem em dizer… E nem é essa cocada toda como outras pessoas insistem em idolatrar… Um dia tento me inspirar para falar mais sobre o meu posicionamento em relação a APF, em quais cenários acho que ela serve bem e em quais cenários NÃO recomendo sua utilização ;-)
Bruno Torquato 
25 abril, 2011 at 12:25 pm
Oi Bruno, quanto tempo! Tudo bem?
Parabéns pelo artigo e pelo equilíbrio. Temas assim costumam puxar as pessoas para um lado ou para o outro. Aguardarei pelo ‘complemento’.
Antes, queria sua opinião sobre aquela variação toda de preços e, principalmente, do esforço necessário por PF. Você teria algumas suspeitas? Desde já agradeço.
Abraços!
Paulo Vasconcellos
25 abril, 2011 at 4:34 pm
Oi Paulo, tudo bem e você?
Em relação aos preços é mais fácil, principalmente em se tratando de contratos públicos onde venho atuando recentemente. O pregão eletrônico na modalidade “menor preço” se popularizou como forma de contratação de serviços de desenvolvimento de sistemas. Estão caracterizando dsv de software como “bens e serviços comuns” ou seja, “aqueles cujos padrões de desempenho e qualidade possam ser objetivamente definidos pelo edital, por meio de especificações usuais no mercado”. Estão querendo comprar software como se compra copo descartável.
A modalidade “técnica e preço” vêm deixando de ser utilizada. Isto facilita a guerra dos preços, ajuda na entrada de ‘empresinhas’ que não tem condições de executar um bom serviço e jogam o preço lá em baixo e aumenta a taxa de suicídio das ‘maiores’ (que fazem de tudo pra ganhar uma licitação, e depois fazem de tudo pra tentar se manter vivas no contrato).
Outra questão é que MUITOS editais estão considerando apenas APF na formação do preço. Isto é perigoso. É o mesmo que concordar com “Vamos assinar um contrato, mas eu pagarei apenas pelos requisitos funcionais que você me entregar, ok? Os de qualidade e os técnicos não”. Mais uma vez a “Continuous attention to technical excellence and good design” está sendo declarada como sem valor. Mais uma porta de entrada para extreme-go-horses que fazem variar tanto o preço.
Quanto ao esforço, os cenários de dsv de sistemas que encontramos por aí são diversos. São muitas linguagens, muitas metodologias, níveis de maturidade diferentes… Temos Dream-teams e meras equipes. E muitos outros fatores… Não acredito que dê para se falar em produtividade genérica tendo cenários tão distintos. Acredito que o melhor é uma organização entender o seu próprio cenário e tirar seus próprios números. Analisar os números de suas próprias equipes, onde ela é dona da informação. E evitar comparar aleatoriamente com outras organizações onde não se tem a menor ideia de como o dsv de sw é feito por lá.
Independente de APF, se apresentarmos uma mesma demanda a diversas organizações, acho que também teremos uma faixa bem variável de tempo de desenvolvimento.
Valeu pela leitura e pelo comentário.
Abraços,
Bruno