Como sabemos, nós, Gerentes de Projetos, não somos responsáveis por concluir todas as tarefas, na verdade, somos responsáveis por identificar e ajudar a atribuir essas tarefas e, depois, estimar quanto tempo elas levarão para serem concluídas. Essas estimativas são unificadas para determinar o cronograma geral do projeto. Mas então, como estimamos o tempo que uma determinada tarefa levará para ser concluída ? Boa leitura e vamos nos conectar no Likedin!
Qual a diferença entre estimativa de Duração e estimativa de Esforço ?
Não é novidade que estimamos atividades com a ajuda de nossas equipes, entretanto, devemos ter em contexto alguns conceitos para apoiar a equipe nessas definições. Um exemplo de conceito a se levar em consideração para estimações é o de estimativa de duração e estimativa de esforço. Estimativa de duração é a previsão da quantidade total de trabalho necessário para concluir uma tarefa levando em consideração o período de inatividade sobre a atividade, ou até mesmo de espera. Já a estimativa de esforço leva em consideração o tempo aplicado à atividade apenas durante a execução da mesma, sem levar em consideração o tempo de inatividade ou espera.
Um pequeno exemplo: A estimativa de esforço para pintar uma parede pode ser de 30 minutos, mas a estimativa de duração para esta mesma atividade pode ser de 20 horas. Isso porque, além dos 30 minutos para a execução da pintura de fato, há também 19 horas e 30 minutos para que a tinta esteja seca, há um tempo de inatividade para esta tarefa, se houver atividades que dependam desta parede pintada, certamente terão que esperar 20 horas para começarem. É importante entender estes conceitos relacionados à estimativa de tempo e estimativa de esforço porque isso pode nos ajudar a atuar de maneira mais eficiente com os recursos disponíveis. Se houver tempo ocioso associado a uma determinada tarefa, seu colega de equipe estará livre para realizar outras atividades. Um pintor pode fazer outras tarefas enquanto a parede está secando, como pintar a porta da sala ou a moldura da janela.
Uma estimativa de esforço irreal pode impactar negativamente o cronograma do projeto. O otimismo pode ser um dos principais fatores para subestimarmos a quantidade de tempo que levará para concluir uma tarefa. Vale lembrar que o otimismo é uma ótima característica para um gerente de projeto, mas otimismo excessivo nos pode levar a ignorar os riscos potenciais que podem gerar atrasos às atividades. Pode ser tentador fazer uma suposição otimista que as tarefas serão executadas exatamente de acordo com o plano (nas condições normais de temperatura e pressão, rs), mas sempre existe a possibilidade de haver contratempos, riscos.
Em resumo, a estimação de esforço está mais focada na quantidade de trabalho e recursos necessários para realizar uma atividade, enquanto a estimação de duração está voltada para o tempo necessário para concluir essa atividade de maneira geral. Ambas são essenciais para o desenvolvimento de um cronograma realista e eficaz, pois fornecem informações sobre como as atividades se encaixam no tempo e na capacidade da equipe e dos recursos disponíveis. Estimar tanto o esforço quanto a duração de forma precisa ajuda a garantir que o projeto seja concluído dentro do prazo e dos recursos planejados.
Mas então, como realizar estimativas reais de tarefas em um projeto ?
Levando em consideração uma abordagem mais tradicional, a resposta é: Faça as perguntas certas a quem executará a atividade. Busquemos nos comunicar cada vez melhor com nossos colegas que executarão as atividades, geralmente especialistas ou quem estiver atribuído diretamente à tarefa. Nossos colegas de equipe terão a compreensão mais realista sobre a quantidade de trabalho necessária para concluir uma tarefa e também conseguirão nos oferecer uma melhor estimativa levando em consideração os eventos e dependência que podem impactar na execução da atividade e, por consequência, estimações mais precisas. Fazer as perguntas certas nos trará as respostas que necessitamos para estimar uma atividade. Mais adiante daremos exemplos de abordagens para obter informações que proverão o que necessitamos.
Com as perguntas certas, ao invés de simplesmente perguntar quanto tempo se estima para determinada atividade, teremos a possibilidade de mapear subtarefas vinculadas às tarefas que requerem estimação. Subtarefas são tarefas menores necessárias para completar uma tarefa maior. Isso pode incluir, por exemplo, uma reunião com a equipe de Produtos, com a equipe de vendas para identificar os clientes, coletar informações de contato, determinar requisitos e criar um documento para armazenar essas informações. Este grupo de subtarefas podem compor as dependência até a criação de uma tarefa chamada Criar Plano de Negócio.
Pense nas conversas sobre a estimação de tempo como uma espécie de entrevista. Estamos nos conectando com os colegas de equipe para aprender mais sobre como eles trabalham em tarefas específicas e, por consequênca, usaremos essas informações para criar um cronograma. Para obter informações relevantes dessas conversas, convém ter certeza de fazer perguntas eficazes e abertas para que nos levem às respostas que procuramos. Uma pergunta aberta é aquela que não pode ser respondida com sim ou não. A resposta oferece os detalhes relevantes sobre o que você precisa saber. Vamos imaginar isso no contexto de um projeto para o lançamento de Portal Web. Estamos discutindo o design do site com o Web designer e queremos saber quanto tempo ele vai levar para fazer os testes de usabilidade do Portal Web.
Agora, imagine que comeceçamos a conversa fazendo uma pergunta como: “É possível terminar os testes em uma semana?”. Esta é uma pergunta fechada e pode gerar uma resposta como sim ou não, o que não diz muito sobre a tarefa de testar um site ou sobre o estilo de trabalho do colega de equipe, inclusive ajudá-lo a identificar pontos de atenção sobre a tarefa e suas dependências. Agora, imagine se tivéssemos iniciado essa conversa com uma pergunta aberta. Por exemplo, “Quanto tempo normalmente você leva para fazer um teste de usabilidade de um site como este?”. Estas são perguntas abertas e tem mais probabilidade de conseguir uma resposta mais detalhada.
A partir daí, faça mais perguntas para complementar a análise, como: “Qual a complexidade das etapas para concluir esta tarefa?”. “Quais são os riscos associados à atividade?” e: “Quando você acha que consegue terminar essa dependênca ?”. Ao fazer perguntas eficazes e abertas aos colegas de equipe sobre as tarefas atribuídas a eles, é possível aprender mais sobre como eles trabalham e o que fazem para concluir a atividade. Conforme geramos mais conversas assim, desenvolveremos um melhor senso das funções e tarefas dos colegas de equipe e podermos contar menos com a equipe para fazer estimativas precisas.
Negociando nas estimativas de atividades
Por vezes enfretamos barreiras para estimação que estão vinculadas não à complexidade da atividade, mas à disponibilidade do recursos que tem os skills necessários para completá-la. Por isso, uma outra maneira de conseguir estimativas de colegas de equipe é negociar com eficácia. Parte do nosso trabalho como gerentes de projetos é fazer a ponte entre as metas de alto nível do projeto e a perspectiva do dia a dia de nossa equipe.
O projeto pode ser nossa maior prioridade, mas é possível que as pessoas em nossa equipe do projeto também tenham prioridades neste projeto que conflitam com outras prioridades em outras equipes e projetos. Negociar de maneira eficaz pode nos ajudar a influenciar um integrante da equipe a viabilizar de alguma maneira as entregas que necessitamos, mesmo que ajustadas à realidade de quem executa, para isso é importante mostrá-lo que há possibilidade de realizar entregas com valor no projeto e em conformidade com os demais projetos em que esteja submetido. Por exemplo, vamos imaginar que o designer do site estima que levará duas semanas para fazer o teste de usabilidade do site. Mas nós esperávamos que a estimativa pudesse estar em torno de uma semana.
Para chegar a uma estimativa que funcione para nós e para o designer, conteste a estimativa de maneira gentil fazendo perguntas complementares, talvez perguntar se a estimativa dele inclui o teste para várias páginas seja um caminho. Neste caso, caso ele responda que sim, valeria à pena perguntar se o designer pode compartilhar uma ou duas páginas antes do prazo proposto. Fazendo perguntas certas, é possível determinar se a estimativa é flexível ou se nós precisaremos de mais um designer para ajudar a cumprir o cronograma.
Ao negociar de maneira eficaz com os colegas de equipe, é possível criar um senso de propriedade compartilhada sobre os resultados do projeto e criar um cronograma que se alinhe com a carga de trabalho de todos.
Estimativa de tarefas em projetos Ágeis - Pontos de História
A estimativa por Pontos de História é uma técnica utilizada em gerenciamento de projetos ágeis para estimar o tamanho relativo das atividades ou funcionalidades em um projeto. Essa técnica é geralmente é utilizado em metodologias como Scrum e Kanban. Ao invés de estimar o tempo real que uma atividade levará, estimamos a complexidade da atividade em relação a outras atividades, para isso utilizamos, geralmente, uma história como História de Referência. As demais histórias utilizam essa história de referência como base de comparação a nível de complexidade com as demais.
Um exemplo prático:
Imagine que estamos trabalhando em um projeto de desenvolvimento de um aplicativo para gerenciamento de tarefas de projetos àgeis. A equipe está se preparando para uma reunião de planejamento do Sprint e utilizaremos as estimativas com base em Pontos de História.
História de Referência: "Criar página de lista de tarefas"
Pontos de História: 5
Agora temos duas histórias adicionais para realizar a estimação:
História A: "Adicionar funcionalidade de marcação de prioridade às tarefas"
Esta funcionalidade é considerada um pouco mais complexa do que a história de referência.
Pontos de História estimados para a História A: 8
História B: "Implementar notificações por e-mail para prazos expirados"
Esta atividade envolve integração com um serviço de e-mail e é percebido pela equipe como um pouco mais complicada que a história de referência.
Pontos de História estimados para a História B: 7
História C: "Adicionar tema escuro ao aplicativo"
Essa tarefa é relativamente simples em comparação à história de referência.
Pontos de História estimados para a História C: 3
Neste exemplo, a equipe utilizou a história de referência como ponto de partida e comparou as histórias complementares com base ao entendimento sobre sua complexidade e chegou às estimativas relativas de Pontos de História para cada história.
Lembre-se de que as estimativas por Pontos de História são relativas e não representam uma unidade de medida absoluta. A ideia é comparar a complexidade das histórias em relação umas às outras, em vez de tentar estimar o tempo real necessário para cada atividade. Isso ajuda a equipe a priorizar e planejar suas iterações de maneira mais eficaz.
