Quem conta um Ponto, Aumenta um Conto

  • 2
Bem, hoje o assunto é ponto de função, e como tem se tornado nos poucos post, começarei com uma historinha minha dentro da área.

Eu estudo ponto de função a 2 anos. Do início dos meus estudos em PF até começarmos a utilizar esta técnica na empresa foram 2 meses. Antes do ponto de função, nossa estimativa era bastante empírica, utilizávamos nossa experiência e estimávamos no "olhômetro" cada funcionalidade ou caso de uso do sistema. Nem preciso dizer que em 2 anos, após começar a utilizar o PF já temos uma pequena base histórica da nossa produtividade, nossas taxas de erros de previsão e diversos fatores que influenciam em nossos projetos. O que vale ressaltar aqui é que com as informações desta base de dados, juntamente com a experiência adquirida, hoje nos é possível prever e orçar com muito mais certeza um projeto.

Mas não foi pra ficar falando dos benefícios da APF que eu vim discutir hoje, meu ponto hoje é o papel e o uso da APF no mercado hoje em dia. Desde que iniciei os meus estudos neste assunto, uma metáfora sempre ficou na minha cabeça e sempre a tomei como a melhor forma de explicar "o que é ponto de função", a metáfora da casa e o metro quadrado: "O Ponto de Função é o metro quadrado do software. Posso lhe dizer que existe uma casa de 200 m² e isso lhe dará uma boa noção do tamanho desta casa, porém isto não lhe dará informações sobre custo ou esforço desprendido na construção desta casa, afinal ela pode ter piso de mármore e torneiras folheadas a ouro ou ser feita de materiais mais comuns, ela pode ter sido construída em um bairro de classe média próximo ao centro da cidade ou no alto de um penhasco." (Coloquei entre aspas pois não me lembro onde ouvi esta história, nem achei a fonte)
Coloquei em destaque o que mais me marcou desta história, é que o ponto de função não lhe determina o esforço, nem o custo do seu projeto.

Bem, fazendo uma pequena pausa, vamos ao que me inspirou a este post. Na minha empresa, hoje temos uma noção de quanto temos capacidade de desenvolver, temos inclusive alguns números que envolvem nossa produtividade em PF. Na semana anterior nos veio um cliente e durante nossa reunião questionou quanto nossa fábrica era capaz de produzir em PF/mês, e prontamente informamos os dados que temos. Neste ponto o cliente nos perguntou quanto tempo demoraríamos para absorver uma demanda maior, informávamos que dependia do tamanho da demanda e de como planejaríamos este aumento. Bem o cliente gostou dos números, saiu satisfeito e espero que tenhamos um bom negócio. Porém ao sair da reunião algo me incomodava, e fiquei meditando no assunto. O que me incomodou foi o fato de termos tratado PF como uma unidade "padrão", como se minha fábrica de software produzisse "balinhas" e eu dissesse que produzo X balinhas por mês e se você quer uma produção de 3X basta eu comprar mais maquinário. Meu problema é que eu não produzo "balinha", o problema que eu enxerguei (e que me causou desconforto) foi que tratamos PF como "balinhas", desconsiderando o fato que o custo de 1 PF é bastante distinto de um sistema para outro.

É importante ressaltar esta questão, pois isto nos volta ao que serve o PF (nosso m²). Pois imagine você que alguém lhe diga que tem um sistema de 2000PF para ser desenvolvido, lhe pede um prazo e custo sem mais informações. É impossível determinar, afinal podemos ter um imenso sistema CRUD, ou mesmo termos um sistema de simulação aeroespacial, que terão esforços por PF bastante distintos. Eu compreendo que nós, que cuidamos de muitas equipes, precisamos de alguns números para nos auxiliar em planejamento e a acompanhar o andamento dos projetos. Minha crítica aqui vem de utilizarmos estes números sem critérios, afinal falarmos em produtividade sem noção do negócio do cliente é, no mínimo, voltarmos a técnica do "chutômetro", agora porém, com números.

2 comentários:

Ricardo Lovatel disse...

Prezado Fabricio
Achei teu convite para comentar este post.
A exemplo de Jack, vamos por partes. Concordo contigo que encontramos no mercado uma generalização perigosa sobre o valor de um "ponto de função". Gostaria de lembrar que a técnica, regulamentada pelo IFPUG, não se refere em momento algum a valores financeiros. Por si só, este fato, compromete o uso da Análise de Ponto de Função para, isoladamente, valorar sistemas. É necessário o uso de outras técnicas. O segundo fato, ajudado pelo teu exemplo, é distinguirmos o custo de um produto do seu preço. O exemplo que você cita é da casa no penhasco. Se o usuário quer a casa no penhasco, vai assumir pagar um preço superior à casa no plano. Quanto ao custo, a analogia é similar. Se um fornecedor "sabe" saber por um custo menor, ele pode decidir em baixar o preço ou auferir lucro maior, ou os dois.
Vejo também uma confusão entre estimativa em ponto de função e preço fechado. Explico: tem sido prática no mercado a contratação de equipes de desenvolvimento cuja remuneração é em horas trabalhadas. Neste caso, o ônus tem sido do contratante, em caso de falhas, pois irá pagar e não terá seu produto, ou pagará mais que o previsto, em prazo maior. Em contra-ponto, ponto de função tem sido usado para estimar o tamanho inicial de um sistema, ocorrendo um "congelamento" do valor de remuneração.
Finalmente, observo que Análise de Pontos de Função mede o tamanho funcional de um sistema, ou seja, várias atividades de suporte à aplicação são "embutidas", nos levando a termos um "descolamento" da estimativa inicial de custos sem que ocorra mudança nos pontos de função.
Acredito que APF seja uma excelente ferramenta de estimativa, que corretamente completada nos permite errar menos.

Eduardo disse...

Caro Fabricio,

Vi seu convite no forum do bfpug e acho que posso contribuir de alguma forma com o seu post.
Bem, há muitos pontos mais que comentar, mas vou me ater a questão da produtividade.
De fato, uma equipe tem produtividade diferente por ponto de função conforme o tipo de aplicação que está sendo desenvolvido. Isso é fato. Um Sistema de automação de escritório com 500 PFs não pode ser feito com a mesma produtividade que uma aplicação científica ou ainda uma DW com os mesmos 500 PFs. O que é razoável é se medir a produtividade de sua equipe conforme o tipo de aplicação que está sendo desenvolvido. Mais ainda, deve ser considerada produtividade diferente conforme a tecnologia a ser utilizada, posto que desenvolver um sistema em ASP, .NET ou Java não é a mesma coisa.
De modo análogo, o preço do PF pode e deve estar classificado de acordo esta gama de variações citadas, tanto de tipo de aplicação, quanto de tecnologias.

Espero ter contribuído de alguma forma.

Sds,

Eduardo Avila, CFPS
Petrobras - Macaé.