#164 - Como fazer estimativas com Eduardo Matos

Resumo

Neste episódio, Eduardo Matos aborda o tema polêmico das estimativas no desenvolvimento de software. Ele começa explicando por que as estimativas são tão problemáticas, destacando que os seres humanos são naturalmente otimistas e tendem a errar frequentemente ao prever prazos. Uma distinção crucial é feita entre estimativa (uma aproximação) e prazo (uma data fixa a ser cumprida). Matos observa que, muitas vezes, as equipes estimam apenas o tempo de codificação, esquecendo-se de outras etapas como revisão, testes e deploy, o que leva a erros significativos.

O apresentador argumenta que, na maioria dos casos, as estimativas podem nem ser necessárias. Em vez de gastar tempo discutindo se uma tarefa vale 2 ou 3 story points, o foco deveria estar na priorização. Perguntar qual tarefa gera mais valor para o negócio é uma discussão muito mais relevante do que tentar acertar o tempo exato de entrega. Matos sugere que, quando há confiança entre as partes interessadas e a equipe de desenvolvimento, simplesmente não estimar pode ser a melhor abordagem, concentrando-se em fazer as tarefas na ordem de prioridade.

Para situações com prazos fixos inevitáveis, Matos propõe uma estratégia de negociação. A primeira camada é negociar o escopo: o que acontece se entregarmos 8 funcionalidades em vez de 10? Se não for possível reduzir o escopo, a próxima camada é negociar a arquitetura, optando por soluções mais simples que acelerem a entrega, mas com riscos técnicos. A terceira e mais arriscada camada é negociar a qualidade, como reduzir a cobertura de testes. Crucialmente, ele enfatiza que essas decisões devem ser tomadas em conjunto com o negócio, que arcará com as consequências.

Matos introduz técnicas práticas para lidar com estimativas quando são necessárias. Ele recomenda o uso do método MoSCoW (Must have, Should have, Could have, Won’t have) para priorizar funcionalidades quando há uma data limite. Para estimativas em si, ele sugere usar dados históricos e estatística para criar intervalos probabilísticos (ex: 75% das tarefas são concluídas em até 15 dias), em vez de datas exatas. Uma técnica simplificada proposta é categorizar tarefas apenas como “1” (cabe na sprint), “TFB” (Too Fucking Big - precisa ser quebrada) ou “NFC” (No Fucking Clue - precisa de mais estudo).

A solução de alto nível apresentada é focar em fazer entregas pequenas e frequentes. Isso resolve múltiplos problemas: reduz o risco de errar estimativas de tempo (tarefas pequenas são mais previsíveis), permite obter feedback rápido do cliente sobre o valor entregue e, mais importante, muda a discussão das partes interessadas de “quando isso estará pronto?” para “como priorizamos isso na fila?” Matos conclui que a melhor forma de lidar com a incerteza inerente ao desenvolvimento de software é focar na parte mais importante da tarefa mais importante para o cliente mais importante, entregando valor incremental o mais cedo possível.

Indicações

Concepts

Cost of Delay (Custo do Atraso) — Conceito discutido que tenta quantificar o valor perdido (em dinheiro ou oportunidade) por não entregar uma funcionalidade ou tarefa dentro de um determinado período.
CD3 (Cost of Delay Divided by Duration) — Métrica derivada do Cost of Delay, dividindo-o pela duração estimada da tarefa. Teoricamente usada para priorizar tarefas com maior valor por unidade de tempo, mas com a ressalva de que se baseia em estimativas incertas.

Frameworks

MoSCoW — Método de priorização mencionado para situações com prazos fixos. Categoriza tarefas em Must have (obrigatórias), Should have (deveria ter), Could have (poderia ter) e Won’t have (não faremos), ajudando a focar no essencial.

Workshops

Workshop sobre Estimativas da Escola Forja — Recomendado no final do episódio, é um workshop com mais de duas horas e meia de duração que aprofunda o tema de estimativas com conteúdo prático para aplicar no dia a dia. Pode ser acessado criando uma conta gratuita na Escola Forja.

Linha do Tempo

00:01:05 — Introdução ao problema das estimativas — Eduardo Matos apresenta o tema do episódio: estimativas no desenvolvimento de software. Ele explica que é um assunto polêmico porque os times frequentemente erram nas previsões de tempo de entrega. Um dos principais motivos é o otimismo exacerbado, mas não intencional, das pessoas ao estimar.
00:02:28 — Diferença entre estimativa e prazo — Usando a analogia do tempo para chegar ao aeroporto, Matos diferencia estimativa de prazo. A estimativa é uma aproximação (ex: “uns 40 minutos”), que varia com as condições. O prazo é uma data/horário fixo que deve ser cumprido. Ele alerta que, no dia a dia, as pessoas costumam tratar estimativas como prazos, o que gera cobranças problemáticas.
00:04:53 — Formas alternativas de estimar e seus problemas — São mencionadas formas de estimar como story points e T-shirt sizes (P, M, G), criadas para tentar uma abordagem mais relativa e reduzir vieses. No entanto, Matos observa que essas escalas também frequentemente falham em refletir a realidade. Um erro comum é estimar apenas o tempo de codificação, ignorando etapas como revisão, testes e deploy, que acumulam tempo.
00:08:48 — A sugestão radical: talvez não precisemos estimar — Matos propõe que, na maioria dos casos, talvez não seja necessário estimar. Ele critica as longas discussões sobre se uma tarefa é tamanho 2 ou 3 em story points, argumentando que a diferença prática no valor entregue é mínima. Em vez disso, ele defende que a priorização (discutir qual tarefa gera mais valor) é uma conversa muito mais importante e que geralmente não acontece.
00:13:08 — Estratégia para prazos fixos: negociar escopo, arquitetura e qualidade — Para situações com prazos fixos inevitáveis (como em fábricas de software), Matos propõe uma estratégia de negociação em camadas. Primeiro, negocia-se o escopo (entregar 8 funcionalidades em vez de 10). Se não for possível, negocia-se a arquitetura, optando por soluções mais simples que aceleram a entrega, mas com riscos técnicos. Por último, negocia-se a qualidade (ex: menos testes). Ele enfatiza que essas são decisões de negócio, não apenas técnicas.
00:19:50 — Método MoSCoW para priorização com prazo fixo — Apresenta o método MoSCoW como uma ferramenta para priorizar funcionalidades quando há uma data limite. As tarefas são categorizadas em: Must have (obrigatórias), Should have (deveria ter), Could have (poderia ter se der tempo) e Won’t have (não faremos). Isso ajuda a equipe a focar no essencial e a definir claramente o que não será feito.
00:23:26 — Usar estatística e histórico para estimativas quando necessário — Quando estimativas são inevitáveis, Matos sugere remover o viés humano usando matemática. A ideia é analisar o histórico de tempo de entrega (desde o início da codificação até a produção) de tarefas passadas. Com esses dados, pode-se fornecer um intervalo probabilístico (ex: ‘75% das tarefas semelhantes foram entregues em até 15 dias’). Estimativa deve ser vista como um range com probabilidade, não uma data exata.
00:25:52 — Técnica simplificada: TFB, NFC e Tamanho 1 — Propõe uma técnica de estimativa extremamente simples com apenas três categorias: Tamanho 1 (a tarefa cabe na sprint/iteração), TFB - Too Fucking Big (é grande demais e precisa ser quebrada em partes menores) e NFC - No Fucking Clue (não se tem ideia do tamanho, precisa de mais estudo/descoberta). O objetivo é que todas as tarefas eventualmente se tornem do ‘Tamanho 1’.
00:28:59 — Solução chave: entregas frequentes para focar na priorização — Matos apresenta a solução principal para o problema das estimativas: fazer entregas frequentes. Se um time entrega, por exemplo, 10 tarefas por semana, a discussão com as partes interessadas muda de ‘quando isso estará pronto?’ para ‘como priorizamos isso para entrar na próxima semana?‘. O foco se desloca da estimativa de tempo para a priorização de valor, que é onde deve estar.
00:30:25 — Estimativas como transferência de responsabilidade — Matos faz uma crítica contundente: em muitos casos, as estimativas são um artifício para transferir a responsabilidade do nível tático/estratégico (gestão, produto) para o nível operacional (desenvolvedores). Se as entregas frequentemente atrasam, o problema deve ser resolvido em um nível superior, não exigindo estimativas mais precisas dos desenvolvedores.
00:33:44 — Resolver erro de valor e tempo com entregas pequenas — Argumenta que, assim como desenvolvedores erram em estimativas de tempo, pessoas de produto/negócio erram em estimativas de valor. A solução para ambos os problemas é a mesma: fazer entregas pequenas. Isso permite obter feedback rápido do cliente, validar (ou invalidar) hipóteses de valor rapidamente e, ao mesmo tempo, elimina a necessidade de estimativas complexas para tarefas longas.
00:37:41 — Conceito de Cost of Delay e CD3 — Introduz o conceito de Cost of Delay (Custo do Atraso), que tenta quantificar o valor perdido por não entregar algo. Combinado com a duração estimada, forma-se a métrica CD3 (Cost of Delay Divided by Duration), que teoricamente ajuda a priorizar tarefas com maior valor por unidade de tempo. Matos alerta, porém, que isso ainda envolve estimativas incertas e que a melhor prática é focar em entregas pequenas da parte mais valiosa.
00:43:14 — Matos resume os principais pontos: 1) Humanos são péssimos em estimar. 2) Se não precisar, não estime - foque na priorização. 3) Faça entregas pequenas e frequentes para ganhar confiança e mudar o foco da discussão. 4) Corte o escopo primeiro, focando na parte mais importante da tarefa mais importante. 5) Se for estimar, use histórico e estatística, não intuição. — Resumo final e recomendações práticas

Dados do Episódio

Podcast: Tech Leadership Rocks
Autor: Eduardo Matos
Categoria: Technology
Publicado: 2023-11-26T17:06:32Z
Duração: 00:45:19

Referências

URL PocketCasts: https://pocketcasts.com/podcast/tech-leadership-rocks/2670a500-d4f6-0138-e77e-0acc26574db2/164-como-fazer-estimativas-com-eduardo-matos/cdeab4eb-be20-4114-8008-dcd7a8d03885
UUID Episódio: cdeab4eb-be20-4114-8008-dcd7a8d03885

Dados do Podcast

Nome: Tech Leadership Rocks
Tipo: episodic
Site: https://escolaforja.com.br/podcast/tech-leadership-rocks
UUID: 2670a500-d4f6-0138-e77e-0acc26574db2

