Como responder quando lhe pedem uma estimativa?

De O Programador Pragmático: Do Viajante ao Mestre :

What to Say When Asked for an Estimate

You say "I'll get back to you."

You almost always get better results if you slow the process down and spend some time going through the steps we describe in this section. Estimates given at the coffee machine will (like the coffee) come back to haunt you.

Na seção, os autores recomendam o seguinte processo:

• Determine a precisão de que você precisa. Com base na duração, você pode citar a estimativa com precisão diferente. Dizer "5 a 6 meses" é diferente de dizer "150 dias". Se você escorregar um pouco no 7º mês, você ainda é bem preciso. Mas se você escorregar para o 180º ou 210º dia, não muito.
• Certifique-se de entender o que está sendo perguntado. Determine o escopo do problema.
• Modele o sistema. Um modelo pode ser um modelo mental, diagramas ou registros de dados existentes. Decomponha esse modelo e crie estimativas a partir dos componentes. Atribuir valores e intervalos de erros (+/-) para cada valor.
• Calcule a estimativa com base no seu modelo.
• Acompanhe suas estimativas. Registre informações sobre o problema que você está estimando, sua estimativa e os valores reais.
• Outras coisas para incluir na sua estimativa são desenvolver e documentar requisitos ou alterações nas especificações de requisitos, criar ou atualizar documentos e especificações de design, testes (unidade, integração e aceitação), criar ou atualizar manuais do usuário ou READMEs com as alterações. Se houver duas ou mais pessoas trabalhando juntas, haverá sobrecarga de comunicação (telefonemas, e-mails, reuniões) e mesclará o código-fonte. Se for uma tarefa longa, conta para coisas como outro trabalho, folga (feriados, férias, tempo de doença), reuniões e outras tarefas de sobrecarga ao escolher uma data de entrega.

A estimativa de software é a tarefa individual mais difícil na engenharia de software - em segundo lugar, a elicitação de requisitos.

Existem muitas táticas para criá-las, todas baseadas na obtenção de bons requisitos primeiro. Mas quando suas costas estão contra a parede e eles se recusam a lhe dar melhores detalhes, Fake It:

1. Dê uma boa olhada nos requisitos que você tem.
2. Faça suposições para preencher as lacunas com base em seu melhor palpite sobre o que elas querem
3. Anote todas suas suposições
4. Faça-os sentar, ler e concordar com suas suposições (ou, se tiver sorte, faça com que eles cedam e dêem a você requisitos reais).
5. Agora você tem requisitos detalhados dos quais pode estimar.

É como minha mãe costumava ameaçar quando eu era criança "Apresse-se e escolha algumas roupas, ou eu vou selecioná-las para você!"

Eu fiz desenvolvimento para um cara que era muito inflexível em querer estimativas precisas. O que nós resolvemos, que funcionou muito bem, foi isto:

• Eu faturei pelo tempo todo que gastei estimando. Chegou a cerca de 20-25% do que eu faturei.
• Eu fiz um exame extremamente detalhado das tarefas. Nenhum tiro do quadril. Eu entrei no código, descobri que linhas precisavam ser alteradas, que outras partes do programa isso afetaria, quanto teste eu teria que fazer para garantir que as coisas ainda funcionassem. Eu estimaria cada peça em unidades de 0,1 horas (6 minutos).
• Enviei-lhe minha estimativa para cada tarefa junto com essa análise detalhada.

20-25% do faturamento parece muito.

Mas ele me pediu para fazer a mudança XYZ, pensando que levaria cerca de 2 horas. Em 1 hora de estimativa detalhada, eu determinaria que levaria 8,5 horas. Então ele decidiria se valeria 8,5 horas de pagamento. Se não, então ele economizou 7,5 horas sobre o que teria custado se eu tivesse feito isso sem uma estimativa.

E se ele quisesse investir 8,5 horas, o trabalho detalhado que fiz para a estimativa foi um trabalho que eu teria que fazer de qualquer maneira.

Descobri que com esse método consegui trazer a maioria das tarefas a tempo ou até mesmo cedo, sem precisar superestimar muito. Como o tempo foi quebrado tão minuciosamente, eu percebi desde cedo se estava escorregando. Se eu batesse em bloqueios de estrada para que depois de 3 horas eu pudesse dizer que minha tarefa de 8,5 horas demoraria 12, eu poderia falar com ele antes que mais tempo passasse para que ele pudesse reavaliar e tirar o recurso se ele estivesse preocupado com o custo .

Ele era níquel e diming? Não, eu olhei para ele como deixá-lo aplicar seu dinheiro, onde ele viu o maior benefício. E fiquei feliz em ter experiência em estimar, o que eu sempre fui terrível.

