Qual é a margem de erro aceitável ao estimar a duração de um projeto?

A empresa em que trabalho visa obter uma margem de erro máxima de 10%. Eles esperam que os analistas não percam a estimativa em mais ou menos que 10%.

Não sei o que pensar, pois não tenho nada para comparar.

O que poderia ser uma boa linha de base para medir se estamos estimando muito errado, por mais ou menos? Quanto (em%) acha que é certo para a falta?

A menos que você esteja estimando algo muito semelhante ao que você e seus colegas de trabalho já fizeram antes, +/- 10% é ridiculamente otimista. Seu gerenciamento não tem muita experiência com software ou não conhece os Grandes limites para a estimativa de software . Esse artigo tem algum material de apoio que o acompanha e muita literatura pode ser encontrada.

Vamos examinar um sistema muito mais simples do que um projeto de software típico: o Cubo de Rubik. Você pode resolver qualquer posição em 20 movimentos , máx. Mas, como você está estimando, só é possível olhar para um determinado cubo por alguns minutos antes de fornecer a solução. Você pode dar uma boa estimativa? Não, às vezes estimar um processo leva mais tempo do que fazê-lo.

Outro sistema simples: Pinóquio. Um autômato de madeira, seu nariz cresce quando ele diz uma mentira. O que acontece quando Pinóquio está em repouso e depois diz "Meu nariz está crescendo"? Alguns sistemas não são passíveis de previsão, são indecidíveis.

Esses dois problemas estão embutidos na maioria dos sistemas de software. Por esse motivo, você nunca obterá estimativas próximas a +/- 10%.

Meu conselho é fornecer uma estimativa altamente acolchoada, trabalhar como um escravo para concluir o projeto o mais rápido possível e, em seguida, parecer ocupado até que você esteja dentro de 10% abaixo ou acima. Nesse momento, anuncie um sucesso espetacular.

Eu ficaria muito hesitante sobre qualquer tipo de "margem de erro de destino" porque realmente depende do projeto. Se você estiver tentando estimar quanto tempo levará para instalar, configurar e personalizar um novo sistema de CRM, onde ninguém sabe ao certo que tipos de personalizações serão necessários e que tipo de alterações nos processos de negócios serão necessárias. a empresa não tem histórico de projetos grandes semelhantes, sua margem de erro deve ser bastante grande (por exemplo, você pode imaginar que levará 18 meses +/- 50% e cotará 9-27 meses). À medida que o projeto avança, as especificações ficam mais claras, as decisões são tomadas sobre os processos de negócios, os desenvolvedores ficam mais confortáveis ​​etc. essas margens de erro devem ficar mais apertadas. Se você estiver tentando estimar por quanto tempo criará o 101º site de comércio eletrônico básico quando você ' Se você tiver um bom histórico dos 100 primeiros, seria de esperar uma estimativa muito mais precisa. A maioria dos projetos, no entanto, vai cair em algum lugar no meio.

Agora, se você estiver citando um único número em vez de um intervalo, a resposta provavelmente será começar a citar o intervalo, para que a pessoa que faz a estimativa possa especificar a precisão que espera que sua estimativa seja.

Uma boa linha de base seria aquela baseada em dados reais que você coletou.

O primeiro passo para fazer isso é registrar todas as estimativas . O segundo passo é registrar os resultados reais . Seja honesto, não fique tentado a 'auto-ajustar' o real. Reúna o suficiente dessas informações e você terá alguns dados para basear estatísticas de quão boas são suas estimativas. Observe que isso pode / irá variar muito de acordo com quem fez a estimativa e quem fez o trabalho. Somente fazendo isso, é razoável esperar que você dê uma "margem de erro" que é qualquer outra coisa pura.

Também não para por aí; analisar o que faz com que as estimativas sejam desativadas pode ajudar a melhorar a precisão de suas estimativas futuras. Nota: Eles ainda permanecem estimativas e, como tal, são apenas estimativas .

A estimativa também não termina após a primeira estimativa; isso é algo que pode ser ajustado à medida que o projeto avança à medida que mais conhecimento é adquirido, reduzindo a possível margem de erro à medida que avança. Quanto mais aberto você estiver com a comunicação, as surpresas anteriores serão discutidas - levando as pessoas a serem menos surpresas e permitindo mais tempo para fazer ajustes nas expectativas do projeto ou dos clientes.

Segundo, talvez uma maneira melhor de lidar com a margem de erro seja a ' confiança interna ', em vez de apenas% de margens de erro. Você baseou a data estimada de entrega em um intervalo de confiança, em vez de uma data singular.

PERT é um exemplo de uma estrutura para lidar com estimativas com base em raciocínio estatístico. Por exemplo:

"Com base no que sei agora, temos um nível de confiança de 90% que podemos oferecer em 8 meses. 95% de confiança em 10 meses, 99% de confiança em 2 anos, etc."

Observe aqui: quanto mais confiantes eles quiserem, maior será a estimativa. Dependendo da complexidade (ou seja, quão preciso você pode ser), pode haver uma pequena diferença entre 80% e 90%, ou pode ser enorme!