Transcrição

[00:00:00] Fala, líder! Meu nome é Eduardo Matos e esse é o podcast Tech Leadership Rocks.

[00:00:14] Antes de começar, eu queria deixar um recado.

[00:00:17] Se você é líder na área de tecnologia, Tech Lead, Engineering Manager, Tech Manager,

[00:00:21] KIA Lead, DevOps Lead, etc., então eu quero te convidar a conhecer a nossa formação

[00:00:26] para líderes de tecnologia na Escola Forja.

[00:00:28] Lá a gente traz uma formação completa passando por assuntos como gestão de pessoas,

[00:00:32] agilidade, métricas, comunicação, arquitetura e muito mais.

[00:00:36] São treinamentos com aulas ao vivo, bastante interação com os colegas e conteúdos práticos

[00:00:40] para você aplicar no seu dia a dia e se destacar na sua empresa.

[00:00:43] Para conhecer, você só precisa visitar escolaforja.com.br.

[00:00:47] escolaforja.com.br.

[00:00:50] Recado dado, agora vamos partir para a conversa com o nosso convidado.

[00:00:54] Bom, vamos lá.

[00:00:55] A gente está aqui para mais um episódio do podcast Tech Leadership,

[00:00:58] dessa vez, enfim, num estilo um pouquinho diferente do que a gente costuma fazer.

[00:01:02] Então, nesse caso aqui, eu estou no monólogo, né?

[00:01:05] Eu vou falar aqui sobre estimativas, que é um assunto bem interessante e bastante polêmico, assim, na nossa área.

[00:01:10] Bom, vamos lá, então, né?

[00:01:12] Por que estimativas são um assunto tão polêmico?

[00:01:15] Basicamente porque existe muito erro, vamos dizer assim, na hora dos times,

[00:01:20] quando eu falo times aqui, estou falando Tech Leads, engenheiros, enfim,

[00:01:24] tem pessoas do time ali dando estimativas em relação ao tempo de entrega das tarefas.

[00:01:28] Então, se você, vamos dizer assim, faz parte da maioria, provavelmente, na sua equipe,

[00:01:33] seja na atual, em equipes passadas ou até em futuras, quando vocês dão estimativas,

[00:01:37] provavelmente, vocês erram bastante em relação a tempo de entrega.

[00:01:41] E por que isso acontece?

[00:01:43] Isso acontece por alguns motivos ali, tá?

[00:01:45] O primeiro, isso é bem comum, inclusive, é por conta de um otimismo exacerbado, tá?

[00:01:50] Mas não é aquele otimismo, vamos dizer assim, intencional.

[00:01:53] É mais um otimismo que acontece porque a gente é otimista quando vai dar qualquer tipo de estimativa.

[00:01:58] Daí, a gente costuma errar bastante em relação àquilo que a gente tinha estimado.

[00:02:02] E eu sei que estimativa e prazo são coisas diferentes, então a ideia da estimativa não é que a gente acerte na mosca,

[00:02:07] não é nada assim, porém, quando a gente dá uma data, enfim, um número ali,

[00:02:12] a pessoa, naturalmente, vai ficar esperando que seja alguma coisa em torno daquele número,

[00:02:16] ainda que não seja um prazo, que seja alguma coisa próxima daquilo, tá?

[00:02:19] E isso, normalmente, não acontece.

[00:02:21] Então, por isso que eu estou falando que acontece bastante erro quando a gente vai estimar, tá?

[00:02:25] Beleza.

[00:02:26] Aí, eu queria aproveitar para falar um pouquinho, também,

[00:02:28] sobre a diferença entre estimativa e prazo.

[00:02:31] Mas, para falar isso, eu queria trazer uma historinha bem rapidinha.

[00:02:34] Vamos dizer, por exemplo, que, sei lá, alguém me pergunte quanto tempo eu levo para sair de onde eu moro hoje até checar no aeroporto.

[00:02:42] Aí, eu posso chegar e falar, sei lá, eu levo uns 40 minutos, mais ou menos.

[00:02:47] Daí, a pessoa me pergunta assim, tá, mas se eu medir no cronômetro, você vai acertar de fato que são 40 minutos exatos?

[00:02:54] É isso mesmo?

[00:02:55] Provavelmente, não vai ser, tá?

[00:02:56] Então, esses 40 minutos que eu dei seriam uma estimativa baseada no local onde eu moro,

[00:03:01] baseado onde fica o aeroporto mais próximo.

[00:03:04] Pode depender muito do horário, também.

[00:03:06] Então, se eu sair de madrugada, então, eu chego mais rápido.

[00:03:08] Talvez, eu chego, sei lá, em meia hora.

[00:03:10] Se eu sair, sei lá, num horário de rush, provavelmente, eu vou levar uma hora e meia, não sei.

[00:03:14] Mas, enfim, acho que 40 minutos é um tempo razoável.

[00:03:17] Mas, o ponto é, esses 40 minutos, como não são exatos,

[00:03:21] é somente uma aproximação do que eu imagino que, enfim, do tempo que eu imagino que eu vou levar

[00:03:26] para chegar lá, mas não é um número no cronômetro.

[00:03:29] Agora, quando a gente fala de prazo, especificamente, aí sim.

[00:03:32] Prazo é algo que tem uma data, talvez até um horário ali, que é o que vai acontecer naquela data.

[00:03:38] Bom, então, prazo é uma coisa que a gente, invariavelmente, vai ter que cumprir, tá?

[00:03:42] Isso acontece.

[00:03:43] Nem todos os prazos são prazos, vamos dizer assim, realistas, mas, enfim,

[00:03:47] eu estou assumindo que prazo é algo que a gente precisa atingir enquanto estimativa é outra coisa.

[00:03:51] Basicamente, vamos dizer assim, é um número que a gente dá, é uma data que a gente dá,

[00:03:55] aproximada do tempo que a gente imagina que a gente vai levar para fazer alguma coisa, tá?

[00:03:59] Então, essa é a grande diferença aí entre os dois.

[00:04:02] Porém, o que aconteceu é o seguinte, até baseado no que eu falei ainda há pouco.

[00:04:06] Normalmente, quando a gente está dando estimativa, a gente erra muito por conta de otimismo,

[00:04:10] enfim, por conta de N razões aqui.

[00:04:13] E, justamente, para tentar tirar um pouco esse viés, esses erros que vêm acontecendo,

[00:04:18] como estimativas, naturalmente, eram dadas em, ou em horas, ou em dias, alguma coisa assim,

[00:04:22] surgiram outras formas de a gente estimar.

[00:04:25] Normalmente, as mais conhecidas, né, são por story points, ou até por, o pessoal chama aí, né,

[00:04:30] de t-shirt size, o tamanho de camisa, P, M, G, GG, PP, enfim, por aí vai.

[00:04:35] Então, essas são formas de tentar, vamos dizer assim, fazer a gente estimar de uma forma relativa

[00:04:40] para a gente ter mais ou menos uma noção de quanto de trabalho cabe naquela semana,

[00:04:45] enfim, naquela sprint de duas semanas, dependendo de qual for o tamanho da iteração da equipe.

[00:04:50] Então, essa é basicamente uma forma de tentar substituir uma coisa pela outra.

[00:04:53] Porém, se você já…

[00:04:55] usou, né, já estimou em story points ou em qualquer outro tipo de escala,

[00:04:59] provavelmente você percebeu que as escalas, elas também não batiam tanto com a realidade, tá?

[00:05:04] Enfim, aí, trazendo até um outro motivo pelo qual isso não acontece,

[00:05:08] além do otimismo que, normalmente, a gente tem,

[00:05:11] ainda que a gente tente ser, vamos dizer assim, um pouquinho mais científico nesse sentido,

[00:05:15] a gente cai ali no problema de, quando a gente faz a estimativa do tempo de entrega de uma tarefa,

[00:05:21] provavelmente, a gente está olhando somente para o tempo de codificação.

[00:05:25] Então, o tempo que eu vou parar, literalmente, codificar a tarefa e só.

[00:05:29] Esse é o tempo que eu consigo prever com uma certa facilidade,

[00:05:32] que é o tempo que eu imagino, ah, eu vou levar tanto tempo para escrever tal componente,

[00:05:36] vou ter que ver essa coisa, estudar um pouquinho sobre aquilo e tal,

[00:05:38] então, eu devo levar mais ou menos aí, sei lá, dois dias, três dias para conseguir finalizar isso aqui.

[00:05:42] Só que, no ciclo de desenvolvimento de software, a gente, normalmente, tem várias etapas,

[00:05:48] além da etapa de codificação. A codificação é uma das etapas.

[00:05:51] Então, se a gente estima somente a etapa de codificação,

[00:05:54] e esquece de todas as outras etapas, provavelmente, mesmo que a gente acerte muito certinho a estimativa,

[00:06:00] mesmo que chegue muito próximo, quando a gente somar com as outras etapas,

[00:06:03] provavelmente, o erro vai ser relativamente grande, tá?

[00:06:06] Então, estou falando aqui de etapas de revisão de código, de testes, enfim,

[00:06:10] de, enfim, deploy, depende de como funciona o deploy, o projeto,

[00:06:15] então, tudo isso vai acumulando tempo ali, para que, no total, seja, vamos dizer assim,

[00:06:19] vá muito além daquilo que a gente tinha estimado em relação ao tempo de codificação.

[00:06:23] Então, é importante a gente entender a diferença aqui, né?

[00:06:26] Normalmente, quando a gente estima, a gente estima tempo de codificação.

[00:06:29] Mas, quando a gente passa a levar outras coisas em consideração,

[00:06:32] o tempo de entrega fica muito maior do que, normalmente, a gente imaginava.

[00:06:36] Até porque, nessas outras etapas, a gente não está falando somente do tempo

[00:06:40] que a tarefa vai ficar, vamos dizer assim, vai levar para ser realizada a etapa em si.

[00:06:46] Então, por exemplo, o tempo que a gente vai levar para revisar não é só o tempo da pessoa,

[00:06:51] de alguma outra pessoa sentar, ler o código, ver se está legal, se não está legal,

[00:06:54] enfim, comentar, não é só esse tempo.

[00:06:56] Normalmente, até, é muito mais o tempo de espera entre uma coisa e outra acontecer

[00:07:00] do que, necessariamente, quando a pessoa está executando.

[00:07:03] Então, quando eu terminei de codificar, por exemplo, então, normalmente, a tarefa vai ficar,

