Sempre houve um grande dilema entre a estimativa de prazo e de dinheiro que envolve um projeto de TI, reclamações por ambas as partes cliente/desenvolvedores justificando que tal análise ou estimativa não era exata(bem, uma estimativa já não é exata por definição) também é algo frequente. Porém será que métodos como APF(análise de ponto de função) não podem ajudar quando o assunto é gerar uma estimativa?
Foi com uma indagação parecida que Plínio Marco Canto começou uma discussão no fórum de arquitetura Tectura, ele perguntou:
Certo dia um diretor, muito sagaz exclama a seguinte frase;
“Agora já sei como justificar os prazos de nossos projetos!!! ANALISE DE PONTO DE FUNÇÃO!”Entendendo a pressão que ele deva sofrer para justificar o investimento na área de TI e tendo que fugir obrigatoriamente do chutômetro, “acho que levarei 312 jornadas para fazer isso…” ¬¬
Será que a Analise de Ponto de Função realmente ajudaria nesse caso? Alguém já aplicou essa teoria na pratica? Existem outras formas de se assegurar o tempo estimado para um projeto?
Com certeza muitos desenvolvedores já passaram por situação semelhante, entretanto a utilidade de se estimar utilizando APF é um tanto quanto questionável como afirma Breno Martins:
Desenvolvimento de sistemas, ao menos no meu ponto de vista, é algo empírico e pronto! Não acredito numa correta mensuração em um processo empírico e não acho necessário.
Rubem Azenha afirma que esse tipo de análise serve apenas para você ter um pouco mais de "gordura" e que detalhes de implementação contribuem para que sua estimativa ganhe números cada vez mais dispersos da realidade:
[...] APF serve pra jogar o custo do projeto na estratosfera pra de dar uma boa “gordura”. Uma mesma funcionalidade pode ser uma tela simples com alguns campos ou uma tela monstruosa, com drag’n’drop, ajax, validação no cliente, etc. Por isso é impossível fazer uma correlação entre funcionalidade => numeros de pontos de função => horas necessárias para desenvolver a funcionalidade sem detalhar a funcionalidade…
APF só serve para você dar a impressão pro seu cliente que você esta usando algum método cientifico para estimar o “esforço” do seu projeto (não me venha com essa que esforço != custo != prazo… no fim a estimativa vai de esforço vai virar custo e prazo, principalmente por que quem acredita em APF acredita que 9 mulheres fazem 1 filho em 1 mes…).
Você pode ser honesto com o seu cliente e dizer que não tem como estimar o projeto se ele for muito grande. Ou você pode tentar enganar ele (e a si mesmo) com APF.
Guilherme Silveira concorda com Rubem Azenha e diz que uma melhor "estimativa" seria analisar a velocidade do seu time que, muitas vezes, pode oferecer dados mais realísticos:
Como o Rubem citou, uma estmativa é uma estimativa. Como ela não é baseada em experiências anteriores (não se analisa os erros de estimativa da mesma equipe no projeto anterior para acertar nessa), os mesmos erros se repetem a cada nova estimativa de projeto. As mesmas falhas surgem, o mesmo atraso, a mesma reclamação.
Por isso que a velocidade, que diz algo de acordo com os erros e acertos da equipe atual, é mais realista.
O fato é que grandes empresas e orgãos do governo precisam de um projeto de escopo fechado e, para que isso aconteça, precisamos oferecer prazo e custo para os mesmos. Se esses cliente fossem flexíveis ao p0nto de aceitarem projetos de escopo aberto, talvez os dois lados sairiam ganhando, entretanto sabemos que isso é quase impossível. Dado esse cenário e sabendo que, hoje em dia, todos os métodos de estimativa que conhecemos são um tanto quando inexatos e trabalhosos, então como oferecer para nossos clientes tal prazo e custo?
E você leitor, qual dica daria para aqueles que precisam estimar o seu projeto? Você concorda que a estimativa é algo falho e serve apenas para oferecer números, mesmo que não exatos para os clientes?