Aprender a fazê-lo bem pode melhorar a colaboração e a coordenação entre os departamentos, tornando todos mais felizes e produtivos.

Como desenvolvedor web principal no Avance Network e por muito tempo Tech Lead, aprendi que estimativas precisas eram essenciais para que uma empresa fosse saudável e produtiva. Ao longo dos anos, passei boa parte do tempo desenvolvendo minhas teorias sobre por que estimativas e colapsos são tão importantes, e elaborando minha própria metodologia para a melhor maneira de fazê-las. 

Abaixo, tento destilar as lições que aprendi para que outros possam experimentar e melhorar minhas técnicas. Agora, devo ser claro, o conselho abaixo é o que funciona para mim. Tenho certeza que há diferentes abordagens que podem funcionar melhor para os outros. Sinta-se livre para compartilhar sua abordagem favorita nos comentários.

Por que devs são solicitados para estimativas?

O impulso para fornecer uma estimativa para o trabalho de desenvolvimento na maioria das vezes vem de partes interessadas não desenvolvedoras em sua organização. Uma estimativa ajuda a planejar e coordenar lançamentos de produtos, sincronizar o trabalho com outras equipes, garantir que os recursos sejam alocados adequadamente para atender às necessidades do produto e, claro, permitir o faturamento preciso dos clientes quando sua equipe foi contratada para fazer um trabalho para uma empresa externa. 

Dada essa lista, é claro que há muitas razões legítimas pelas quais você será solicitado para uma estimativa. E devido a uma série de razões (culpa, boas intenções, pressão do solicitante de estimativa) você pode até dar uma estimativa de melhor palpite. No entanto, como muitos de nós aprendemos, embora seja fácil dar um número a alguém, é muito mais difícil dar um número que seja de alguma forma preciso. E devido às dependências que outros colocam no número fornecido, uma estimativa ruim às vezes pode causar mais danos do que nenhuma estimativa.

O que uma boa estimativa fornece

Por força de seus pré-requisitos (e o nível de organização e planejamento necessários), uma estimativa precisa permitirá que você entregue seu trabalho com um alto nível de qualidade no menor período de tempo. Ele vai ajudá-lo a evitar falsas partidas e a dor de ter que jogar fora o código desnecessariamente. Isso ajudará a minimizar as mudanças de escopo. Ele permitirá que você se estruture e planeje seu trabalho da maneira mais eficiente possível, e também ajudará todas as outras partes interessadas mencionadas na seção anterior imensamente.

Regras de Estimativa

Então, como você deve fazer estimativas? A técnica de estimativa é uma decisão pessoal que cada dev tem que tomar para si mesmo. Recomendações serão feitas abaixo para diferentes técnicas que trabalharam para diferentes pessoas no passado para chegar à estimativa final. 

Dito isto, aqui estão algumas diretrizes que são importantes a seguir (independentemente da técnica de estimativa).

Nunca escreva código a menos que você tenha uma boa compreensão de qual funcionalidade é necessária

Embora isso não seja algo que se relacione diretamente com a realização da estimativa real, ele está no topo da lista porque é um fator tão importante na escrita de software de qualidade que realmente faz o que o cliente precisa que ele faça. Além do benefício para outros que uma estimativa precisa fornece, o principal artefato que uma estimativa precisa lhe dá é a confiança de que você sabe no que está trabalhando, que você pensou sobre as diferentes questões que podem surgir com arquitetura e implementação, e que você levou isso em conta na quebra do seu trabalho e na elaboração da estimativa.

Sempre estimar uma especificação

Uma estimativa que não se baseia em uma forte compreensão dos requisitos funcionais provavelmente resultará em uma estimativa imprecisa, pois não responderá por toda a funcionalidade necessária. Mesmo que tenha havido reuniões para falar sobre o que é necessário, a menos que seja escrito e todas as partes interessadas tenham concordado com seu conteúdo, deve-se supor que uma das partes interessadas entenda os requisitos de forma diferente das outras.

Se a especificação tiver perguntas sem resposta, ou detalhes faltantes, não se comprometa com uma estimativa ou trabalhe nessa seção