[00:07:07] sei lá, algumas horas ali, talvez um dia, dois dias, dependendo do caso,

[00:07:11] parada, esperando alguém pegar aquela tarefa para poder revisar.

[00:07:15] E eu estou falando de revisão aqui, mas isso serve para qualquer outra etapa, tá?

[00:07:19] E, beleza.

[00:07:20] Quando a gente começa a levar isso em consideração, a gente percebe que, cara,

[00:07:23] ainda que eu dê estimativas, isso é mega problemático, porque é muito fácil de errar

[00:07:28] e, normalmente, no dia a dia, na maioria das empresas é assim, pelo menos,

[00:07:32] a gente, as pessoas encaram estimativas como prazo.

[00:07:36] Então, se você fala que você vai levar ali em torno de dois dias e já deu quatro dias

[00:07:41] e a tarefa não foi entregue, a pessoa, ela vai começar a te cobrar.

[00:07:44] Então, isso é super, super problemático, tá? Super problemático.

[00:07:47] Daí, uma, vamos dizer assim, um ponto que, normalmente, a galera traz,

[00:07:50] mas é, tá, beleza.

[00:07:51] Então, se eu aprender a estimar melhor, enfim, putz, eu consigo estimar isso aqui

[00:07:57] ou entregar mais próximo do que eu tinha estimado, beleza.

[00:08:01] Em tese, você até conseguiria, tá?

[00:08:03] E existem casos ali onde existe uma certa validade nisso.

[00:08:07] Por exemplo, se eu sou uma fábrica de software, eu vou construir o software para uma outra empresa,

[00:08:12] provavelmente, eu vou ter que combinar uma data ali onde as regras serão feitas, tá?

[00:08:16] Apesar de existirem formatos diferentes, esse é o mais tradicional, vamos dizer assim.

[00:08:19] Então, nesses casos de fábrica de software ou alguma coisa nesse sentido,

[00:08:23] quando eu contratei um terceiro para fazer para mim,

[00:08:25] então, datas, elas acabam tendo a sua importância ali,

[00:08:28] porque não existe uma relação de confiança, necessariamente, entre essas empresas.

[00:08:33] Então, eu preciso, de alguma forma, para poder cobrar aquele terceiro de que, enfim,

[00:08:38] aquela tarefa precisa estar pronta.

[00:08:39] E, normalmente, o prazo, ele serve para isso, tá?

[00:08:42] Porém, talvez esse seja o principal ponto que eu queria trazer aqui nesse episódio que, enfim,

[00:08:48] que a gente está discutindo sobre estimativos é que, na maioria dos casos,

[00:08:52] talvez a gente nem precise de estimativos, tá?

[00:08:54] Talvez a gente nem precise de estimativos.

[00:08:57] Então, eu vou dar um exemplo aqui.

[00:08:58] Eu trabalhei em várias equipes onde era muito comum a gente estar estimando as tarefas ali,

[00:09:04] normalmente em story points, daí chegava uma tarefa e alguém falava,

[00:09:07] ah, não, isso aqui para mim é uma tarefa de tamanho 2.

[00:09:10] Aí outra pessoa falava, não, para mim isso aqui é uma tarefa de tamanho 4,

[00:09:13] ou tamanho 3, alguma coisa assim.

[00:09:15] E a gente ficava discutindo, ali, não,

[00:09:18] mas é 3, é 2, é 3, é 2, e ficava nisso infinitamente.

[00:09:22] Cara, qual a diferença se a tarefa é 3 ou é 2?

[00:09:25] Não vai fazer diferença nenhuma no valor que aquela tarefa vai trazer.

[00:09:28] Se for levar mais tempo, de 3 em 2, cara, vai levar talvez algumas horas a mais.

[00:09:31] O que isso vai fazer de diferença dentro de uma sprint de 2 semanas, por exemplo?

[00:09:35] Normalmente não tem diferença nenhuma.

[00:09:37] Então, por que a gente está discutindo esse tipo de coisa?

[00:09:39] Quando a gente começa a estimar, seja em horas, pontos ou qualquer outro tipo de medida,

[00:09:43] naturalmente essas discussões, elas vão surgir,

[00:09:48] sem trazer nenhum ganho, necessariamente.

[00:09:50] Existe, talvez, um ganho que a gente possa ter com esse tipo de discussão?

[00:09:53] Talvez a minha percepção seja diferente da sua.

[00:09:55] Beleza, vamos conversar para entender como que a gente consegue resolver esse problema em específico.

[00:09:59] Então, talvez para isso, tá?

[00:10:01] Mas fora isso, enfim, não traz tanto ganho, assim, na hora da gente fazer estimação, tá?

[00:10:07] E eu diria que, talvez, vamos dizer assim, seja…

[00:10:12] Não vou dizer o segundo principal, mas, enfim, um ponto importante aqui,

[00:10:16] nesse episódio, que é eu querer trazer que a priorização das tarefas

[00:10:23] importa muito mais do que as estimativas.

[00:10:26] E, normalmente, a gente foca demais em estimar, senta junto com o time, discute com as pessoas,

[00:10:31] mas a gente não discute tanto assim priorização.

[00:10:34] Então, será que a tarefa que a gente está fazendo, ela é mais importante,

[00:10:39] gera mais valor do que uma outra tarefa que a gente deixou de fazer?

[00:10:43] Essa é uma discussão muito mais relevante, tá?

[00:10:45] Muito mais relevante e, normalmente, não surge,

[00:10:47] porque ela vem de uma pessoa, normalmente, que vem do negócio ali,

[00:10:50] um stakeholder, pode vir de um cliente, pode vir de Product Manager, enfim,

[00:10:54] alguma pessoa que está olhando mais para o lado do negócio

[00:10:57] e a gente simplesmente acredita que ela é mais importante e a gente vai lá e faz.

[00:11:01] E, na maioria dos casos, ela não vai entregar tanto valor assim quanto era esperado, tá?

[00:11:05] Então, priorização acaba sendo muito mais importante do que estimativa

[00:11:09] quando a gente pensa em, realmente, gerar impacto para o time, tá?

[00:11:13] Então, por isso, que é a minha solução, tá?

[00:11:14] Então, por isso, que é a minha solução, tá?

[00:11:15] Então, por isso, que é a minha solução, tá?

[00:11:16] Então, por isso, que é a minha solução, tá?

[00:11:17] Então, por isso, que é a minha solução, tá?

[00:11:18] Então, por isso, que é a minha solução, tá?

[00:11:19] Então, por isso, que é a minha solução, tá?

[00:11:20] Então, por isso, que é a minha solução, tá?

[00:11:21] Então, por isso, que é a minha solução, tá?

[00:11:22] Então, por isso, que é a minha solução, tá?

[00:11:23] Então, por isso, que é a minha solução, tá?

[00:11:24] Então, por isso, que é a minha solução, tá?

[00:11:25] Então, por isso, que é a minha solução, tá?

[00:11:26] Então, por isso, que é a minha solução, tá?

[00:11:27] Então, por isso, que é a minha solução, tá?

[00:11:28] uma tarefa que você estimula e que você vai levar dois dias para entregar aí você pode perguntar para

[00:11:33] pessoa de produto ali para os membros de stakeholder seja lá quem possa parte produto time em vez de

[00:11:39] entregar em dois dias se por acaso entregar em três que que vai acontecer nessa tarefa a gente

[00:11:44] vai ter um problema alguém vai reclamar o que vai acontecer se em vez de entregar em dois também três

[00:11:48] provavelmente está na maioria dos casos a pessoa não tem problema não eu só queria saber mais ou

[00:11:54] quatro você entregar então se você vai entregar em dois em três em quatro em cinco se não vai fazer

[00:11:59] muita diferença provavelmente você não precisa estimar tá talvez existe ali um problema de

[00:12:04] confiança porém eu acho que o ponto principal aqui é se vai levar mais tempo isso não vai fazer

[00:12:09] diferença nenhuma então estimativa também não faz muita diferença ali tá desde que a tarefa não seja

[00:12:14] lá muito grande desde que tem um certo nível de confiança entre pessoas de produtos pessoa é

[00:12:19] pessoas de desenvolvimento então aí não problema não é tão grande não tá então se você puder

[00:12:24] isso aqui é não 어때 simplesmente instime e essa a confiança que eu tô comentando é ela não é algo

[00:12:31] que ela aquele tipo de confiança que normalmente a gente imagina que essa era não tão a pessoa vim

[00:12:37] que confiam em mim se ela não confiar em mim a gente tá no ambiente onde não tem confiança isso

[00:12:41] errado que não a ideia não é essa a ideia você construir essa confiança então a pessoa o time

[00:12:48] ou seja lá quem for não vai confiar em você porque você tá falando que vai fazer o que a pessoa vai

[00:12:53] de sopr україн

[00:12:54] mostrando que você merece aquele tipo de confiança, tá?

[00:12:57] Então, ela vem muito mais da prática aqui

[00:12:59] e dos resultados que você traz

[00:13:01] do que necessariamente do que você fala, tá?

[00:13:03] Então, é desse tipo de confiança que eu estou falando, beleza?

[00:13:06] Então, você não precisa estimar minha sugestão.

[00:13:08] Não estime, tá?

[00:13:10] Segundo, quando tem um prazo fixo,

[00:13:12] porque, eventualmente, a gente vai trabalhar

[00:13:14] com tarefas que, de fato, têm prazo fixo,

[00:13:16] então, é um evento que vai acontecer,

[00:13:18] é um orçamento de um produto, alguma coisa assim,

[00:13:20] pô, beleza, então, o prazo, ele está ali, ele precisa acontecer.

[00:13:22] Então, nesse caso, você vai negociar o escopo da tarefa, tá?

[00:13:27] Então, você não vai, vamos dizer assim,

[00:13:29] ah, não, a gente tem esse escopo aqui,

[00:13:30] que são essas 10 funcionalidades,

[00:13:32] a gente tem que entregar essas 10 funcionalidades até a data tal.

[00:13:34] Nesse caso, a minha sugestão é, comece negociando o escopo.

[00:13:38] O que acontece, por exemplo,

[00:13:39] se você, em vez de entregar aquelas 10 funcionalidades,

[00:13:41] você entregar 8?

[00:13:43] O que de ruim vai acontecer?

[00:13:44] Qual a consequência disso aí?

[00:13:46] Se a consequência não for tão ruim assim,

[00:13:49] pô, beleza, então, talvez dê pra gente negociar aqui.

[00:13:51] A gente vai tentar entregar as 10,