Frequentemente pedimos uma "estimativa de estimativa" durante as reuniões, nas quais recebemos ideias muito amplas sobre o que eles gostariam de fazer. Eu sempre digo, "se você quer uma resposta hoje é um ano e um milhão de dólares. Se você gostaria de me dar mais detalhes e algum tempo para revisá-los, então eu posso refinar esses números para você". >

Eles quase sempre entendem.

Depende de qual é a estimativa.

Para uma estimativa inicial de alto nível para um caso de negócios, as principais coisas são:

1. Velocidade. Qualquer método que você use, precisa ser rápido. O ponto principal é que as partes interessadas não têm certeza se vale a pena fazer o projeto - e é por isso que elas precisam dos números para o caso de negócios. Se o business case fosse sólido, eles não precisariam de suas estimativas. A maior parte desses projetos não irá adiante, então é importante que não seja gasto muito esforço fornecendo a estimativa.
2. Dê um intervalo. Faça amplo. Você não teve tempo para analisar requisitos, realizar workshops com partes interessadas, validar suposições. Uma ampla gama informa ao destinatário da estimativa "Os projetos de software são naturalmente complexos e arriscados - se você quiser uma estimativa adequada, precisará fornecer mais detalhes e mais tempo". O problema em dar um único número ou um intervalo estreito é que ele o coloca em um canto definindo expectativas antes que qualquer análise real seja feita.

Eu acho a melhor técnica para escolher um projeto comparável que "pareça" o mesmo. "Feel" é completamente subjetivo - mas, com esse tipo de estimativa, minha experiência me diz que você não encontrará medições objetivas. Em seguida, forneça um amplo intervalo. Eu li alguns livros que dizem que um intervalo de -50% a + 100% é bom, mas depende de muitos fatores.

Para uma estimativa detalhada e de baixo nível:

1. Você precisa de uma linha de base. Se a linha de base não for estável, a estimativa não tem sentido.
2. A parte de baixo é a melhor. Obter uma análise detalhada do trabalho, estimar cada componente e, em seguida, acumulá-lo em um número maior. Acho que planejar o poker é uma ótima técnica aqui.
3. Contingência do documento. Deixe claro onde qualquer contingência (se houver) é adicionada. É adicionado a cada item de linha? Ou para toda a estimativa? Ou para riscos específicos? Ou não há nenhum?
4. Indique suas suposições. Valide o máximo possível de acordo com o período de tempo.
5. Indique explicitamente o que está incluído e excluído da estimativa. Por exemplo, a revisão está incluída? Os atrasos técnicos estão incluídos?

"Duas semanas!"

Sério. Minha primeira estimativa é sempre de duas semanas. Porque eu tenho algum tipo de bloqueio mental bizarro que me faz pensar que tudo soa como se fosse duas semanas.

Eu tento contornar isso, tentar realmente pensar sobre quanto tempo eu acho que algo vai demorar, tentando identificar todos os possíveis pontos problemáticos e bits que parecem muito pretos para mim. para estimar com precisão. E tente reconhecer que, se a minha resposta for "Duas semanas!", Provavelmente não o fiz.

Praticamente todo bom gerente que eu tive aprendeu a reconhecer "Duas semanas!" como uma resposta que requer um leve chiado verbal em resposta.

Alguns conselhos do lado negro de alguém que aprendeu da maneira mais difícil.

The requirements are unclear. Nobody has done an in depth analysis of all the implications.

Não faça uma estimativa neste momento. Não se estima quantos soldados são necessários para vencer uma batalha sem pistas sobre os números inimigos. A estimativa é feita após o escotismo. Isto é, a menos que você já tenha lutado contra esse inimigo.

The new feature will probably break some assumptions you made in your code and you start thinking immediately of all the things you might have to refactor.

Esta é sua responsabilidade de levar em consideração, a menos que você espere que os outros tenham conhecimento sobre essa área.

You have other things to do from past assignments and you will have to come up with an estimate that takes that other work into account.

O mesmo que acima, mesmo para trabalhos imprevistos criados por um colega de equipe desleixado ao seu lado com um procedimento de teste quase inexistente que faz com que seu código se destaque e não seja possível prever com precisão antecipadamente. É uma previsão do tempo.

The 'done' definition is probably unclear: When will it be done? 'Done' as in just finished coding it, or 'done' as in "the users are using it"?

