Pular para o conteúdo principal

Quem conta um Ponto, Aumenta um Conto

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.

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.
evisconde 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é.

Postagens mais visitadas deste blog

WorkChopp Intacto

Olá pessoal! Sou o @andersonfer_ e tô invadindo o blog do Fabricio pra contar sobre um evento muito legal que organizamos na @IntactoSoftware . Como eu ainda não tenho blog (shame on me), pedi permissão pra falar por aqui! Espero que gostem! Depois do #agileBR , todos nós voltamos naquela vontade de distribuir o conhecimento adquirido lá entre toda galera. Então tivemos a ideia de organizar um workshop baseado em uma dinâmica que eu assisti, apresentada pelo Emilio Gutter e pela Alejandra Alfonso . Eu sempre fui muito favorável às dinâmicas, jogos e afins pq acho que têm um poder muito grande de quebrar as resistências das pessoas e fazê-las enxergar os benefícios das metodologias e técnicas ágeis para além dos contextos e projetos em que estão inseridas e consequentemente tentar aplicar esses conceitos no seu dia-a-dia. Optamos por relizar a dinâmica Construindo A Cidade Ágil. Os 2 grupos tinham à disposição papeis coloridos, tesoura e cola pra construir, em 4 sprints de 3 min

Formando pessoas desenvolvedoras na bxblue

Eu sempre fui apaixonado por ensinar. Trabalho com a formação e ensino desde 2003, indo desde o ensino das bases de computação até lecionar em cursos de pós-graduação. Estar no dia-a-dia com pessoas que estão no começo da carreira é um mix de satisfação e desafio. Satisfação por você ter a oportunidade de contribuir com um pedacinho tão especial da história daquela que será uma pessoa desenvolvedora no futuro. Desafiadora pelo fato de precisarmos nos despir de aprendizados já superados em nossas mentes e nos esforçamos por enxergar novamente pelos olhos de quem ainda não tem a mesma vivência que você. Por onde passei, eu sempre acreditei que um bom equilíbrio entre profissionais experientes e em formação é a melhor combinação para um time de tecnologia. Isso é benéfico não apenas para a retenção, como também é estímulo para uma cultura de aprendizado e humildade. Cultura essa que favorece o compartilhamento e interação não apenas entre quem faz o software, mas também as demais áreas da

Aceleração de Startups - Parte 2 - Como é o ecossistema ?

Continuando a série sobre aceleradoras, onde na primeira parte  eu falei sobre o que é uma. Hoje vou contar um pouco de como é o ecossistema que a rodeia. Vale ressaltar que o tipo de aceleradora descrita seria melhor definida como sendo uma aceleradora de estágio semente ( seed stage accelerator ) e desempenha um papel bem específico nos "degraus" da escalada empreendedora. Uma das formas visuais mais interessantes de desenhar este caminho é a feita pela Techstars para explicar ela participa nos mais diversos estágios do ecossistema. Jornada empreendedora de acordo com a Techstars. Usando esse desenho como base, vou tentar delinear como alguns elementos se encaixam nesse ecossistema. Vale ressaltar que essa não é uma relação exaustiva, novos tipos de intervenções são criadas a todo momento, antigas caem em desuso mostrando sua constante evolução e adpatação. Aprendizado No nível de aprendizado, o foco está em fomentar o empreendedorismo e a ensinar o básico de al