Uma parte importante do processo de escrita de especificações é revisar a especificação e fazer perguntas conforme necessário. Aproveite para cobrir casos de borda e detalhes de implementação que impactarão a funcionalidade. Chame seções que estão faltando detalhes importantes (estas são muitas vezes as seções mais complicadas na especificação). 

A escrita de especificações leva tempo, e às vezes há requisitos que não são compreendidos até mais tarde em um projeto. Isso é bom e aceitável. A consequência disso é que as seções incompletas na especificação não podem ser dadas uma estimativa precisa.

Se o estimador não tiver revisado completamente a especificação, a estimativa não será precisa

Sem revisar a especificação, o estimador simplesmente não está devidamente equipado para fazer uma estimativa para completar a funcionalidade que é exigida pelo cliente. Não há uma maneira real de contornar isso — chegar a uma estimativa nessas circunstâncias tem uma chance muito pequena de realmente se relacionar com precisão com o trabalho que precisa ser feito.

O desenvolvedor que está fazendo o trabalho deve executar a estimativa

Uma estimativa que é feita por alguém que não seja a pessoa que estará fazendo o trabalho é muito mais difícil de acertar. Mesmo que a estimativa seja baseada em uma especificação completa que o estimador entende, ela ainda terá algumas grandes deficiências:

Cada desenvolvedor trabalha em um ritmo diferente, então as estimativas de um dev normalmente não serão transferíveis para um segundo desenvolvedor.

Cada desenvolvedor vai quebrar e planejar seu trabalho de forma diferente.

Diferentes devs possuem diferentes conjuntos de conhecimento de domínio, o que também torna o tempo estimado para aprender/entender as consequências muito diferentes para mudanças (e se você não tiver o conhecimento do domínio, certifique-se de explicar o tempo extra necessário em sua estimativa também).

Se o desenvolvedor não fizer a estimativa, eles perderam o passo extremamente valioso de planejar a execução do projeto, algo que pode contribuir muito para evitar trabalhos desnecessários e entregar recursos dentro do prazo.

Mantenha a especificação e a estimativa atualizada ao longo do projeto, incluindo alterações de escopo

Idealmente, a especificação e a estimativa devem ser mantidas atualizadas ao longo do projeto à medida que os requisitos e o escopo mudam. Ele será indispensável para executar o QA corretamente e servirá como uma referência muito útil para quem precisa aprender mais sobre a funcionalidade no futuro.

Disciplina

Não se deixe intimidar a dar uma estimativa completa para seções que não foram devidamente definidas

Uma vez que você chega a um estágio com as partes interessadas onde as pessoas compraram para que o desenvolvedor seja o autor da estimativa, isso pode levar a uma situação em que a pressão é exercida para se comprometer com uma estimativa de trabalho que ainda não foi totalmente definida. Esse cenário comum pode acontecer com a melhor das intenções. Planos precisam ser feitos, e muitas vezes eles precisam ser feitos por aqueles que não têm uma maneira direta de avançar ao longo do processo de definição. E quando esses planos dependem de estimativas, pode deixar o desenvolvedor em um lugar difícil.

Nesse cenário, é importante ser muito claro: uma estimativa acionável deve ser baseada em um trabalho bem definido. É importante deixar isso claro para o interessado. E ao fazê-lo, não deixe de destacar que você quer dar-lhes uma estimativa confiável, e fazê-lo sem saber todo o escopo do trabalho quase certamente resultará em uma estimativa que não é confiável. Em casos de necessidade, você sempre pode fornecer uma estimativa muito inflada, na pior das hipóteses, mas isso deve ser evitado, e quando você precisar, certifique-se de informar o próprio stakeholder que a estimativa em si pode ser atualizada e feita mais precisa uma vez que mais detalhes sobre a definição do projeto são conhecidos.

Não molde uma estimativa para atender às expectativas de tempo ditadas externamente. Em vez disso, desagueia recursos.