Entenda o requisito de fim de usuário aqui, pense como um usuário. Não faça o que seus colegas fazem se eles estimarem que algo está "pronto" só porque algumas funcionalidades básicas com um fluxo de trabalho básico que nenhum usuário pode tolerar é o que eles consideram ser "feito" . Pense nisso do ponto de vista do usuário, porque isso é tudo o que você está fazendo a estimativa para entender normalmente. Estime para os requisitos completos de usuário final, não para os requisitos técnicos do barebone. E perceba que seus clientes que pedem estimativas serão totalmente imprecisos aqui sobre como eles dizem as coisas e entendem os aspectos técnicos do que você diz.

No matter how conscious you are of all these things, sometimes your "programmer's pride" makes you give/accept shorter times than you originally suppose it might take. Specially when you feel the pressure of deadlines and management expectations.

Não faça isso! Você parece um trabalhador esforçado e auto-motivado e possivelmente alguém que se entrega facilmente à coerção.

O problema aqui é o seguinte: digamos que você e Joe tenham feito estimativas de tempo para a mesma tarefa (mas entre dois funcionários separados, inconscientes de ambas as estimativas ao mesmo tempo). Você estima valentemente, "uma semana" . Tudo bem, você pensa, você vai trabalhar mais de 100 horas por semana, horas extras não pagas. Agora você está três dias atrasado.

Enquanto isso, Joe estima 5 meses. Você acha que isso é ridículo, você acha que pode conseguir isso em uma semana. Quanto Joe trabalha? 10 horas por semana? ... exceto que ele termina no tempo em exatamente 5 meses.

Adivinha quem é percebido como o idiota? Está certo você. Joe parece ser um grande trabalhador, você parece pouco confiável agora. Não importa tanto que você tenha conseguido um resultado ainda melhor em aproximadamente 7% do tempo que Joe tomou. O que importa é que você ficou 3 dias fora de uma estimativa de uma semana.

Nunca erre do lado da estimativa mais apertada. Errar do lado da estimativa mais solta. Há uma reputação a ser construída em sua empresa e não se baseia tanto no tamanho de suas estimativas quanto na precisão de suas estimativas. É fácil ser preciso com uma estimativa que é muito longa, você só tem mais tempo para trabalhar no problema e resolvê-lo melhor. Uma estimativa que é muito curta não deixa espaço para respirar, você quer encontrá-lo desesperadamente ou você está ferrado.

Há uma entrada de blog que descreve como manter um registro de quão precisas suas informações anteriores as estimativas se foram, e então, da próxima vez que você disser a alguém que "serão duas semanas", você poderá ver sua história anterior e ver quanto tempo demorou na última vez em que disse "serão duas semanas".

Eu não tentei por mim mesmo, mas gostaria de ver como minhas estimativas são precisas.

Depende da organização e de como as estimativas são usadas.

Se a estimativa é apenas para fornecer uma ideia geral de quando ela estará pronta, geralmente posso fazer uma estimativa rápida com base na minha experiência. Muitas vezes incluirei qualquer incerteza ou possíveis variações com a estimativa, juntamente com a forma como as alterações podem afetar outras áreas do sistema e a extensão dos testes de regressão necessários.

Se a estimativa for usada para qualquer coisa contratual ou em um cenário em que um tempo mais preciso seja necessário, eu faço uma análise completa do trabalho. Isso é mais trabalho e exige mais profundidade pensando sobre o design e as alterações no sistema, mas é muito mais preciso, especialmente para trabalhos maiores.

Em ambos os casos, a comunicação contínua é fundamental. Se você se deparar com algo inesperado, divulgue-o no momento em vez de esperar até o prazo final. Se os requisitos não forem claros, certifique-se de documentar sua compreensão sobre eles e a funcionalidade que planeja entregar. Isso também é útil em todas as suposições feitas por você. E no que diz respeito a prioridades concorrentes, quando um trabalho atrapalha outro, fique claro como isso afetará o cronograma.

Estimativas para quê? Pequenas tarefas ou soluções completas.

O último eu raramente faço, mas apenas adivinho, acrescente um pouco, faça o gerente adicionar um pouco e torná-lo em um intervalo, com uma pequena nota ao lado afirmando que o acima é um palpite.

Tarefas pequenas - Planejando o poker Eu encontrei um ótimo trabalho (não perfeito, algumas tarefas de 1pt levaram muito mais longo e algumas tarefas de 5pt levaram minutos, mas tudo se equilibra no final).

Apresente um intervalo com base no que você conhece hoje. Use o Cone of Uncertainty para fornecer o intervalo em torno de suas estimativas iniciais.