Por fim, boa sorte;) Se você resolver a 'margem máxima de erro' na estimativa de software, na qual poderá especificar algo como 'todas as nossas estimativas serão de +/- 10%', certifique-se de encomendar um filme de bilheteria pelo resto nós na indústria de software. Estou pensando em algo como um cruzamento entre o Office Space e The Matrix: D

Na verdade, depende muito do tamanho e da complexidade do projeto.

Se a estimativa do seu projeto for de 1 semana - 10% é razoável. Significa +/- 1/2 dia.
Se for 1 mês, 10% é instável - pela minha experiência, é impossível prever o que você descobrirá em 1 mês.

Mais de um mês - todas as apostas estão desativadas :).

Estes são por desenvolvedor - portanto, para uma equipe de 4 desenvolvedores, 1 semana == 1 mês.

Para uma equipe de 4 desenvolvedores, é bom apresentar uma lista de recursos que podem ser executados em 1 mês e estar dentro de 10% para esses recursos. Em seguida, faça uma nova estimativa para o próximo mês.

Eu fiz algumas suposições ingênuas aqui

1. Todos os desenvolvedores podem trabalhar em paralelo.
2. Não consideraram o testador - eles devem ter algum tempo para testar
3. Todos os desenvolvedores são iguais - Frontend, Backend, Designers etc ...

Você precisa levar isso em consideração .. mas essa é a ideia geral.

Existem muitas variáveis:

1. Quanto tempo dura o projeto?

2. Como o projeto será gerenciado? Cascata? Ágil? SCRUM?

Eu assumiria a partir da pergunta Waterfall. Se for esse o caso, espera-se que você falhe em alguma porcentagem, dado o pedido de margem.

Se a resposta for alguma metodologia Agile, especialmente algo como SCRUM. Realmente não importa qual é a porcentagem da margem. Uma margem de erro de 50% em um Sprint de 2 semanas é de 1 semana, em um Sprint de 1 semana são de 2,5 dias, os dois piores cenários. Isso ocorre porque a data de entrega é re-estimada a cada Sprint e torna-se cada vez mais precisa ao longo do tempo, em vez de cada vez menos.

Com o Waterfall, a margem de erro de 50% também não é ouvida, mas em um projeto de 12 meses, que é de 6 meses, e ele realmente não é descoberto / admitido, isso é ruim até 10 meses após os 12.

Quando eu liderava as equipes de software, mais ou menos nos limites do Cretáceo / Terciário, chegamos perto de atingir +/- 10% na estimativa. Foi cerca de +/- 15% se minha memória muito desonesta serve. Mas isso foi porque estávamos estimando o que já tínhamos feito : firmware de comunicação em tempo real relativamente simples, que pegou bytes de A e os moveu para B usando uma linguagem com a qual estávamos familiarizados, em um ambiente de tempo real projetado por nós. , conversando com hardware projetado internamente por pessoas a alguns escritórios de distância. Muitas variantes leves sobre o tema acima, por literalmente anos .

Esperar atingir esse tipo de taxa de erro na estimativa normal de projetos de software é, francamente, ridículo . Quando você vê isso aparentemente alcançado, é porque as pessoas superestimam e acolhem (fazendo coisas extras e projetos para animais de estimação para gastar o orçamento), ou subestimam e trabalham como cães à noite e nos fins de semana para ganhar tempo.

Você provavelmente já ouviu a coisa de 300%, certo?

Na verdade, eu uso. Totalmente baseado no que tenho visto há anos. Quando ouço um dia ou dois, é uma semana ou mais para ser realmente feito . E testado. Em todos os ambientes. Documentação atualizada. Usabilidade testada. Desempenho testado. Carga testada. Algumas horas são realmente mais como um dia.

Acho que somos muito ruins em estimar por causa de:

• Ajudando os outros
• Sendo interrompido
• Treinando novas pessoas
• Outras coisas chegando
• Ficar doente ou indisposto
• Cobrindo as pessoas que saem
• Precisando de férias ou folga
• Ficar distraído por outras pessoas
• Sendo sustentado por outros grupos
• Ser excessivamente otimista sobre realista
• Não alocando tempo para trabalhar em falhas de teste intermitentes
• Excluindo facilmente o tempo de teste, especialmente escrevendo testes automatizados

Portanto, no nível mais alto, com pessoas de negócios que precisam de estimativas superiores a 300%, o que acabamos fazendo é buscar estimativas razoavelmente boas, mas ao preço de ser de nível superior e mais geral. "Teremos uma função de edição do usuário", mesmo que a versão 1 signifique apenas 1 grupo de usuários para alterar 1 campo.

Quando se trata de "Qual é a margem de erro aceitável ao estimar a duração de um projeto?" Acho que essa abordagem, usada em muitos ambientes Agile, ajuda a mudar a questão para qual é a funcionalidade mínima para obter uma versão alfa ou beta ativa e, em seguida, iterá-la.