Recentemente, andei pensando na questão das subestimativas de esforço com relação aos desenvolvimentos de software. Mesmo sem nenhuma estatística é fácil dizer que a grande maioria das estimativas de esforço e tempo para desenvolvimento e implantação de softwares são menores que os reais.
Percebi nos meus tempos coordenando que os mais “novos” (de experiência) subestimam mais que os mais “velhos”.
Filosofando um pouco, acabei chegando a 2 conclusões.
Pessoas não “contam” a parte ruim
Não sou psicólogo, mas acredito que as pessoas no momento inicial da estimativa, apenas “lembram” das partes prazerosas do seu trabalho, as partes penosas são subtraídas deste pensamento, isso faz com que ele vê menos esforço com relação ao real. Acredito que os mais experientes acabam lembrando do não prazero por terem “apanhado” muito no passado.
Uma forma de evitar este equivoco seria criar um diário de bordo com anotações com todas as tarefas exercidas pelo profissional. Quando for estimar uma nova atividade, este ”olharia o passado” para verificar quais são as atividades (tanto as prazerosas, quanto as não prazerosas).
Estimativas de valor alto são penalizadas
Pelo menos em empresas de desenvolvimento pequenas, sempre que alguém estima um prazo grande para uma atividade, levanta-se a discução, as vezes em vários níveis da empresa, se aquela informação esta correta. Já escutei um vendedor questionando que com aquele esforço ele não conseguiria vender (dado que o valor cobrado do cliente era proporcional ao esforço passado). Para o desenvolvedor, que só quer desenvolver, estes questionamentos funcionam como uma espécie de castigo e quando ele subestima, ninguém reclama.
É comum vermos reclamações quanto a não entrega em data pré combinada a reclamações quanto a subestimativa. Tem a ver com a memória curta das pessoas. Acredito que neste caso o desenvolvedor não sinta culpado pela subestimativa e portanto o fato de não ver problema nela. Os mais experientes acabam aprendendo a dura lição e acabam criando opniões fortes que combatam os questionamentos, o efeito colateral é que estes acabam tornando-se intransigentes.
Quanto esta segunda conclusão, acredito que para resolver deveriamos repensar as broncas, a estimativa deve ser comparada com o realizado, e apenas neste caso um desvio deve ser questionado (tanto para cima quanto para baixo). O questinamento prévio deveria ser evitado a todo custo.
E você o que pensa disso?
De sua opnião nos comentários, me diga porque acha que exista a subestimava e como devemos tratar para resolver.
“Estimativas” sempre foi um ponto sensível, não só pra area de desenvolvimento, mas acredito que para qualquer setor que precise passar um prazo pra entregar algum trabalho.
Aqui na empresa em que trabalho, adotamos a metodologia XP com Scrum, e ela (o conjunto) nos fornecem algumas ferramentas para otimizar o valor estimado. Antes de abrir o jogo, quero resaltar algumas coisas.
Existem diversos fatores para uma estimativa ruim, entre elas, você citou uma, é a falta de experiência. Talvez seja o principal fator sim, seja falta de experiência com programação (no caso da nossa área) ou falta de conhecimento do produto ou negócio.
Assumindo que isso é um problema, e assumindo também que uma boa estivativa é uma das partes mais importantes de um projeto (pois envolve custo, e um projeto com erro de estimativa, dependendo do tamanho, pode fechar uma empresa) vale a pena investir em toda e qualquer ferramenta que tenha como objetivo melhorar a estimativa.
O scrum tem uma ferramenta bem bacana, chamada “poquer do planejamento”. Basicamente consiste em um “jogo”, onde os membros da equipe, munidos de um jogo de “cartas”, fazem as estimativas em conjunto. As “cartas” contém valores (no nosso caso, frações de dias, que variam de 1/4 até 8 dias).
Todas as tarefas (roteiros de usuário) são colocadas em uma ficha, que contém - de forma resumida - o que o usuário solicitou. Todos da equipe tem que ler e entender o problema, propor uma forma de resolver, e, em seguida, estimar, colocar sua carta sobre a mesa (com o valor virado pra baixo) e só então todos desviram a carta. Se não houver concenso no valor, cada um deve explicar o motivo de ter colocado aquele valor. Na sequência, o jogo é feito novamente, até um concenso.
Vale resaltar também que toda estimativa é feito com um computador próximo, para que todas as dúvidas sobre o código sejam sanadas. A estimativa não pode ser feito, em hipótese alguma, se houver dúvida em relação a como implementar, e, em caso de dúvida sobre o solicitado, o time não pode “supor”, mas sim entrar em contato com o product owner (o cliente) e tirar todas as dúvidas, para então voltar ao poquer do planejamento.
Todos os roteiros de usuário devem sem desmembrados em subtarefas, de forma que cada subtarefa tenha um tempo relativamente curto (2 dias no máximo seria um bom valor). Quanto mais detalhada e dividida for, mais fácil será de estimar. Essa divisão em subtarefas deve ser feita antes ou durante o poquer do planejamento.
Enfim, não da pra dizer tudo por aqui, pois não é só o poquer do planejamento que resolve, tem mais detalhes, como por exemplo o uso do task board, do gráfico burndown e etc, mas posso dar um feedback positivo em relação ao XP e scrum.
Lembrando que não da pra aplicar tudo que o XP ou scrum prega, pois depende da estrutura da equipe, quantidade de pessoas.
Se quiser conversar qualquer dia sobre o assunto, só me falar.
abraço.
Com relação a pressão pelo prazo de entrega, nada melhor do que uma estimativa bem detalhada (roteiro de usuário + subtasks). Mostre ao seu product owner tudo o que terá que ser feito para entregar o que ele solicitou, e em caso de inviabilidade (custo x beneficio muito alto) a solução deverá ser repensada, juntamente com o cliente, lógico. De forma alguma deve-se penalizar as estimativas. Na pior das hipóteses, aumente o número de pessoas no time, ou envolva outro programador e divida as subtasks.
Seja qual for a metodologia, acredito que estimar horas não é tarefa para somente uma pessoa, mas sim de uma equipe de desenvolvimento.
E os membros desta equipe não podem ser coagidos a mudar sua opinião por questões comerciais ou hierarquicas. O storyboard deve ajudar também.
Um grande equívoco - comum - é atribuir a somente uma pessoa a tarefa de análise e estimativa de horas (orçar). A análise torna-se alienada.
Talvez um brainstorm seria o melhor primeiro passo.
… ou não…
(rsrsrs)
Um colega, Hernane, comentou ao ler o artigo que tem a questão do “não decepcionar o próximo”. Pensei sobre o assunto e concordo com ele. É natural querermos agradar em um primeiro momento e tentamos nos aproximar da expectativa do interlocutor. Aqui cabe lembrar que decepcionamos também quando entregamos fora do prazo.
O comentários do Douglas e Edgar são totalmente pertinentes, o exercício de estimar deve ser em equipe e utilizando-se de técnicas modernas. Mas gosto de analisar o lado psicológico deste assunto, ajuda a entender melhor.