[00:13:52] mas, se não der tempo, a gente vai entregar só 8.

[00:13:55] Se der tempo, a gente entrega até mais,

[00:13:57] entrega 12, entrega 15, não sei, quantas ideia ali.

[00:13:59] Mas, se você coloca o escopo como negociável,

[00:14:02] você abre espaço pro time não precisar, por exemplo,

[00:14:05] correr, trabalhar mais horas, enfim,

[00:14:07] fazer algo que não é tão legal fazer com frequência ali,

[00:14:11] por conta de uma, vamos dizer assim,

[00:14:12] um prazo que, às vezes, não era nem realista.

[00:14:14] Ainda tem isso, né?

[00:14:15] Alguns prazos, eles só são prazos

[00:14:17] porque alguém definiu uma data,

[00:14:18] mas sem nenhum motivo por trás disso.

[00:14:21] Só era uma data, realmente,

[00:14:22] enfim, tirada da cabeça de alguém, tá?

[00:14:24] Nesse caso, é pior ainda.

[00:14:25] Nesse caso, talvez, enfim, seja muito melhor nem ter prazo, né?

[00:14:28] Mas, vamos dizer que realmente tenha prazo?

[00:14:30] Você vai tentar negociar o escopo da tarefa.

[00:14:32] Então, o escopo, ele vai ser móvel,

[00:14:34] enquanto que o prazo, ele vai ser fixo.

[00:14:36] Então, você vai entregar tudo que der pra entregar

[00:14:38] dentro daquele prazo.

[00:14:40] E a minha sugestão aqui é você, primeiro,

[00:14:43] negocia o escopo, tá?

[00:14:45] Então, as funcionalidades ali, então, entregar 10, pô,

[00:14:48] vamos tentar entregar as 10.

[00:14:49] Se não der, cara, a gente finaliza ali onde é.

[00:14:51] A gente…

[00:14:52] Conseguiu fazer 7? Faz 7.

[00:14:54] Conseguiu fazer 6? Fez 6.

[00:14:55] Paciência, né?

[00:14:56] Então, o escopo, em primeiro lugar.

[00:14:58] Se você, porventura, não conseguir negociar o escopo,

[00:15:02] daí, vamos dizer assim, você vai pra uma segunda camada, tá?

[00:15:05] Aí, você começa a trazer um pouquinho mais de risco aqui.

[00:15:07] Então, você vai negociar, por exemplo, a arquitetura

[00:15:10] do que você está desenvolvendo.

[00:15:11] Então, vamos dizer que pra uma certa funcionalidade

[00:15:14] que você vai desenvolver,

[00:15:15] você desenhou uma arquitetura que vai dar um certo trabalhinho

[00:15:18] pra codificar aquilo, enfim, né?

[00:15:20] Só que esse trabalho,

[00:15:22] ele vai ser necessário pra que aquela, vamos dizer assim,

[00:15:24] aquela entrega, ela se adeque às necessidades do negócio.

[00:15:28] Então, se você tem que atender, sei lá, 100 clientes em simultâneo,

[00:15:31] 100 usuários em simultâneo, alguma coisa desse tipo,

[00:15:33] então, você vai desenhar uma arquitetura pra resolver daquele jeito.

[00:15:36] Só que, se você tem um prazo fixo

[00:15:38] e você precisa entregar N coisas e N funcionalidades,

[00:15:42] e pra você fazer isso, você precisa de uma certa arquitetura,

[00:15:44] mas essa arquitetura vai dar um pouco mais trabalho

[00:15:46] do que uma arquitetura mais simples,

[00:15:47] então, você pode trazer essa discussão pra pessoa de produto também.

[00:15:51] Olha só.

[00:15:52] Pra fazer do jeito correto, vamos dizer assim,

[00:15:54] pra atender a todas as necessidades de negócio,

[00:15:57] a gente vai desenhar essa arquitetura aqui.

[00:15:58] Só que corre o risco de a gente não conseguir entregar as 10 funcionalidades.

[00:16:02] Então, a gente tem que tomar, fazer uma escolha aqui,

[00:16:04] que é entre a escolha de a gente, vamos dizer assim,

[00:16:08] faz do jeito certinho e talvez não entregue tudo

[00:16:10] que a gente imaginava que deveria entregar, tá?

[00:16:13] Esse é um ponto, é uma possibilidade.

[00:16:15] E a outra possibilidade é a gente faz uma arquitetura mais simples,

[00:16:21] corre um pouco mais de risco aqui,

[00:16:23] de não atender as necessidades do negócio em termos de tecnologia,

[00:16:26] porém, a gente aumenta as chances de entregar mais rápido.

[00:16:29] E essa decisão não é uma decisão de tecnologia,

[00:16:32] essa é uma decisão de negócio.

[00:16:34] Então, a pessoa de produto que tá ali envolvida,

[00:16:37] ela precisa entrar nessa decisão,

[00:16:40] porque é ela que vai bancar o resultado bom ou ruim que aconteceu lá na ponta.

[00:16:43] Então, ela vai ajudar a tomar essa decisão.

[00:16:46] Então, agente de tecnologia, a gente coloca as cartas na mesa,

[00:16:49] coloca os riscos na mesa,

[00:16:50] e o negócio vai tomar a decisão dele.

[00:16:52] E se, porventura, o negócio sempre decidir ou recorrentemente decidir

[00:16:57] por sacrificar tecnologia para poder, enfim, entregar mais funcionalidade,

[00:17:02] o próprio negócio vai sofrer.

[00:17:03] Então, essa é uma carga que, na minha opinião,

[00:17:06] não deveria estar somente com as pessoas de tecnologia,

[00:17:09] até porque, em muitos casos, elas não são tomadores de decisão.

[00:17:12] Essa carga precisa ser compartilhada com o negócio

[00:17:15] e precisa até, na minha visão,

[00:17:17] estar mais do lado de negócio do que do lado de tecnologia.

[00:17:20] Então, na tecnologia, a gente coloca as cartas na mesa

[00:17:23] e ajuda a pessoa, que normalmente é uma tomadora de decisão do lado do negócio,

[00:17:27] a entender o risco que ela está correndo.

[00:17:29] Se ela estiver disposta a correr os riscos, beleza,

[00:17:31] é ela que vai pagar por conta daquilo.

[00:17:33] Seja porque a gente vai ter um legado muito grande daqui a um tempo,

[00:17:35] seja porque a qualidade vai ser menor, a gente vai ter mais bugs, enfim.

[00:17:39] Essa é uma decisão de negócio, tá?

[00:17:41] Então, essa não é uma decisão puramente de tecnologia.

[00:17:43] Por mais que a gente queira fazer tudo certinho,

[00:17:45] a gente tem que colocar na mesa as possibilidades e riscos que a gente tem,

[00:17:50] para poder tomar a melhor decisão para o negócio, tá?

[00:17:52] Então, se a gente não conseguir negociar escopo,

[00:17:55] a gente, enfim, parte para negociar parte da tecnologia ali.

[00:17:58] Até em último grau, se, vamos dizer assim,

[00:18:00] criar funcionalidades mais simples e tal do lado de tecnologia não for suficiente,

[00:18:04] daí a gente entra, vamos dizer assim, no local onde o risco aumenta bastante,

[00:18:09] mas pode fazer sentido pelo lado do negócio.

[00:18:11] É quando a gente começa a olhar para a qualidade.

[00:18:13] Então, cara, a gente vai fazer aqui a funcionalidade,

[00:18:15] talvez a gente não consiga testar todos os cenários.

[00:18:18] Talvez a gente, enfim,

[00:18:20] de testar uma parte aqui que talvez seja um pouco menos importante, não sei.

[00:18:23] A gente pode ganhar um pouco de tempo aqui,

[00:18:25] aumentando bastante o risco, inclusive aumentando o código

[00:18:30] que a gente vai ter que refatorar no futuro, vai precisar refatorar.

[00:18:33] Porém, a gente pode ter um ganho de curtíssimo prazo aqui.

[00:18:35] Então, a gente está disposto a tomar esse tipo de decisão?

[00:18:38] Sim ou não?

[00:18:39] E, de novo, essa aqui é uma decisão de negócio.

[00:18:41] Então, com a tecnologia, a gente coloca as cartas na mesa.

[00:18:44] A gente tem que entender as consequências daquilo que a gente está fazendo.

[00:18:48] Dado que a gente entende as consequências,

[00:18:50] a gente coloca na mesa, a pessoa do lado do negócio ali,

[00:18:52] ela vai ter que olhar aquilo, ela vai entender aquilo,

[00:18:54] vai ter que entender aquilo.

[00:18:56] Entender que não se trata somente de entregar mais funcionalidades.

[00:18:59] Não é assim que funciona, mas existe um risco também envolvido ali.

[00:19:03] É claro que aqui eu coloquei no nível de risco.

[00:19:05] Então, o que significa?

[00:19:06] Se a gente entregar menos funcionalidades ou funcionalidades mais simples,

[00:19:11] provavelmente o risco é menor.

[00:19:13] Mas quando a gente começa a entrar na tecnologia e a capar a tecnologia

[00:19:16] para poder priorizar funcionalidades,

[00:19:19] para fazer entrega de produto,

[00:19:20] provavelmente o risco vai aumentar bastante.

[00:19:23] E isso, enfim, essa decisão é de negócio.

[00:19:25] Acho que esse é o ponto mais importante aqui.

[00:19:27] Então, se a gente tiver prazo fixo,

[00:19:29] basicamente essas são, vamos dizer assim, as alternativas que a gente tem.

[00:19:34] Beleza.

[00:19:35] Aí, como é que a gente faz para priorizar aqui?

[00:19:37] Até olhando um pouquinho para a funcionalidade de novo,

[00:19:39] como é que a gente normalmente faz para priorizar funcionalidades?

[00:19:42] Assumindo que o nosso escopo é móvel.

[00:19:44] Existem várias formas de a gente priorizar,

[00:19:47] mas uma bastante conhecida é chamada de

[00:19:49] Moscow.

[00:19:50] Moscow com W no final.

[00:19:53] E o que significa Moscow?

[00:19:55] Significa a gente categorizar as tarefas em quatro categorias diferentes.

[00:19:59] A primeira categoria são os must haves.

[00:20:01] Então, a gente tem aquelas funcionalidades que a gente precisa entregar de qualquer jeito,

[00:20:05] não tem negociação, a gente precisa entregar aquilo.

[00:20:08] Uma série de funcionalidades vai cair nessa categoria.