Toda semana calcule quanto resta para fazer, re-estimar com base no que você sabe. Uma vez que você tenha uma amostra suficiente de quanto trabalho está recebendo por semana, forneça um intervalo de confiança de 90% para o que resta para dar um intervalo de datas (geralmente) cada vez menor à medida que o projeto avança e a quantidade de trabalho restante ) encolhe.

Com confiança. Eu não posso te dizer quantas vezes eu estraguei uma reunião inicial com um cliente, não colocando em profissionalismo ao dar uma estimativa. Mesmo se você está soprando números do nada - certifique-se de sempre manter alguma estimativa ao redor. Dito isto, tenha cuidado para não se estimar em um buraco. Coisas diferentes levam quantidades diferentes de tempo, esforço e recursos para montar. Aqui está uma boa maneira de fazer isso:

Them: How much will it cost?

Me: It depends on what you want me to do. Generally, I start this sort of project at around $X.

Às vezes, estimar torna-se um enorme desafio para você e sua equipe, especialmente quando estamos falando de estimativa de projeto de software.

Uma vez que decidimos compartilhar nossa experiência e nosso conhecimento sobre o processo de estimativa de software e definimos quatro tipos distintos de estimativas :

• figura de estimativa
• estimativa de serviço
• estimativa de recurso
• estimativa componencial

Naturalmente, esses tipos são distintos. O Ballpark é o que geralmente é chamado de “guesstimate”. Portanto, é um número ou intervalo aproximado que dá uma ideia geral do custo e isso pode ajudar uma perspectiva a decidir se gostariam de levar a discussão adiante.

Como regra geral, os clientes precisam de uma estimativa no início do projeto. E nosso conselho é: a discussão do projeto e o fornecimento de valores de referência devem ser apenas passos para receber uma estimativa do componente (que é flexível, pode-se fazer uso do tipo de componente para todo o processo de desenvolvimento. para re-estimar a partir do zero quando você quiser adicionar, remover ou substituir recursos, serviços etc).

Todos devem ter em mente os riscos que acompanham a estimativa de desenvolvimento de software: subestimação, superestimação, cenário total de falhas épicas, etc.

Você pode ler mais no nosso blog!

link

Espero que esta informação o ajude!

Primeiro, se alguma tarefa fosse atribuída a mim, eu a dividiria em subtarefas. Eu estimaria o tempo para cada subtarefa e, provavelmente, com subtarefas, eu seria capaz de encontrar a área problemática e, portanto, seria capaz de prever como demoraria até certo ponto.

Mas ainda assim todo o planejamento ajudaria apenas até certo ponto. Somente quando você começar a codificar, você pode encontrar os problemas exatos

I always end up giving estimates that I later realize I cannot fulfill. It has happened countless of times, and I always promise it won't happen again.

Parece que você está sendo solicitado por um compromisso, não uma estimativa. Essas são coisas diferentes, mas se você conseguir gerenciar os compromissos de forma confiável, isso realmente ajudará sua credibilidade e sua carreira.

Alguns conselhos baseados nos meus 10 anos de experiência:

• Sempre forneça um intervalo (ou seja, limite inferior e superior). Isso comunicará seu nível de incerteza
• Se você tem uma incerteza muito grande, peça um adiamento (por exemplo, um dia para fazer a análise e, em seguida, forneça um intervalo mais restrito)
• Se a tarefa for muito grande, divida-a e forneça um intervalo para cada peça

Se você faz muitos projetos para o mesmo chefe ou cliente, pode tentar estimar em linhas gerais de complexidade em vez de semanas ou meses, possivelmente em tamanhos de camisetas. Identifique alguns projetos anteriores e atribua a eles os tamanhos S, M, L, XL.

E, em seguida, pergunte a si mesmo: qual projeto é semelhante ao escopo? E então, em vez de responder com "2 meses", você pode responder com "soa como um L para mim" (ou qualquer que seja sua calibragem para o projeto).

Isso é muito fácil de entender, e também está claro que há muita incerteza nessas suposições.

Então, quando os requisitos mudam, você pode dizer "essa mudança faz parecer mais um XL".

Um pouco atrasado, mas quando eu estava no exército, fomos instruídos a usar o PERT para determinar as estimativas. Isso requer alguma experiência em seu campo e na tarefa em mãos. Foi surpreendentemente preciso determinar o tempo estimado de conclusão ao manter e consertar dispositivos eletrônicos (rádios complexos e equipamentos de comunicação via satélite), onde qualquer número de coisas pode estar errado ou ser encontrado e necessário para ser consertado durante a manutenção de rotina. As estimativas foram importantes porque outras unidades podem ficar inoperantes até receberem seus equipamentos de comunicação. Um que eu usei é este Free Online PERT Calculator