Outro cenário desconfortável que pode ocorrer é quando uma parte interessada tenta ditar o que a estimativa precisa ser, com base em dependências externas ou outros requisitos de negócios, mesmo quando isso está em desacordo com a estimativa real. A esperança é que fazer com que o desenvolvedor se comprometa com essa estimativa garantirá que o trabalho será feito dentro dessas restrições de tempo (ou se não, que o desenvolvedor possa ser responsabilizado por perder o prazo). Como deve ser claro até agora, qualquer estimativa que não se basee em uma quebra realista de requisitos bem definidos não deve ser considerada confiável ou, de fato, ser dada. Nesse cenário, a resposta adequada é negociar espaço para o cronograma. Como em: se você quiser liberar até esta data, então precisamos cortar a quantidade de trabalho que vai precisar ser feito. Mantenha-se firme e continue trazendo a conversa de volta ao seu desejo de fornecer uma estimativa que será precisa e confiável para todos os envolvidos.

Traduzindo horas em dias: seja realista

Sua estimativa deve acabar configurando um número de horas para completar as tarefas definidas. Para fins de planejamento, muitas vezes você será perguntado no início de um projeto quantos dias de codificação serão necessários. Acho que é mais preciso criar estimativas granulares em horas e traduzir as horas totais em vários dias. Ao fazer isso, não deixe de considerar coisas como outras funções (plantão de bugs, outros projetos), responsabilidades de gestão, férias e férias. Também não deixe de prestar contas das tarefas rotineiras que o desenvolvedor precisa fazer (reuniões, e-mail, avaliações de especificações, planejamento). Descobri que assumir mais de 6,5 horas de trabalho de projeto produtivo por dia pode resultar em um descompasso entre as expectativas de produtividade e os resultados reais.

Torne seu colapso e estime público e peça feedback

Uma vez que você tenha seu colapso e estimativa completo, é melhor postá-lo online e compartilhá-lo com seu PM e membros da equipe. Mesmo que eles estejam menos familiarizados com os detalhes da especificação do que você, outras pessoas podem ver buracos em seu colapso ou podem ser capazes de levantar questões sobre estimativas para itens específicos que você não tinha pensado. Lembre-se: torna-se exponencialmente mais caro consertar as coisas quanto mais você entra em um projeto. Mudar uma linha em uma estimativa é barato. Reescrever um módulo do ground-up não é. Tome o tempo extra para solicitar feedback.

Postar estimativas publicamente (e mantê-la atualizada em relação à conclusão da tarefa) também torna você mais responsável pelo seu progresso (em um bom caminho). Um PM responsável verificará seu progresso periodicamente, especialmente se parecer que as coisas estão paradas (um cenário onde você deve estar em comunicação aberta com o PM de qualquer maneira).

Não há problema em dar uma faixa de estimativa, juntamente com uma escala de confiança

Se toda a especificação não puder ser concluída a tempo da estimativa, dê uma estimativa completa para as partes onde você pode e alcance/confiança para seções onde a especificação está incompleta. Use seu julgamento: você pode ser solicitado para uma estimativa de confiança de 100% em um grande projeto, mas se a especificação não está pronta para isso, então seja claro sobre o que sua estimativa cobre. É muito melhor para todos a longo prazo dizer: 60-100 horas com 60% de confiança do que não dizer nada ou fazer um número exato sem baseá-lo em nada. E então, à medida que a especificação se torna mais completa, a estimativa deve seguir o exemplo.

Mitigação de riscos e contabilização de iterações em projetos maiores

Grandes projetos (definição arbitrária: projetada para levar mais de dois meses, embora isso possa variar) vêm com seu próprio conjunto de desafios. Eles terão estimativas maiores (e, portanto, mais oportunidades para bagunçar as estimativas), eles terão mais pessoas confiando na data de lançamento projetada para qualquer que seja sua dependência, eles são mais propensos a ter grandes especificações onde nem todas as funcionalidades são definidas na frente, e eles são mais propensos (pelo menos em alguns domínios) a ter ciclos de lançamento/iterado. Como se explica isso nas estimativas?

Embora cada projeto precise ser abordado com base em suas próprias necessidades, a abordagem geral para grandes projetos com iteração deve ser usar as diretrizes acima indicadas em um nível macro e micro. Se o projeto muito grande tem uma seção de trabalho totalmente definida na especificação e o resto dele vagamente definido, então faça uma quebra e estimativa para a primeira seção. Se uma estimativa completa for necessária para todo o projeto, então faça uma estimativa muito conservadora para a coisa toda com base no que você sabe da funcionalidade, anexe suas suposições e confiança no número, e continue a perseguir a conclusão de toda a especificação e todas as suas perguntas respondidas.

