Não, é preciso menos esforço do que isso
(smartguess.is)- Quando alguém de fora da equipe de desenvolvimento pressiona para reduzir estimativas sem novos fatos, a estimativa passa a parecer negociável, prejudicando tanto a confiança quanto a qualidade do planejamento ágil
- A quantidade real de trabalho, na maioria dos casos, não pode ser reduzida livremente pela equipe de desenvolvimento; a equipe estima o esforço previsto com base na velocidade da equipe, em dados de histórias concluídas e na vazão atual
- Pular processos ou reduzir a qualidade para cumprir uma estimativa menor pode fazer o cronograma parecer mais curto no momento, mas tende a voltar depois com um custo maior
- Uma conversa mais produtiva não é “estime mais baixo”, e sim analisar juntos o orçamento, as partes que consomem mais tempo, as grandes incógnitas, alternativas, a divisão da história e a validação inicial
- Apenas reduzir números com um escopo funcional fixo cria expectativas erradas para o cliente sobre o prazo de entrega; é necessário discutir a remoção de funcionalidades de alto esforço e baixo valor
As distorções criadas pela pressão por estimativas sem novos fatos
- É comum que stakeholders de fora da equipe de desenvolvimento, com conhecimento técnico ou entendimento limitado da base de código, tentem reduzir estimativas dizendo: “Não, é preciso menos esforço do que isso”
- À primeira vista, parecem pedir uma “estimativa melhor”, mas muitas vezes o que realmente querem é uma estimativa mais baixa
- Quando estimativas são tratadas como números negociáveis, stakeholders e equipe de desenvolvimento chegam a um acordo que deixa ambos insatisfeitos, e o negócio passa a ter expectativas ruins sobre quando conseguirá entregar software aos clientes
- Como citação relacionada, há o link para Is tasking developers with creating detailed estimates a waste of money?
Estimar está mais perto de prever do que de controlar
- Há casos em que uma estimativa pode ser questionada
- Quando a equipe de desenvolvimento discute uma história internamente
- Quando há novos fatos que afetam a quantidade real de trabalho
- Um stakeholder externo que não entende os detalhes de implementação ou não fornece novas informações pedir uma estimativa menor é parecido com dizer a um meteorologista que “a previsão de amanhã está errada e o tempo vai melhorar”
- O meteorologista não controla o clima; ele faz previsões com base em conhecimento e dados observados
- A equipe de desenvolvimento também quase não controla a quantidade real de trabalho; ela estima o esforço previsto com base em conhecimento e dados
O que a equipe de desenvolvimento pode e não pode controlar
- A equipe de desenvolvimento estima usando a velocidade estabelecida da equipe, dados de revisão de histórias concluídas e processos que melhoram a cada sprint
- É possível pular partes do processo e entregar software de menor qualidade para tentar reduzir a quantidade de trabalho
- Não é a abordagem recomendada
- Muitas vezes isso resulta em custos maiores depois
- A equipe pode ter espaço para melhorar sua velocidade, mas, no momento da estimativa, deve usar como base a vazão atual, não a vazão futura esperada
- Se na empresa surgir uma conversa do tipo “é só trabalhar mais horas”, esse ambiente está perto de ser uma receita para o desastre
- Como relatos de experiências relacionadas, há três comentários no Reddit:
A conversa que se deve ter em vez de cortar números
- Desenvolvimento de software é complexo e, muitas vezes, leva mais tempo do que as pessoas imaginam
- Se o stakeholder entende que só pode gastar até certo valor, em vez de reduzir a estimativa, deve-se discutir o seguinte
- Quanto pode ser gasto nessa história
- Quais partes da história consomem mais tempo
- Onde estão as maiores incógnitas
- Quais alternativas existem para lidar com as partes demoradas e com as incógnitas
- Também é preciso avaliar opções que mudem a forma de validação e entrega
- Dividir a história e entregá-la em várias partes
- Validar cada parte o mais cedo possível
- Quando possível, validar com um protótipo
- Em especial, funcionalidades que exigem muito esforço mas têm o menor valor devem ser removidas da história, se houver uma forma de fazer isso
Tornando as perguntas sobre cronograma mais úteis
- Mais produtivo do que perguntar como reduzir a estimativa é fazer perguntas que esclareçam a relação entre funcionalidades, prazo e escopo
- Um texto separado traz as seguintes perguntas
- Quando é possível entregar a Feature A
- O que é possível entregar antes do fim do próximo trimestre
- É possível entregar a Feature A antes do fim do próximo trimestre
- Texto relacionado: converting story points to hours
2 comentários
Se você traduzir o título original do artigo com o DeepL, fica assim:
Tem alguém dizendo: 'Não, isso dá menos trabalho que isso aí!'?Comentários do Hacker News
A analogia de que “pressionar um vendedor a aumentar vendas/cotas é como exigir sol de um meteorologista” não parece tão injusta neste contexto
Na prática, está mais perto de pedir que ele trabalhe de forma mais eficaz para concluir o mesmo trabalho mais rápido
Se você pedir a vendedores que definam as próprias cotas, como há muita complexidade e incógnitas no fechamento de contratos, eles escolherão números que consigam atingir com segurança para não parecer que falharam
Mas esse número pode ficar abaixo do que o negócio precisa; por isso se apresenta uma cota mais alta e se faz com que tentem atingi-la, mesmo que seja um pouco puxado
Isso é ainda mais importante se a remuneração estiver diretamente ligada ao cumprimento desse número
Mas vendedores não ficam escrevendo textos dizendo que “cotas definidas por eles mesmos são sagradas, só vendedores devem defini-las, e a diretoria que exige desempenho acima disso é ignorante”
Uma analogia mais próxima seria a equipe de vendas dizer, sobre uma negociação específica, “70% de chance de fechamento, cerca de US$ 5 milhões em receita recorrente anual”, e a diretoria responder “dá para transformar isso em 80% e US$ 7 milhões?”
Pode até ser possível aumentar a chance de fechar e também o preço, mas, assim como concluir uma funcionalidade na metade do tempo, isso exigiria alguma grande mudança ou concessão em algum ponto
Mas, em vez de transformar estimativas em metas desejadas, é muito melhor terminar antes da estimativa
O ideal é ordenar o trabalho refletindo prioridades e pré-requisitos, garantir um volume suficiente de histórias prontas para desenvolvimento e, quando houver urgência, atribuir tickets de forma estratégica, aceitando o custo de longo prazo de concentrar capacidades da equipe
Se houver pressão de tempo, é preciso remover de todas as funcionalidades aquilo que é “bom ter” ou empurrar para o fim do backlog, e qualquer consulta a outras equipes ou especialistas externos deve ter limites de tempo rígidos
É preciso eliminar reuniões e interrupções desnecessárias, permitir que desenvolvedores recusem reuniões ou bloqueiem a agenda, e elevar o critério para refatoração ao que tenha relação custo-benefício clara antes do prazo, tratando isso como pegar emprestado do futuro
Só é preciso ter muito cuidado para não transformar esse modo em padrão de trabalho
Se você consegue converter 10% dos leads, quando precisa de 5 conversões em vez de 4, é mais ou menos uma questão de ligar para mais 10 pessoas
Uma comparação melhor com software seria construir um novo tipo de edifício, por exemplo uma casa em domo geodésico, sem experiência e sem conhecer bem os problemas que vai encontrar
Só que a situação é parecida com pedirem uma estimativa precisa e, depois, pressionarem para reduzi-la ainda mais
O mais importante é enganar clientes, e não estou falando simplesmente de “exageros comuns que são bons para a empresa”
É algo como fazer promessas que a empresa não consegue cumprir, ou vender funcionalidades futuras que exigem marchas da morte sacrificando qualidade e sustentabilidade
Mesmo que o nível C não veja isso, as consequências acontecem
Isso não significa que se deva acreditar cegamente nas estimativas dos desenvolvedores, mas esse é um buraco de coelho maior, e estou cansado demais para entrar nele agora
Só torna a compreensão do cronograma mais irrealista
É perfeitamente possível encontrar outras soluções criativas para resolver o mesmo problema, ou entender que escopo pode ser reduzido para atingir a meta
Mas isso é completamente diferente de dizer “faça exatamente a mesma coisa, só que mais rápido”
Quando o assunto é estimativa, muitas vezes os desenvolvedores quase nunca tentam se colocar no lugar do lado de negócios, nem procuram entender por que estimativas são necessárias e por que prazos mais curtos são sempre melhores do que prazos mais longos
Em vez disso, tentam proteger o santuário que é o desenvolvimento de software, aumentando ainda mais a distância entre engenheiros e “todo o resto”
Nesse momento aparecem cinismo e sarcasmo, e isso acaba levando a estimativas irrealistas
Já fui desenvolvedor, PO, gerente, diretor e CTO, mas ainda me surpreende como a maioria dos desenvolvedores está distante da realidade de entregar valor e do fator tempo
Como desenvolvedor, é até uma sorte ser perguntado quanto tempo algo vai levar e ter a oportunidade de explicar, contestar e defender sua estimativa
A triste realidade é que desenvolvedores muitas vezes são ruins em participar de conversas no nível do negócio e em expressar pensamentos, ideias, preocupações e sugestões para que PMs e gestores enxerguem a complexidade do trabalho e façam uma discussão saudável de custo/benefício
É preciso ver se o desenvolvedor líder participa das reuniões de negócios, se a equipe de desenvolvimento olha números e orçamento, participa do roadmap junto com o restante, e faz pesquisa com usuários e brainstorming de funcionalidades junto com o pessoal de negócios/UX
Caso contrário, é difícil esperar que desenvolvedores entendam o negócio
A separação entre desenvolvimento e negócio faz com que cada lado fique em seu silo esperando que outro especialista entenda bem o seu problema, e leva à sacralização do desenvolvimento de software
Muitas empresas apenas continuam funcionando apesar de papéis extremamente siloizados, mas, como o dinheiro continua entrando, parecem se iludir achando que esse jeito está bom
Normalmente é só alguém querendo colocar um número em um PowerPoint de política organizacional
Às vezes estão tentando decidir entre fazer A ou B e, nesse caso, o que se justifica não é uma estimativa absoluta, mas apenas uma estimativa relativa
De vez em quando existe um prazo real, mas aí o necessário também não é uma estimativa, e sim “conseguimos cumprir essa data?” ou, de forma mais útil, “o que precisamos fazer para cumprir essa data?”
Trabalhar o mais perto possível do negócio é bom, e o motivo de usar software, em primeiro lugar, geralmente é resolver uma necessidade de negócio
Mas, quando se trata de estimativas, muitas vezes eles estão de fato errados e nós estamos certos
Se mais curto é sempre melhor, então a partir de agora todas as estimativas podem ser de 1 dia; isso é melhor?
Se uma pessoa desenvolvedora consegue escrever código, estimar e entregar dentro do cronograma do negócio, essa pessoa não é funcionária: é fundadora
O que se quer são pessoas ingênuas que entreguem como fundadores, mas sem receber participação nos lucros
Por maior que seja o seu ou o meu esforço, o bebê não vai nascer mais rápido
Não há nada ambíguo nisso
A reclamação está na forma como a pergunta é feita, como se o desenvolvedor pudesse saber quando algo ficará pronto
A capacidade de alguém entregar valor rapidamente é separada da capacidade de estimar quanto tempo isso levará
É possível entregar muito valor mesmo errando completamente a estimativa
Se realmente existisse uma forma de estimar o tempo de trabalho em software, as empresas contratariam estimadores profissionais, assim como têm equipes de produto
Não haveria motivo para colocar isso nas costas dos desenvolvedores
Claro que outras pessoas também não conseguem, e os desenvolvedores pelo menos acertam o limite inferior, então continuam sendo importunados, mas o processo em si é obviamente tolo
Para dizer quanto tempo algo vai levar, seria preciso listar todas as etapas necessárias para fazê-lo, mas no desenvolvimento de software isso é impossível
Desenvolvedores conseguem fornecer um limite inferior para requisitos dados e, se nada inesperado acontecer, uma estimativa precisa até seria possível, mas em 95% a 98% dos projetos a estimativa acaba sendo menor do que a realidade
No fim, a “estimativa do desenvolvedor” vira uma medida de quanta folga o desenvolvedor quer colocar naquele projeto
Pedir estimativas enquadra a conversa de forma totalmente errada
A verdadeira pergunta deveria pedir a opinião do desenvolvedor sobre o problema que o negócio tem agora, o problema que talvez tenha daqui a 6 meses e a relação custo-benefício de resolver esse problema
Depois disso, deveriam ser tomadas decisões qualitativas voltadas a reduzir riscos
O melhor resultado de uma estimativa de software é todo mundo ignorá-la e esquecê-la; qualquer outro resultado destrói valor de negócio
Entendo o ponto, e o risco real também é grande em organizações com partes irresponsáveis
Mas a analogia com meteorologistas não é muito boa
O trabalho central de um meteorologista é prever o tempo, enquanto um desenvolvedor comum é alguém que trabalha nesse tempo, e tem relativamente menos experiência em previsões precisas
O que frustra, como stakeholder, são estimativas absurdas que nem começam no tempo de trabalho nem terminam em um prazo realista
Isso é especialmente verdadeiro no nível de microtarefas, quando é uma tarefa de no máximo 30 minutos que eu poderia fazer mais rápido se tivesse acesso, mas a estimativa que volta é de semanas
Mesmo quando isso gera um custo operacional sério e entra na categoria de “precisamos parar tudo para resolver”
Claro que uma tarefa de 30 minutos não leva realmente só 30 minutos por causa de testes e documentação, mas quanto mais a estimativa parece chutada, mais a relação de confiança é prejudicada
É diferente perguntar pelo tempo real de trabalho de uma tarefa específica ou pelo tempo decorrido de agora até o momento em que ela é implantada
Em quase todas as equipes, ambos são dominados pelo tempo em que o trabalho fica esperando alguma coisa, mas no segundo caso isso é especialmente grave
O tempo de digitação efetiva no teclado geralmente é quase um erro de arredondamento em comparação com coordenação e agendamento
Se a equipe não tiver investido em formas de trabalho contraintuitivas, o ticket médio passa esmagadoramente mais tempo esperando do que em trabalho real
Além disso, a equipe nem enxerga esse desequilíbrio e nem percebe que ele importa
Dá vontade de corrigir rápido e seguir em frente
O problema é que, sem implantação contínua totalmente automatizada, 30 minutos não são 30 minutos
Essa tarefa de 30 minutos precisa ser revisada para ver se não afeta outros departamentos, exige coordenação de agenda, comunicação e deploy, e pode envolver mais 2 ou 3 pessoas
Se for uma tarefa agendada, chega perto de 2 horas distribuídas entre várias pessoas; se for um hotfix ou ticket de suporte, quando existe um processo de QA além de testes automatizados, vira uma perda de produtividade de 4 a 6 horas
Se mais 6 pessoas pedirem “tarefas de 30 minutos” cujo impacto sobre outras pessoas da empresa não está claro, nada termina
Nossa equipe tem um fluxo de hotfix, mas precisa ser uma emergência de verdade, daquelas que paralisam a operação da empresa
Exceto em casos muito óbvios, a solicitação precisa vir de um chefe de departamento ou acima
O prejuízo de uma correção para uma pessoa criar problemas para várias outras, ou impedir a conclusão de um projeto grande estrategicamente importante, é muito maior do que o prejuízo de não tratar imediatamente todo ticket urgente
Deve haver alguma forma na organização de conceder o acesso necessário
Se a resposta for algo como “não é meu trabalho”, então essa organização valoriza uma estrutura de partes interconectadas com responsabilidades rígidas
Em uma organização assim, é natural que o custo de comunicação domine completamente o desempenho de entrega
Quando bem coordenada, a qualidade pode ser boa e, com funções claras, a vazão também pode ser alta, mas baixa latência nunca será obtida
O tempo de resposta é sacrificado em favor de outras coisas
Uma estimativa de 1 semana para uma tarefa trivial também é algo previsível em uma estrutura desse tipo
Com a agenda lotada, é provável que uma nova tarefa só seja atribuída semanas depois; se as responsabilidades fragmentadas exigirem duas ou mais pessoas, os tempos de espera vão se somando
Se isso não combina com o trabalho, então a própria organização não combina com esse trabalho
É ineficiente para todos os envolvidos
Nossa equipe tem bastante autonomia e ninguém fica contando horas ou medindo produtividade de fora, mas, quando é necessário, não há tempo para lapidar o código
Quando aparece uma tarefa de “30 minutos”, eu levo para a revisão da manhã e pergunto se, ao tocar naquele assunto, também devemos mexer em coisas adjacentes
Mesmo que não haja nada, eu reservo um dia; se for um projeto que conheço muito bem, reservo meio dia
Metade do dia vai para examinar o código, e a outra metade para atualizações como pequenos comentários, upgrades de versão, melhorias de código e mudanças em nomes de variáveis
Acho que é mais eficiente em termos de tempo pressionar contribuidores individuais a fazerem o mesmo
Um contribuidor individual recém-chegado aprende o código antigo com esse tempo e, no fim, desde que não faça grandes mudanças, os problemas legados também diminuem
A única varinha mágica no desenvolvimento de software é a simplificação de requisitos
Os requisitos estão sempre errados
São amplos demais, vagos demais ou baseados em premissas equivocadas
A habilidade realmente excepcional é descartar algumas premissas e propor uma solução simplificada
É a melhor e única forma de encurtar o cronograma
Quando os requisitos são simples, é mais fácil que sejam completos e precisos, mas os requisitos reais podem não ser passíveis de simplificação
Nesse caso, o necessário é uma especificação melhor
“They write the right stuff”, sobre o grupo de software do ônibus espacial, é basicamente uma história sobre fazer esse tipo de coisa: https://www.fastcompany.com/28121/they-write-right-stuff
A maioria dos bugs de software, na verdade, são bugs de requisitos, e, quando há bons requisitos, a velocidade de construir software fica absurdamente alta
Já vi um projeto sair de um repositório vazio para produção em 2 meses com requisitos totalmente claros e estáveis
Por outro lado, também já vi a implementação de uma funcionalidade de cerca de 30 linhas se arrastar por meses por causa de requisitos vagos e em constante mudança
Hoje há só algumas dezenas de itens, mas dizem que daqui a alguns anos serão milhares
O designer projeta todos os fluxos de busca com base em um documento de requisitos de produto de 20 páginas, e só depois que todo o planejamento e preparação terminam é que chamam a engenharia para escrever histórias e estimar o trabalho
Normalmente têm conhecimento de domínio suficiente e sabem o que é necessário para construir algo nesse contexto
Vale a pena discutir como mudar o escopo para alcançar um equilíbrio entre custo e benefício adequado aos stakeholders
Já vi casos em que desenvolvedores presumiam que seria necessário trabalho demais, e também casos em que não desenvolvedores ignoravam as partes essenciais que aumentavam o tempo
Às vezes se tenta criar uma solução generalizada, mas o que de fato é necessário pode ser alguém passar um dia sentado diante de uma planilha resolvendo aquilo
O problema de estimativas serem frequentemente questionadas por serem altas demais, mas quase nunca por serem baixas demais, é justamente o ponto que o planning poker tenta abordar
A ideia é que todos digam a dificuldade da tarefa sem serem influenciados uns pelos outros e, se as expectativas divergirem, discutam
É muito provável que alguém esteja deixando algo passar
O motivo de eu achar algo simples também pode ser porque deixei passar a parte complexa do problema, ou porque consigo enxergar uma solução mais limpa
Um bom exemplo é quando um cliente faz uma exigência impossível matemática ou fisicamente
Dá para passar o dia inteiro fazendo planning poker em torno desse desejo e ainda assim chegar a uma alternativa de compromisso impossível
Quando eu era freelancer, preferia ouvir uma explicação minuciosa do problema, se necessário observar por cima do ombro da pessoa que hoje o resolvia, sumir por alguns dias e depois voltar com o projeto que eu considerava a forma mais elegante e confiável de resolvê-lo
A menos que a pessoa tenha muita experiência com problemas complexos, a maioria consegue explicar bem seu problema, mas não propor a solução
Porque as soluções sempre tomam como modelo o conjunto limitado de coisas que a própria pessoa conhece
Na prática, já vi muitos requisitos estranhos criados por várias pessoas apenas empilhando suposições, sem que ninguém os tivesse pedido
Por exemplo, criar uma arquitetura de microsserviços infinitamente escalável e uma aplicação single-page completa só para permitir que doze usuários internos baixem dados em uma planilha do Excel
Ele pressupõe que a equipe esteja suficientemente familiarizada com todo o conjunto de funcionalidades e entenda como usar o sistema para lidar com a diferença inevitável entre A fazer em X e B fazer em X*3
Basta ver as discussões sobre Scrum mal conduzido para notar que essas premissas não são garantidas de forma alguma
Também não se considera que, por rotatividade e novas funcionalidades, a equipe pode sair dessas premissas a qualquer momento
Com frequência demais, todos apenas levantam as sobrancelhas uns para os outros e vira “X vai fazer, então a estimativa de X é o valor”, ou escolhem a média/o mínimo, prejudicando justamente quem estimou mais alto
Se for assim, nem sei por que fazer poker para começo de conversa
Isto é mais maquiavélico do que isso
O intermediário quer um acordo em que, se der cara, eu ganho; se der coroa, você perde
Ele quer obter vantagem apresentando um número baixo para convencer a contraparte do seu lado
Por isso usa todo tipo de técnica para fazer o desenvolvedor dizer o número que ele quer, mas sem parecer uma ordem ou coerção
Se parecer assim, esse número passa a ser dele, e o jogo desanda
Mas, quando inevitavelmente leva muito mais tempo, ele pode apontar para o número fornecido pelo desenvolvedor e dizer que só repassou o que ouviu, portanto não tem responsabilidade
A única linguagem que esse tipo entende é fazer com que o resultado de todo pedido de “revisão” de estimativa sempre suba, para mandar o recado
Primeiro, estimativas deveriam ser úteis para que o negócio se adapte, mas na prática não há adaptação nenhuma
O PM sofre pressão do chefe para terminar até uma data mais ou menos definida
Se, de qualquer forma, ninguém liga para minha estimativa, por que estimar?
Segundo, a equipe não tem incentivo para estimar de forma realista
Se acertar, ganha uma medalha? Na prática, todos os incentivos empurram para inflar a quantidade de trabalho por meio das estimativas
Terceiro, toda essa dança e ritual das estimativas não passa de algo que gestores adotam para parecerem mais eficazes e influentes do que realmente são
Quando eu era engenheiro, dizia com firmeza: “não há como fazer isso mais rápido, então não me pressione para obter o número que você quer ouvir”
Quando terminar, terminou; eu vou deixar sólido e em bom estado, então não me atrapalhe
Mas, como gestor, quando pressionei por uma estimativa menor, foi porque, pela realidade do negócio, o ponto crucial era entregar alguma coisa dentro do prazo definido
Mesmo que fosse preciso montar um castelo de cartas e cortar cantos, ao menos precisávamos sobreviver tempo suficiente para lidar com o problema depois
Naquele momento, da engenharia veio a resistência que eu mesmo provavelmente teria apresentado se estivesse naquela posição
Que era uma ideia terrível, que nos levaria ao fracasso no futuro e que era preciso fazer o trabalho braçal agora para evitar dor depois
Voltei a ser engenheiro, mas a experiência como gestor ajuda bastante ao lidar com esse tipo de lacuna
São pessoas que “vão até 11”
Como o amplificador do Spinal Tap, se você ajustar a potência máxima normal para 9, fica uma margem para subir mais um nível quando elas quiserem
É claro que isso faz você trabalhar mais devagar do que trabalharia originalmente
Mas, se querem um desenvolvedor que “vá até 11”, fica claro que só existe um jeito que funciona
Meu gerente e o gerente acima dele são exatamente assim: empurram prazos arbitrários não porque o cliente esteja esperando, mas para ficarem bem com o chefe deles
Quando a estimativa inevitavelmente falha, todos levantam as mãos e começam a colocar pessoas em planos de melhoria de desempenho por causa das estimativas ruins deles
Como engenheiro, o que se ganha vivendo sob esse estresse constante e perdendo até o tempo que se passaria com família e amigos?
Apenas fazer a estimativa incompetente do seu gerente parecer boa
Um dos truques antigos é criar uma visão, prometer algo e depois dizer: “eu fiz a minha parte, agora é só a engenharia fazer a dela”
Lembro de um gerente que acrescentava funcionalidades sem avisar enquanto estávamos finalizando um release, às vezes poucas horas antes
Ele até anexava funcionalidades a releases que já estavam concluídos
Na cabeça dele, parecia que bastava anexar a funcionalidade ao release e pronto
A maior dificuldade é que as pessoas pedem uma estimativa imediatamente quando o projeto tem só uma descrição de um parágrafo
Além disso, sempre dá a sensação de que “depende de quanta dívida técnica existe depois de olhar o código”
A única resposta razoável que dei até agora foi: “preciso de 1 a 2 dias para pressionar você a solidificar os requisitos e, antes de começar, pausar para auditar a base de código e procurar riscos”
Dá para fazer melhor do que isso?
O objetivo não é criar cards perfeitos, mas sim criar pelo menos um ticket para cada coisa que pareça precisar ser feita no projeto
Assim surgem vários cards de uma linha, como “criar endpoint de API para criação em lote” e “migrar dados da tabela existente para a nova tabela”
Se houver 5 cards ou mais, estimo com
((número de cards / número de desenvolvedores) * dias úteis estimados por card) + dias de férias previstosNão vai ser preciso, mas faz o PM e o chefe dele sentirem que a estimativa foi ponderada e razoável na época
Se depois for preciso adiar, fica fácil explicar: “presumimos que todos os cards teriam um número de dias parecido, mas estes dois foram outliers maiores do que o esperado”
É parecido com o processo normal de sprint, mas não é preciso acompanhar a velocidade da sprint além do feeling
A liderança da empresa pede estimativas com pouquíssima informação e, quando digo que preciso investigar mais e olhar a base de código, eles dizem que precisam de uma estimativa para decidir se “simplesmente” aprovam esse trabalho e se fazem o projeto
A conversa fica girando em círculos, até que acabo dando uma estimativa grande, porque ela inclui todas as incógnitas, inclusive coisas cujo escopo eu nem conheço
Aí, para a liderança, fica grande demais e caro demais
Em termos de Agile, isso é um ticket de spike de 3 pontos, e o resultado são requisitos detalhados, entregáveis e estimativas, junto com trade-offs considerados
É uma abordagem completamente normal
Dá para fornecer uma estimativa antes do spike, mas ela precisa vir com o máximo de ressalvas possível
Por exemplo, você pode dizer algo como “com 60% de confiança, menos de 3 semanas; com 80% de confiança, 5 semanas; com 90% de confiança, 6 semanas”
Em geral, recuso estimar prazos de entrega acima de 1 a 2 semanas e prefiro estimativas por partes sempre que possível
Por exemplo: “este projeto é composto de 7 entregáveis, cada um levando de 1 a 2 dias de trabalho”
Porque algo pode até representar 10 dias de trabalho de engenharia, mas o cálculo da data de entrega se torna praticamente sem sentido por motivos como mudança de prioridades
Se os “gestores” não entendem isso, infelizmente vai ser difícil ter paz
Não se preocupar com dívida e qualidade do código e entregar correndo algo que mal funciona
Aí eles ficarão satisfeitos
A cena típica de hacking em filme de ação é assim
Líder: “Quanto tempo para hackear o mainframe?”
Técnico: “O hacker adversário é muito bom, então no mínimo 2 horas”
Líder: “Você tem 1 hora. Faça acontecer”
Em seguida, eles saem voando por um sistema de arquivos 3D
Toda vez que vejo esse tipo de cena, coloco uma narração mental para o técnico
“A estimativa real era 20 minutos. Provavelmente termino em uns 50 e fico voando ocupado pelo sistema de arquivos 3D por mais 10 minutos para o líder não inventar moda”
Não é completamente verdade
Muitos recursos podem ser feitos em vários níveis, desde uma versão bem esquelética até uma versão totalmente banhada a ouro
Às vezes um colega desenvolvedor estima 2 semanas para uma funcionalidade que, na minha visão, levaria no máximo um dia, porque ele assumiu muitos recursos extras que não foram realmente pedidos, ou porque sabe de partes que eu não sabia que seriam necessárias
Quando pedirem para mudar uma estimativa, encare isso como um convite para discutir um pouco mais os requisitos e a implementação proposta
Pode existir uma solução muito mais simples que chegue a 90% do caminho e seja aceitável
Meteorologistas não têm essa opção
A diferença entre colocar um combobox/caixa de seleção básica e criar um elemento de UI customizado muito melhor para a situação não é bem comunicada para pessoas fora de TI
Dá para explicar com imagens, mas, como os stakeholders não veem nem tocam no produto, ainda não sabem o que está acontecendo
Por isso, em geral é preciso fazer algo funcionar de verdade e mostrar
Há clientes que dizem “faça da forma mais simples possível” e, quando você mostra uma GUI de protótipo, uma GUI com design finalizado e depois o protótipo, aprovam sem nem olhar os dois primeiros
Se pressionados, eles mexem no protótipo e ainda dizem “ótimo, vamos em frente”, mas depois, ao tocar no que está realmente funcionando no servidor de testes, dizem “não era isso que queríamos dizer”
Já vi isso desde lojinhas de casal com duas pessoas até empresas Fortune 500 em que um diretor regional e o CTO global davam opiniões
Isso é falando de front-end; back-end e DevOps são problemas totalmente diferentes, mas ali também há uma grande diferença entre fazer só o esqueleto e banhar a ouro
Agora já conheço esse jogo, então hoje em dia ganho bastante dinheiro com esse processo quebrado
Em 1975, Fred Brooks escreveu
“Leva 9 meses para ter um bebê, não importa quantas mulheres sejam alocadas”
Não há formulação melhor do que essa
https://en.wikipedia.org/wiki/The_Mythical_Man-Month
Cada pessoa a mais adicionada faz demorar mais
A entrega mais rápida é deixar um desenvolvedor solo trabalhar sem ser interrompido