[00:20:13] Algumas funcionalidades vão cair na segunda categoria, que é o should have.

[00:20:17] Ou seja, deveria ter.

[00:20:18] Tá?

[00:20:19] Não é obrigatório, mas, cara, a gente, vamos dizer assim, deveria trabalhar muito

[00:20:22] para tentar colocar elas em produção, enfim, até uma data fixa ali e tal.

[00:20:26] Então, a gente vai tentar trabalhar com elas da melhor maneira possível para que elas

[00:20:30] entrem em produção, mas não são obrigatórias, tá?

[00:20:32] Então, tem essa segunda categoria.

[00:20:34] A terceira categoria é o could have, tá?

[00:20:38] Could have, ou seja, poderia ter.

[00:20:40] Então, se a gente der tempo ali, a gente vai lá e, enfim, implementa, coloca na produção.

[00:20:45] Se não der, paciência, não deu tempo.

[00:20:47] Elas não são tão importantes.

[00:20:48] Elas não são tão importantes assim quanto as primeiras tarefas que a gente implementou,

[00:20:52] tá?

[00:20:53] Então, essa é a terceira categoria.

[00:20:54] E a quarta categoria é a categoria do won’t have, ou seja, a gente define claramente quais

[00:21:01] tarefas a gente não vai fazer, tá?

[00:21:04] Justamente para a gente não cair naquele erro de, ah, não, a gente tem que fazer tudo

[00:21:07] aqui, entregar tudo, backlog inteiro, papapá.

[00:21:09] Não.

[00:21:10] Quando a gente define claramente o que a gente não vai fazer, a gente abre mais espaço

[00:21:13] para focar naquilo que, de fato, é importante, que é entregar aquelas funcionalidades.

[00:21:18] Então, must have, se der, entrega should have e, enfim, tendo espaço ainda, a gente

[00:21:23] entrega aquelas que são could have, tá?

[00:21:25] Então, acho que essa é uma forma interessante de categorizar entregas quando a gente tem

[00:21:30] uma data fixa ali e a gente vai fazendo justamente nessa ordem que eu comentei aqui, tá?

[00:21:35] Então, é uma forma ali de priorizar que é bem interessante.

[00:21:38] E uma outra sugestão que eu dou aqui quando a gente tiver um prazo fixo é da gente se

[00:21:44] programar para conseguir fazer as entregas que a gente precisa fazer muito antes do final,

[00:21:46] tá?

[00:21:47] Porque se a gente, por exemplo, ah, não, a gente tem que entregar essa funcionalidade

[00:21:53] até o dia 1º de abril, pô, beleza, massa, aí você se programa ali para, codificando,

[00:21:59] você no dia 1º de abril, deployar aqui na produção, isso é um erro, tá?

[00:22:04] Provavelmente, se você fizer isso, você vai passar do tempo, porque existem, vamos

[00:22:07] dizer assim, coisas inesperadas que acontecem ali que vão dificultar da tarefa chegar em

[00:22:11] produção naquela data certinha que a gente tinha combinado.

[00:22:14] Então, a minha sugestão aqui é entrega antes do prazo.

[00:22:16] Muito antes do prazo, tá?

[00:22:18] Então, vamos dizer assim, se o tempo que você tem, vamos dizer, 30 dias para entregar

[00:22:22] uma tarefa, então você vai se programar para entregar em 60% desse tempo aí.

[00:22:27] Então, você vai se programar mais ou menos aí para entregar em 18 dias e não em 30.

[00:22:32] Esse tempo que sobrar aí é justamente o tempo de problemas que você vai ter, que

[00:22:35] você não esperava, talvez adaptações que você tem que fazer, talvez até você aprenda

[00:22:40] alguma coisa ali no meio do caminho que você consiga melhorar aquela entrega, por aí vai.

[00:22:43] Então, esse é o tempo de sobra aí que você vai colocar.

[00:22:45] Fazendo isso, você vai ter um tempo de sobra.

[00:22:46] A chance de você conseguir ter algo em produção na data certinha é muito maior.

[00:22:51] Então, você vai se programar para entregar antes e, se necessário, você vai reduzir

[00:22:55] o escopo da funcionalidade, você vai reduzir o escopo da arquitetura, enfim, aí entra

[00:23:00] toda a questão que eu já tinha comentado mais cedo.

[00:23:02] Então, quando a gente tem uma data fixa, a minha sugestão é que, enfim, a gente trabalhe

[00:23:08] dessa forma.

[00:23:09] E existem casos onde a gente, de fato, vai precisar estimar também.

[00:23:14] Então, em alguns casos específicos, talvez a gente trabalhe numa empresa onde a pessoa

[00:23:16] cobre bastante estimativas e tal, então a gente não tem muito jeito, a gente vai ter

[00:23:20] que estimar, tá?

[00:23:22] Nesse caso, a minha sugestão é tira o viés humano da coisa.

[00:23:26] O viés humano, que eu tinha comentado mais cedo, tende a ser muito otimista quando a gente

[00:23:30] vai fazer estimativas.

[00:23:31] E como é que a gente faz para tirar esse lado humano da coisa?

[00:23:35] Usa estatística, matemática.

[00:23:36] Você tira o ser humano da jogada e coloca a matemática no jogo.

[00:23:40] Para colocar a matemática no jogo, a gente vai ter que pegar o histórico das tarefas

[00:23:44] que a gente já fez.

[00:23:45] A gente vai analisar o tempo.

[00:23:46] A gente vai analisar o tempo que a gente levou para fazer, para, usando estatística,

[00:23:50] conseguir chegar, enfim, vamos dizer assim, num range razoável.

[00:23:53] Normalmente, a forma como a gente faz isso é a gente olha para o passado e das tarefas

[00:23:58] que a gente fez, a gente vê quanto tempo a gente levou de ponta a ponta para entregar

[00:24:02] uma tarefa.

[00:24:03] Desde que a gente começou a codificar até a gente, de fato, colocar essa tarefa em produção.

[00:24:06] Quanto tempo levou?

[00:24:07] Ah, uma levou dez dias, uma levou oito, outra levou dois, outra levou quinze, outra levou

[00:24:11] sete.

[00:24:12] Enfim, por aí vai.

[00:24:13] Fazendo isso, a gente consegue ter uma noção de, ah, beleza.

[00:24:16] Então, eu olhei aqui, sei lá, um histórico de cem tarefas, dessas cem tarefas, 75% delas

[00:24:22] a gente faz até quinze dias.

[00:24:23] Então, beleza.

[00:24:24] Esse é o tipo de estimativo que a gente consegue passar para o lado do negócio e falar, oh,

[00:24:29] olhando o histórico, a probabilidade de a gente entregar essa tarefa em até quinze

[00:24:34] dias é de 75%, ou é de 85%.

[00:24:37] Depende de onde você vai querer colocar a barra.

[00:24:40] Mas quando você coloca dessa forma, fica muito mais fácil da pessoa entender que existe

[00:24:44] um risco ali envolvido naquela estimativa.

[00:24:46] Porque o tempo para, de fato, você colocar aquilo em produção pode ser maior.

[00:24:51] Então, isso é uma parte bem importante.

[00:24:54] Estimativa não deve ser uma data.

[00:24:57] Estimativa é um range, é uma probabilidade daquilo acontecer.

[00:25:02] Porque existe um risco daquilo não acontecer.

[00:25:04] Beleza.

[00:25:05] Então, eu falei aqui um pouquinho de formas de a gente estimar ali, com o que a gente

[00:25:11] lida com prazo e tal.

[00:25:13] Agora, como é que a gente faz isso acontecer de uma forma mais simples?

[00:25:15] É, eu acho que é muito importante.

[00:25:16] É uma forma mais simples, tá?

[00:25:17] Normalmente, quando a gente está estimando lá, voltando até um pouquinho, estimando

[00:25:20] em story points, a gente tem uma graduação que varia bastante.

[00:25:25] Então, a gente tem ali 1 ponto, 2 pontos, 3 pontos, 5 pontos, 8, enfim, 13, 20, por

[00:25:31] aí vai.

[00:25:32] Como a gente varia muito, então a gente tende a caminhar bastante nessa escala aí.

[00:25:37] E a minha sugestão para que a gente tire, enfim, toda essa complexidade de fazer estimativa

[00:25:43] e tal, quando a gente precisar aqui.

[00:25:45] E que quando, porventura, histórico não for suficiente pra gente, enfim, que a gente

[00:25:50] use uma técnica que é muito simples, tá?

[00:25:52] Muito simples.

[00:25:53] Que é, são duas possíveis estimativas que a gente dá.

[00:25:56] É o TFB e o NFC, tá?

[00:25:59] TFB significa too fucking big, tá?

[00:26:02] Então é grande demais.

[00:26:03] E o NFC é no fucking clue, eu não faço ideia do tamanho dessa tarefa.

[00:26:07] Então…

[00:26:08] E 1, tá?

[00:26:09] Desculpa.

[00:26:10] Tem um terceiro que é 1.

[00:26:11] Ou a tarefa tem tamanho 1, ou ela é muito grande, ou eu não faço ideia.

[00:26:13] Quando ela tem tamanho 1, beleza.

[00:26:14] Ela pode entrar na nossa iteração, no nosso sprint, pra gente fazer.

[00:26:18] Show de bola.

[00:26:19] Quando ela é TFB, quando ela é grande demais, então a ideia é a gente pegar ela e quebrar

[00:26:24] em pedaços menores.

[00:26:25] Seja quebrar em funcionalidade, seja simplificar a arquitetura quando fizer sentido, enfim.

[00:26:29] A gente vai tentar entender como que a gente consegue simplificar essa tarefa.

[00:26:32] E o NFC, né?

[00:26:33] O no fucking clue, é quando a gente não faz ideia do tamanho daquilo, a gente tem

[00:26:37] que, enfim, fazer uma descoberta ainda, estudar alguma coisa pra poder ter uma noção melhor.

[00:26:42] Então a gente vai lá.

[00:26:43] A gente estuda melhor.

[00:26:44] Até que ela vai ter tamanho 1, tá?

[00:26:46] E quando eu digo que todas tem tamanho 1, a ideia não é que elas, vamos dizer assim,

[00:26:51] durem exatamente o mesmo tempo, mas é que elas sejam relativamente pequenas, vai.

[00:26:55] Então é uma tarefa que vai levar ali até uma semana.

[00:26:58] Acho que esse tamanho depende muito do contexto da equipe, tá?