Isso também se aplica à iteração: se o planejamento do projeto exige um ciclo de lançamento contínuo, com recursos sendo constantemente refinados e redefinidos ao longo do processo iterativo, isso é algo que, por definição, será extremamente desafiador estimar com precisão no início não há um requisito funcional definido. Em uma situação como esta, você simplesmente não pode estar tão confiante em uma estimativa como você estaria com uma especificação funcional completa. Se esta é a realidade e você é solicitado a dar uma estimativa inicial, não há nada a fazer a não ser estimar muito conservadoramente para as seções mal definidas, observando suas suposições e nível de confiança. Infelizmente, essas situações às vezes são inevitáveis — o que você pode fazer para mitigar os danos potenciais de uma estimativa ruim é continuar a buscar uma especificação funcional completa, ao mesmo tempo em que é muito claro sobre as limitações que existem em qualquer estimativa que você forneça de tal forma que todas as partes estejam tão bem equipadas quanto possível para lidar com isso.

Certifique-se de incluir tempo para solicitações de puxar, testar e liberar problemas

Isso é algo que é muito fácil de esquecer, e deixar o tempo para puxar testes de solicitação e liberação de produto (especialmente quando estes não são triviais) pode deixar um gosto amargo na boca de todos quando os recursos são entregues a tempo e, em seguida, a última etapa de QA e liberação acabam arrastando-se e sobre. Em cenários em que as RS são uma parte necessária do processo, e especialmente quando elas se desempeciam em revisores muito ocupados, o tempo que eles adicionam a uma estimativa pode ser não trivial. Embora não necessariamente aumente a quantidade de tempo do desenvolvedor (embora possa, com base na quantidade de feedback), ele adicionará ao tempo de entrega. Um desenvolvedor responsável deve ter o cuidado de levar esses fatores em conta em seu planejamento e ao assumir compromissos quanto às entregas, com base nas especificidades das responsabilidades do projeto (por exemplo: quem estará revisando PRs, quem possui QA, o que estará envolvido com o lançamento, etc).

Técnicas

As melhores estimativas envolvem a quebra do trabalho a ser realizado em pequenas tarefas — quanto menor, melhor. Estime as tarefas, quebre-as e repita até que elas sejam pequenas o suficiente. Esta é a essência de um método muito minucioso e preciso para a estimativa. Estabeleça uma meta de granularidade. Eu recomendo duas horas no máximo, e quebrar tarefas até que você bater que em todo o quadro. Se você tem uma tarefa acima do limiar, quebre-a ainda mais. Então resumi tudo. 

Existem várias ferramentas que você pode usar para ajudar a organizar isso. Prefiro usar cartões Trello (uma por tarefa principal com uma lista de verificação para uma subseção e caixas de seleção para granularidade), embora isso exija cálculo manual de horas. Você também pode usar Excel, MS Project, FogBugz (ou uma das muitas outras ferramentas de organização de projetos por aí). O mais importante é que você use uma ferramenta que funcione para você e seu processo e que não adicione sobrecarga organizacional.

Existem outras abordagens para as estimativas na Internet (eu me aprofundo mais nas práticas de estimativa neste artigo). Especialmente no mundo ágil, do Planejamento para muitos outros. Se isso funciona para você e ajuda você a obter uma estimativa precisa, então vá em busca dela. Basta lembrar, pode ser arriscado confiar em técnicas que tiram os resultados da estimativa do desenvolvedor que estará fazendo o trabalho real. 

Você tem pensamentos sobre a melhor maneira de fornecer estimativas para que desenvolvedores e equipes de desenvolvimento possam trabalhar com o resto de sua organização? Deixe-nos saber suas dicas e truques nos comentários.

O Avance Network é uma comunidade fácil de usar que fornece segurança de primeira e não requer muito conhecimento técnico. Com uma conta, você pode proteger sua comunicação e seus dispositivos. O Avance Network não mantém registros de seus dados; portanto, você pode ter certeza de que tudo o que sai do seu dispositivo chega ao outro lado sem inspeção.