[00:27:01] Mas a ideia aqui é a tarefa relativamente pequena.

[00:27:04] A gente consegue colocar numa sprint e entregar, por exemplo.

[00:27:07] Isso já deveria ser mais ou menos o suficiente.

[00:27:09] Se você conseguir reduzir bastante, as tarefas aqui, tamanho 1, elas têm até 3 dias.

[00:27:13] Se a gente não conseguir entregar uma tarefa em 3 dias, a gente vai ter que reduzir.

[00:27:16] Beleza.

[00:27:17] Só uma restrição interessante aí, mas a ideia é que ela seja relativamente pequena,

[00:27:22] tá?

[00:27:23] A ponto de que o tamanho dela não seja um problema pro time.

[00:27:26] Então se o time pega uma tarefa e passa 3 meses desenvolvendo, cara, aí claramente

[00:27:29] ela é muito grande.

[00:27:30] Agora, se o time passa 3 dias ou 4 dias desenvolvendo, talvez não seja tão relevante assim.

[00:27:35] Então a ideia é que ela seja pequena, tá?

[00:27:37] Então se, enfim, tiver que estimar ou saber se a tarefa entra ou não na sprint, alguma

[00:27:41] coisa assim.

[00:27:42] Então a ideia é essa regrinha, muito simples.

[00:27:44] Ou a tarefa cabe na sprint, ou você não faz ideia e vai ter que pesquisar ainda pra

[00:27:48] entender melhor o tamanho dela, ou é elegante demais e você vai ter que reduzir, tá?

[00:27:51] Só tem essas 3 possibilidades.

[00:27:52] E todas elas, no final, vão virar uma tarefa que tem tamanho 1 ou, entre aspas, que cabe

[00:27:57] na sprint ali, que a gente tá fazendo, tá?

[00:27:59] Acho que aqui é o ponto esse, né?

[00:28:01] Se for, enfim, estimar que a gente não precise da estimativa, né?

[00:28:05] Que de fato é colocar todas com tamanho 1, né?

[00:28:09] E se por um acaso você tiver no ambiente, ou que pede muito prazo?

[00:28:12] Que, por exemplo…

[00:28:12] É…

[00:28:13] É…

[00:28:14] É…

[00:28:14] Pô, quando você vai entregar isso, alguma coisa assim, a minha sugestão aqui

[00:28:18] pra você é que, assim, eu já trabalhei em ambiente assim, eu sei que é complexo,

[00:28:22] tá?

[00:28:22] Então a minha sugestão pra você é o seguinte, faça entregas frequentes.

[00:28:26] Nada vai conquistar mais as pessoas que estão no seu entorno do que você fazer entregas

[00:28:30] frequentes.

[00:28:31] Por que que isso acontece?

[00:28:33] Vamos dizer que hoje o seu time, ele entregue uma tarefa por semana, tá?

[00:28:37] Como ele entrega uma tarefa por semana, é difícil de saber pra qualquer tarefa nova

[00:28:41] que entre no backlog do time,

[00:28:43] em quanto tempo aquilo vai estar pronto?

[00:28:44] Porque tem um monte de prioridades

[00:28:45] e eu não sei se vai entrar uma outra prioridade depois.

[00:28:48] Então, é complexo.

[00:28:50] Então, naturalmente, as pessoas vão pedir uma data.

[00:28:53] Pô, quando isso aqui vai ficar pronto?

[00:28:54] Quando você consegue entregar isso?

[00:28:56] Para evitar isso, você vai fazer entregas frequentes.

[00:28:59] Então, vamos para um outro cenário aqui.

[00:29:00] Vamos imaginar que o seu time agora entregue

[00:29:02] 10 tarefas por sprint.

[00:29:04] Pô, você entrega 10 tarefas, vamos botar por semana aqui.

[00:29:06] O time entrega 10 tarefas por semana.

[00:29:08] A única coisa que a pessoa vai precisar se preocupar é

[00:29:11] eu vou conseguir colocar a minha tarefa

[00:29:13] nessa semana ou na semana que vem?

[00:29:15] Com quem eu tenho que falar para pedir

[00:29:17] para a pessoa priorizar a tarefa e jogar lá dentro

[00:29:19] da sprint do time ou da semana do time

[00:29:22] para que a tarefa seja feita nessa semana ou na semana que vem?

[00:29:25] Essa é a única discussão.

[00:29:26] Porque você tira o foco da estimativa

[00:29:29] e coloca o foco em onde é importante,

[00:29:31] que é na priorização.

[00:29:32] Então, desde que o time faça entregas frequentes,

[00:29:34] está sempre entregando um volume relativamente grande de tarefas,

[00:29:38] o foco passa para a priorização.

[00:29:39] Então, você tira essa coisa de estimativa

[00:29:41] do seu colo, logo de cara.

[00:29:42] Então, você, ó, pessoa de produto, PM,

[00:29:44] fulano quer tal coisa, combina lá com ele

[00:29:47] quando você consegue colocar isso aqui para a gente fazer.

[00:29:49] É só isso que a pessoa vai precisar fazer.

[00:29:51] Então, o foco precisa sair da estimativa

[00:29:54] e ir para a priorização, como eu comentei mais cedo.

[00:29:58] Beleza?

[00:29:59] E agora eu queria entrar num ponto que talvez seja

[00:30:02] um pouquinho mais sensível, vamos dizer assim.

[00:30:04] A gente vai falar um pouquinho mais de negócio aqui.

[00:30:07] Porque, normalmente, a estimativa está muito ligada

[00:30:09] à área de desenvolvimento ali.

[00:30:11] Engenheiros, enfim, pessoas que estão construindo, de fato,

[00:30:14] dão estimativas, mas, para mim, a coisa deveria ter

[00:30:17] um viés completamente diferente, tá?

[00:30:19] E eu vou dizer, enfim, uma frase aqui

[00:30:21] que talvez doa em algumas pessoas, tá?

[00:30:23] A frase é a seguinte.

[00:30:25] Em muitos casos, as estimativas são um artifício

[00:30:28] para transferir a responsabilidade

[00:30:30] do nível tático e estratégico para o nível operacional.

[00:30:34] Eu vou repetir que essa frase é importante.

[00:30:37] Estimativas são um artifício para transferir

[00:30:40] a responsabilidade do nível tático e estratégico

[00:30:43] para o nível operacional, tá?

[00:30:45] O que eu quero dizer com isso?

[00:30:47] A gente vê muito, eu já vi muito isso, pelo menos,

[00:30:50] de a gente estar ali no time trabalhando

[00:30:52] e ver aquelas cobranças.

[00:30:54] Pô, o time não consegue entregar no prazo,

[00:30:56] não consegue entregar na data, papapá.

[00:30:57] E isso acontece frequentemente.

[00:30:59] Porque, realmente, estimar é muito difícil.

[00:31:00] A gente vai errar muito, como eu comentei mais cedo.

[00:31:02] Então, é natural que isso aconteça.

[00:31:04] Só que, se isso acontece com uma certa frequência,

[00:31:07] se já tem uma expectativa de que as entregas não saiam

[00:31:09] na data,

[00:31:10] na data correta,

[00:31:11] então, provavelmente, eu vou precisar atuar

[00:31:13] no nível tático e estratégico,

[00:31:15] e não no nível operacional.

[00:31:17] Porque, claramente, o nível operacional

[00:31:18] não está conseguindo fazer isso funcionar.

[00:31:21] Eu não estou entrando no mérito,

[00:31:22] se as pessoas estão dando estimativas boas, ruins,

[00:31:24] se elas são boas ou não nisso, não interessa.

[00:31:26] Se a coisa não está funcionando no nível operacional,

[00:31:29] eu vou precisar subir um degrau,

[00:31:31] talvez dois, para a gente definir

[00:31:33] uma forma de lidar com isso.

[00:31:35] Porque, se eu não consigo confiar em algo

[00:31:36] que está acontecendo no nível operacional,

[00:31:37] eu preciso lidar com esse caso.

[00:31:40] De alguma forma, tá?

[00:31:41] E o ponto é,

[00:31:43] mesmo que a gente tente trabalhar

[00:31:44] e dar melhores estimativas e tal,

[00:31:46] dificilmente esse problema vai ser resolvido.

[00:31:47] Porque, senão, já teria sido resolvido há muito tempo.

[00:31:50] A gente já está nessa área há quanto tempo?

[00:31:51] Eu já estou, sei lá, 13 anos, 14 anos,

[00:31:54] não sei essa área,

[00:31:55] e desde que eu comecei, a gente tem esse problema.

[00:31:57] E eu imagino que ele vai perdurar por muito mais tempo.

[00:31:59] Então, o ser humano, ele continua errando demais.

[00:32:01] Então, a gente precisa lidar com isso,

[00:32:04] pelo menos no nível tático, tá?

[00:32:06] Talvez não no nível estratégico,

[00:32:07] mas pelo menos no nível tático,

[00:32:08] a gente vai precisar lidar com isso.

[00:32:10] Como que a gente consegue lidar com isso

[00:32:12] no nível tático barra estratégico?

[00:32:14] Aliás, depende muito de como a gente vai enxergar

[00:32:16] esse problema.

[00:32:18] A forma de lidar é a seguinte.

[00:32:20] Se eu não consigo confiar

[00:32:21] nas estimativas

[00:32:23] em relação à data que, de fato,

[00:32:26] as coisas são entregues,

[00:32:28] então eu vou precisar trabalhar

[00:32:30] de alguma forma para poder me proteger disso.

[00:32:32] Para que, vamos dizer assim,

[00:32:34] o grande objetivo

[00:32:36] que eu gostaria de alcançar no nível estratégico

[00:32:38] não seja impactado

[00:32:39] por um problema no nível operacional.

[00:32:41] Então, vou ter que abordar isso de alguma forma.

[00:32:43] Então, uma forma que eu sugiro aqui

[00:32:45] é de simplesmente, assim,

[00:32:47] dado histórico, inclusive,

[00:32:49] aceitar que a gente não vai dar boas estimativas,

[00:32:51] que a gente vai errar quando a gente der estimativas.

[00:32:53] E dado que a gente vai errar

[00:32:54] quando a gente dá estimativas,

[00:32:57] a forma da gente atuar com isso

[00:32:59] é olhando primeiro para valor, tá?

[00:33:01] Então, vamos esquecer um pouquinho,

[00:33:03] colocar estimativas um pouquinho de lado

[00:33:04] e vamos olhar para valor.

[00:33:06] Porque se a gente olhar, assim, de forma mais ampla,

[00:33:08] o que a gente vai ter é,

[00:33:09] para toda tarefa que a gente entrega,

[00:33:11] para tudo que a gente trabalha,

[00:33:12] a gente vai ter, vamos dizer assim,

[00:33:13] no eixo Y, a gente vai ter o valor

[00:33:16] que aquela tarefa hipoteticamente tem.

[00:33:19] Então, a gente imagina que ela vai gerar um certo valor

[00:33:21] e na horizontal a gente tem o tempo de entrega.

[00:33:24] Então, o que seria a estimativa, vamos dizer assim,

[00:33:26] o prazo, a data de entrega, alguma coisa assim.

[00:33:28] Então, quanto mais valor a tarefa tiver

[00:33:30] e quanto menos tempo eu levar para entregar, melhor.

[00:33:33] Então, normalmente, a gente olha muito

[00:33:35] para prazo, para estimativo,

[00:33:38] estimativo de tempo,

[00:33:39] a minha sugestão é que a gente olhe primeiro

[00:33:42] mais para valor.

[00:33:44] Então, a gente tem que entender que

[00:33:46] do mesmo jeito que a gente erra,

[00:33:48] que a gente erra em termos de prazo, entrega, data,

[00:33:50] esse tipo de coisa,

[00:33:51] a gente também vai errar muito em relação a valor.

[00:33:56] Então, a gente imaginava que tal tarefa

[00:33:58] ia gerar tal valor,

[00:33:59] que ia melhorar a vida do usuário,

[00:34:01] que ia aumentar, não sei quanto, o faturamento da empresa,

[00:34:03] mas quando a gente entrega,

[00:34:04] normalmente não é isso que acontece.

[00:34:06] Então, do mesmo jeito que desenvolvedores,

[00:34:08] enfim, engenheiros,

[00:34:09] eles erram bastante na estimativa de tempo,

[00:34:12] pessoas de produto, de negócio,

[00:34:14] também erram muito em estimativas de valor.

[00:34:16] Então, o erro está em ambos os lados.

[00:34:19] E como é que a gente faz

[00:34:19] para resolver ao mesmo tempo

[00:34:22] o valor, ou vamos dizer assim,

[00:34:24] esse problema de estimar errado o valor

[00:34:25] e o problema de estimar errado

[00:34:27] prazo, enfim, data, esse tipo de coisa?

[00:34:31] A gente resolve os dois da mesma forma,

[00:34:33] que é reduzindo o tamanho da entrega.

[00:34:36] Então, em vez da gente, por exemplo,

[00:34:38] passar três meses,

[00:34:39] desenvolvendo alguma coisa,

[00:34:41] e depois de descobrir que, putz,

[00:34:43] não era exatamente isso que o cliente precisava,

[00:34:45] vamos reduzir isso.

[00:34:46] Vamos entregar, talvez, um experimento,

[00:34:48] alguma coisa mais simples,

[00:34:50] eu não sei, mas alguma coisa que dê um cheiro melhor

[00:34:52] de se a gente está caminhando,

[00:34:54] em relação ao produto,

[00:34:55] na direção correta ou não.

[00:34:56] E quando a gente faz isso,

[00:34:57] a gente consegue ter feedback mais rápido

[00:34:59] do usuário, do cliente,

[00:35:01] e a partir desse feedback,

[00:35:02] a gente melhora o nosso produto.

[00:35:03] E repara que esse simples movimento

[00:35:05] de reduzir as entregas,

[00:35:07] de testar aquelas entregas de alguma forma,

[00:35:09] isso vai, vamos dizer assim,

[00:35:11] ajudar muito em termos de risco

[00:35:14] do valor de negócio,

[00:35:16] porque você leva, por exemplo,

[00:35:17] uma tarefa que eu ia levar três meses

[00:35:18] para entregar, uma funcionalidade,

[00:35:19] vou levar três meses.

[00:35:20] Se eu consigo, em uma semana,

[00:35:22] botar um experimento na rua

[00:35:23] para testar com o cliente

[00:35:24] se funcionou para ele, se não funcionou,

[00:35:26] se ele enxerga aquilo como algo de valor, se não,

[00:35:29] cara, em uma semana eu consigo tirar essa dúvida.

[00:35:31] Se eu consigo tirar essa dúvida,

[00:35:33] significa que,

[00:35:34] se aquilo não for útil para o cliente de alguma forma,

[00:35:36] eu, em uma semana, consigo tirar isso do caminho

[00:35:38] e tenho todo o restante do tempo,

[00:35:39] para trabalhar em alguma outra hipótese que eu tenho.

[00:35:41] Então, isso ajuda muito em termos de valor

[00:35:44] e, ao mesmo tempo, ajuda

[00:35:45] em relação à estimativa de tempo.

[00:35:47] Porque se eu vou fazer algo que leva mais ou menos

[00:35:50] uma semana, é aquele tipo de tarefa que eu não preciso estimar,

[00:35:52] porque ela é muito curtinha,

[00:35:54] muito pequenininha, eu não preciso estimar isso aí.

[00:35:56] Então, eu não perco nem tempo estimando isso.

[00:35:57] Eu simplesmente faço algo simples e entrego.

[00:36:00] Quando eu estou falando de algo simples aqui,

[00:36:01] eu não estou falando de algo que

[00:36:03] a tecnologia vai estar mal escrita.

[00:36:06] Não, você pode fazer um negócio bonitinho,

[00:36:08] pode fazer um experimento no Excel,

[00:36:09] um experimento, enfim, de informes.

[00:36:11] Existem, vamos dizer assim,

[00:36:13] frameworks para você fazer experimentos

[00:36:15] até que não incluem tecnologia.

[00:36:17] Mas, se incluir tecnologia, talvez você faça algo muito pequeno.

[00:36:20] Por exemplo, que você vai,

[00:36:21] em vez de ter que atender

[00:36:22] mil clientes em simultâneo, mil usuários em simultâneo,

[00:36:25] você vai atender ali dez usuários

[00:36:27] em simultâneo, porque você vai escolher

[00:36:29] alguns clientes para poder usar aquela nova funcionalidade.

[00:36:31] Então, a tecnologia desenvolvida

[00:36:33] vai poder ser muito mais simples, você vai fazer

[00:36:35] mais rápido, treinar mais rápido e extrair

[00:36:37] valor mais rápido daquilo, se funcionar.

[00:36:39] Beleza, você sabe que está no caminho certo,

[00:36:41] você vai evoluindo a partir do feedback

[00:36:43] dos clientes. Se não funcionar, se for algo

[00:36:45] muito ruim, você abandona e vai fazer outra coisa.

[00:36:47] Então, repara que esse simples movimento

[00:36:49] de encurtar

[00:36:51] o tamanho das tarefas

[00:36:53] vai resolver tanto para valor, quanto

[00:36:55] para estimativas.

[00:36:57] Então, essa é a forma que a gente

[00:36:59] resolve esse problema no nível,

[00:37:01] vamos dizer assim, vamos colocar no nível tático aqui.

[00:37:03] Você sai do nível operacional

[00:37:05] de ter que dar estimativas certinhas

[00:37:07] quando você vai entregar aquilo e joga isso

[00:37:09] no nível tático de, a melhor forma

[00:37:11] da gente executar isso é, vamos simplificar

[00:37:13] para a gente conseguir extrair

[00:37:15] valor disso mais rápido, aprender mais rápido

[00:37:17] se a gente está na direção

[00:37:19] correta, se não está, enfim, a gente resolve

[00:37:21] para os dois ao mesmo tempo.

[00:37:23] Então, esse que é um ponto bem interessante.

[00:37:26] Beleza, mas dito isso,

[00:37:28] eu queria trazer talvez uma forma

[00:37:29] talvez um pouco mais científica

[00:37:31] da coisa acontecer

[00:37:32] para dar um contraponto aqui também.

[00:37:35] Existe uma

[00:37:36] não vou dizer se é um fenômeno, mas um conceito.

[00:37:39] Vai, chamado cost of delay

[00:37:41] ou em português, custo de retardo.

[00:37:44] Apesar das pessoas não usarem muito

[00:37:45] esse termo em português.

[00:37:47] Ele basicamente fala que

[00:37:49] seja lá o que a gente vai fazer,

[00:37:51] existe um certo custo da gente não

[00:37:53] fazer aquilo. Então, se eu vou, por exemplo,

[00:37:56] desenvolver uma funcionalidade

[00:37:57] que vai, quando eu entregar essa funcionalidade,

[00:38:00] ela vai gerar um milhão de reais

[00:38:01] a mais por mês para a empresa,

[00:38:03] significa que o custo de não entregar

[00:38:05] essa tarefa é de um milhão de reais por mês.

[00:38:07] Porque é o dinheiro que eu perdi,

[00:38:09] ou que eu deixei de ganhar nesse caso,

[00:38:11] porque eu não entreguei aquela tarefa.

[00:38:12] E o mesmo serve para o caso de, por exemplo,

[00:38:15] se eu não entregar essa funcionalidade,

[00:38:17] eu vou ter uma multa aqui do governo,

[00:38:19] do Banco Central, seja lá de quem for.

[00:38:21] Então, sei lá, a multa é de 100 mil reais por semana.

[00:38:23] Para cada semana que eu não entregar.

[00:38:25] Tudo bem, então o custo de retardo é de 100 mil reais

[00:38:27] por semana, ou 400 mil reais por mês,

[00:38:29] aproximadamente, alguma coisa assim.

[00:38:31] Então, existe um certo, pelo menos teoricamente,

[00:38:33] um certo custo de quando a gente

[00:38:35] deixa de entregar alguma coisa.

[00:38:37] Então, essa é a parte que tenta quantificar

[00:38:39] valor, vamos dizer assim.

[00:38:41] Sempre que a gente conseguir medir isso,

[00:38:43] beleza, a gente vai lá e tenta medir.

[00:38:46] Isso vai dar uma noção melhor

[00:38:47] do que a gente deve priorizar,

[00:38:49] porque a gente vai ter uma visão mais clara

[00:38:51] do que gera mais valor do que outra coisa.

[00:38:53] Aí, beleza. Dado que a gente tem ali,

[00:38:56] vamos dizer assim,

[00:38:57] a estimativa de valor,

[00:38:59] a gente também pode ter, a estimativa, ou deveria ter,

[00:39:01] nesse caso, já que a gente está estimando valor,

[00:39:03] vamos estimar, enfim, tempo de entrega também.

[00:39:05] Então, a gente tem ali, tempo de entrega.

[00:39:07] E a partir da estimativa de valor,

[00:39:09] estimativa de tempo de entrega,

[00:39:11] surge uma nova métrica, vamos dizer assim,

[00:39:13] que é chamada de CD3.

[00:39:16] Que é Cost of Delay

[00:39:17] Divided by Duration.

[00:39:19] Então, é o custo de retardo

[00:39:21] dividido pelo tempo de duração.

[00:39:24] O que significa que,

[00:39:25] se eu dividir uma coisa pela outra,

[00:39:26] eu consigo ter um racional ali

[00:39:28] do que eu faria primeiro.

[00:39:30] Então, um exemplo aqui, hipotético também.

[00:39:33] Ah, tem uma funcionalidade que

[00:39:35] ela vai trazer um milhão de reais por mês,

[00:39:37] eu vou levar quatro meses para

[00:39:39] enfim, entregar essa tarefa.

[00:39:40] Então, beleza, ela vai ter um numerozinho lá.

[00:39:42] Então, um milhão dividido por quatro mil.

[00:39:45] Beleza.

[00:39:46] A outra tarefa que eu posso fazer,

[00:39:48] porque eu estou na dúvida, se priorizo tarefa A ou tarefa B,

[00:39:51] a tarefa B,

[00:39:53] ela vai me gerar

[00:39:53] duzentos mil reais por semana,

[00:39:57] porém, ela vai ser entregue

[00:39:59] em seis meses.

[00:40:00] Então, qual que eu faço? Faço uma ou faço a outra?

[00:40:02] Basicamente, a gente faz a divisão

[00:40:04] e a que tiver maior valor,

[00:40:06] a gente faz aquela tarefa primeiro.

[00:40:08] Porque, em tese,

[00:40:09] ela vai gerar mais valor ali, tá?

[00:40:12] Então, acho que esse é o ponto aqui para a gente,

[00:40:16] vamos dizer assim, tentar tornar

[00:40:18] essas estimativas,

[00:40:20] seja de valor entregue,

[00:40:22] seja de tempo,

[00:40:25] mas, vamos dizer assim,

[00:40:26] mais próximos da realidade ali.

[00:40:28] Porém, aí tem um super porém aqui

[00:40:30] que eu queria trazer.

[00:40:31] É o seguinte, a gente está colocando aí

[00:40:33] uma estimativa de valor

[00:40:35] e uma estimativa de tempo.

[00:40:37] Só que, se a gente é muito ruim em estimar,

[00:40:39] a probabilidade da gente errar

[00:40:41] também é muito grande, porque a gente está pegando

[00:40:43] algo incerto, dividido por algo incerto

[00:40:45] e está esperando, enfim, comparar coisas

[00:40:47] como se fossem, enfim, realidade.

[00:40:50] A grosso modo, talvez a gente até consiga

[00:40:51] usar esse tipo de pensamento.

[00:40:54] Então, talvez, se a gente estiver ali

[00:40:55] no nível estratégico, decidindo o que a gente vai fazer,

[00:40:57] esse tipo de estimativa

[00:40:59] pode fazer muito sentido, tá?

[00:41:01] Porém, o problema é que a gente está colocando

[00:41:03] estimativa com estimativa e fazendo

[00:41:05] matemática com isso. Então, a chance de estar errada é muito grande.

[00:41:07] E qual é a forma da gente

[00:41:09] lidar, enfim, da melhor maneira com isso?

[00:41:11] Dado que a gente pode estar tendo um erro muito grande

[00:41:13] ali na estimativa. É justamente fazer

[00:41:15] entrega pequena. Então, pegar essa tarefa que ia

[00:41:17] levar seis meses, por exemplo,

[00:41:19] em vez da gente levar seis meses para fazer

[00:41:21] essa tarefa, e se

[00:41:23] a gente, no primeiro mês,

[00:41:26] fizesse a parte mais importante dela

[00:41:27] ali e conseguisse gerar,

[00:41:29] sei lá, 60% do valor

[00:41:31] que a gente geraria dela

[00:41:33] como um todo? Então, vamos dizer que a gente vai ganhar um milhão de reais

[00:41:35] ali, talvez em um mês a gente consiga entregar

[00:41:37] um pedaço que vai gerar 600 mil reais

[00:41:40] por mês. Então, ao invés da gente levar seis meses

[00:41:42] desenvolvendo, a gente leva um mês

[00:41:43] desenvolvendo e já vai gerar um grande valor com aquilo.

[00:41:46] E depois a gente gera, sei lá, faz uma

[00:41:47] outra funcionalidade ali, um outro pedaço

[00:41:49] dessa funcionalidade, que vai gerar mais

[00:41:51] 200 mil reais por mês. E vai fazendo assim

[00:41:53] até a gente ou terminar, ou a gente

[00:41:55] decidir que, não, aqui já está bom o suficiente

[00:41:57] ou acho que o restante não faz mais sentido a gente

[00:41:59] continuar fazendo.

[00:42:02] Esse tipo de coisa pode acontecer.

[00:42:03] Então, a minha sugestão aqui é a seguinte.

[00:42:05] Você faz a parte mais importante,

[00:42:07] da tarefa mais importante, do

[00:42:09] cliente mais importante. Então, repara

[00:42:11] que você está super focando

[00:42:13] em alguma coisa muito pequenininha

[00:42:15] para gerar o máximo de valor possível.

[00:42:17] Você não está pensando mais numa tarefa que vai levar

[00:42:19] três, seis meses. Você está pensando

[00:42:21] numa tarefa que vai levar duas semanas,

[00:42:23] talvez um mês ali para você desenvolver.

[00:42:25] Mas é o pedaço mais importante que,

[00:42:27] pelo menos em tese, é que vai

[00:42:29] mais gerar valor ali.

[00:42:31] Então, você está deixando o negócio grandão de lado para fazer um negócio

[00:42:33] pequenininho e adiantar

[00:42:35] o valor que você só ganharia lá na frente.

[00:42:37] Então, em vez de usar toda essa matemática

[00:42:39] para fazer a coisa funcionar,

[00:42:41] foca simplesmente em você

[00:42:44] reduzir

[00:42:45] o tamanho da entrega, que vai resolver

[00:42:47] ao mesmo tempo a questão de valor,

[00:42:50] a estimativa de valor,

[00:42:51] a estimativa de tempo,

[00:42:53] e isso vai gerar valor mais cedo também.

[00:42:55] Então, essa é a minha grande sugestão aqui.

[00:42:57] Então, em vez de tentar trabalhar matemática aqui,

[00:42:59] estima aqui, vamos usar

[00:43:01] um monte de regra mirabolante

[00:43:03] aqui, um monte de frame,

[00:43:04] faz o que é mais importante,

[00:43:06] é a parte mais importante,

[00:43:08] a tarefa mais importante do cliente mais importante.

[00:43:10] Simples assim.

[00:43:12] Beleza. Então, resumindo tudo

[00:43:14] que eu trouxe aqui sobre estimativa.

[00:43:17] O ser humano é péssimo

[00:43:18] em estimar. Provavelmente, se você

[00:43:20] estiver estimando

[00:43:22] dentro da equipe, ou a equipe estiver estimando,

[00:43:24] o erro vai ser relativamente grande, pelo menos

[00:43:26] isso é o que acontece na maior parte dos carros.

[00:43:28] Então, isso é quase que dado.

[00:43:31] Se você não precisar,

[00:43:32] não estime. Simplesmente não estime.

[00:43:34] Você faz as tarefas na ordem

[00:43:36] mais prioritária para o lado do negócio.

[00:43:38] Ponto. Faça entregas pequenas,

[00:43:41] porque isso reduz tanto o risco

[00:43:43] do lado do valor, quanto o risco

[00:43:45] de erro no tempo de entrega

[00:43:47] ali. Além de você ganhar a confiança

[00:43:49] das pessoas que demandam

[00:43:50] para você. Então, quando o time vai te pedir

[00:43:52] alguma coisa, se você entrega 10 tarefas por semana,

[00:43:55] ele não vai mais perguntar quanto tempo você vai levar.

[00:43:56] Ele só vai querer que entre naquela semana.

[00:43:58] A discussão, vamos dizer assim, ela muda

[00:44:00] para o lado do negócio, o que é mais importante e o que não é.

[00:44:03] Então, faça entregas pequenas.

[00:44:05] Quarto,

[00:44:06] foque em cortar

[00:44:07] primeiro o escopo.

[00:44:10] Então, você vai focar

[00:44:11] na parte mais importante, na tarefa mais importante

[00:44:14] do cliente mais importante.

[00:44:15] Então, você foca ali em

[00:44:17] escopo. Isso é muito importante.

[00:44:20] E, para finalizar aqui,

[00:44:22] se você precisar estimar, usar matemática

[00:44:24] ali, histórico e tal,

[00:44:26] porque acontece, eventualmente a gente precisa

[00:44:28] fazer isso, a minha sugestão é

[00:44:30] usa estatística, olha para o histórico do time.

[00:44:32] Se necessário, categoriza tarefas

[00:44:34] grandes, separa, grandes e pequenas,

[00:44:36] são melhor, de como você vai fazer

[00:44:38] essa estimativa. Mas,

[00:44:40] usa histórico. Não tenta tirar isso da cabeça.

[00:44:42] Simplesmente, usa histórico, porque vai ser muito

[00:44:44] mais confiável do que você tirar isso da cabeça.

[00:44:47] E, se você quiser

[00:44:48] saber mais sobre esse assunto, enfim,

[00:44:50] sobre estimativas e tal, como é que a gente

[00:44:52] encara melhor isso, vou te recomendar

[00:44:54] aqui o workshop sobre estimativas,

[00:44:56] que tem lá na Escola Forja.

[00:44:58] Ele tem mais de duas horas e meia de duração,

[00:45:00] foi uma discussão bem legal, bastante conteúdo ali

[00:45:02] para você conseguir usar no seu dia a dia.

[00:45:05] E você pode criar uma conta de grátis,

[00:45:06] passa lá para você acessar o conteúdo, tá bom?

[00:45:08] Então, espero que você tenha curtido aqui,

[00:45:10] enfim, toda essa explanação sobre estimativas

[00:45:12] e tal. Se você quiser mais conteúdo

[00:45:14] desse tipo, é só me avisar, eu vou fazendo,

[00:45:16] tá bom? Então, um abraço aí e

[00:45:18] até mais.

Vox

Explorador