O cenário em que é mais fácil estimar é se for um projeto do zero e que você já fez algumas vezes — isso é raro em uma empresa que não seja consultoria. O time quase sempre vai estar trabalhando em cima de código já existente, arrumando ou desenvolvendo novas funcionalidades em cima dele.
Frase comum: “no começo da empresa a gente desenvolvia muito mais rápido”
— Sim, não tinha uma base de código grande para mexer em cima, e todo mundo que estava lá tinha o contexto de tudo.
“Quase todos projetos de engenharia de software atrasam” Staff SWE do Instagram — não é só na sua empresa.
Isso significa que quanto maior e mais antigo o software (ie. quanto mais complexo), mais difícil de conhecer todas as regras explícitas e implícitas dele. Muita coisa você só vai descobrir fazendo e testando.
Quanto maior a qualidade do projeto (mais organizado o código, mais testes, etc), mais previsíveis são os efeitos das mudanças e mais segurança o time sente ao fazer alterações (menor a complexidade).
Quanto menor a qualidade, mais consequências indesejadas (ex: modificar um botão da página inicial e quebrar uma etapa do checkout), mais medo do time ao mexer no código, mais devagar (e estressante) fica o trabalho.
2. Quando o time muda, tudo muda
É difícil manter um time estável (sem sair ou entrar ninguém, sem mudar o escopo) por mais de 3~6 meses.
Cada mudança tem um custo invisível — ela reseta o estágio de desenvolvimento do time. As pessoas têm que se adaptar à nova dinâmica (nova distribuição de responsabilidades, treinar uma pessoa nova, conquistar confiança, adaptar comunicação, …).
Isso tem duas consequências práticas:
A mais óbvia é evitar fazer mudanças nos times
A menos óbvia é que se um projeto estiver atrasado, você não deve adicionar mais gente no time. Esse problema é conhecido como Lei de Brook: na verdade, adicionar alguém atrasa ainda mais o projeto.
Eu mesmo tive que errar algumas vezes pra acreditar que isso era verdade.
3. Quando a estimativa vira um prazo rigoroso, a situação piora
Para cumprir os prazos, o time vira conservador e aumenta muito as estimativas.
Com prazo mais conservador, mesmo se o time conseguisse fazer mais rápido a tendência é entregar no prazo combinado (raramente antes).
Lei de Parkinson —> a tarefa vai durar o quanto houver de prazo para ela
Lei de Hofstadter —> vai demorar mais do que o esperado, mesmo quando vc leva isso em consideração.
Essa é a pá de cal para se ter um time lento, conservador, que só diz “não”, assustado e na direção do burnout.
—> Aqui já dá pra ver um padrão perigoso, que leva pra uma espiral de lentidão e burnout:
Times que comprometem a qualidade do projeto além do que deveriam para entregar mais rápido, tornam o código cada vez mais complexo e assustador
O time fica mais lento, então a saída parece ser adicionar mais pessoas (às vezes isso vem junto com aumento de expectativas pelo time estar maior e mais caro)
O time fica ainda mais lento, então a pressão aumenta e o time compromete mais ainda a qualidade para conseguir entregar
Com o problema criado, aumenta a insatisfação com o time e mais cobrança por prazos
Vem a cobrança por trabalhar mais horas e um time já pressionado e com medo de mexer no código começa a entrar na zona crítica
Não necessariamente tudo isso acontece ao mesmo tempo, mas essas variáveis empurram nessa direção, principalmente em empresas que não tem cultura de tecnologia bem difundida pela organização.
Como sair disso, ou evitar que aconteça pra começo de conversa?
Primeiro de tudo, eu acredito (baseadoemdiversosautorese experiência própria) que os times de produtos digitais que mais entregam resultado são os:
Compostos por “missionários”, motivados pela missão da empresa
Responsáveis por entregar resultados de produto com autonomia, não projetos/features pré definidos
O time sendo responsabilizado (accountable) pelo resultado no período combinado (ex: OKRs trimestrais), as estimativas se tornam uma ferramenta fundamental pra ele mesmo conseguir se organizar. Idealmente elas deixam de ser uma cobrança externa por entrega e passam a ser uma cobrança interna do próprio time pra chegar nos resultados.
Mas o time não pode ser uma caixa preta que o resto da empresa só sabe o resultado esperado e a cada 3 meses o time reporta. Pelo contrário, na vida real o que o time constrói impacta os usuários, outros times e a estratégia da empresa. E para planejar comunicações, campanhas, suporte, operações, finanças, as estimativas são essenciais.
Então vamos falar de estimativas.
1. Previsibilidade tem tradeoffs — use sabendo o custo
Como exemplificado na Lei de Parkinson, para chegar no prazo o time abre mão de outras coisas. Pode ser de velocidade, pode ser de qualidade, pode ser de saúde física e mental.
Na Liv Up, a Tatiana Ottenio (que me substituiu como CTO) fez um modelo de 6 forças que competem entre si — para aumentar uma, alguma(s) tem que ceder.
A cobrança por estimativas mais precisas deve levar o custo disso em conta
2. Para ter previsibilidade, precisa ter consistência
Evitar mudanças nos times
Mudanças de pessoas (reseta o forming - storming - norming - performing)
Mudanças de última hora no backlog
Mudanças de ferramentas
Mudanças de regime de trabalho (remoto x presencial)
Mudanças da rotina (reuniões de última hora, notificações do slack, quebras de foco)
Não necessariamente o certo é não mudar nada.
O ponto é que cada mudança vai impactar na previsibilidade do time — tudo tem tradeoffs.
3. Definir a barra mínima de qualidade
Vimos que estimar software é difícil e que quanto mais velho e menor a qualidade mais difícil é. Então qualidade é um fator importante. O fundamental é ter o mínimobem definido e inegociável. Gosto da ideia de ter 3 níveis, para facilitar a tomada de decisão do time (mínimo, bom, máximo).
Alguma dívida técnica é fundamental sempre em uma startup.
Zero dívida técnica além de ser quase impossível (porque é impossível prever o que será o produto daqui a 1 ano) significa que o time está indo muito devagar. Mas esses tradeoffs são complexos de serem tomados no dia a dia, então ter os 3 níveis ajuda o time a saber onde mirar dependendo da sensibilidade, urgência e do grau de confiança da mudança.
Meu princípio básico para qualquer código em produção é ser (i) Fácil de entender por outra pessoa e (ii) Fácil de manter e mudar pelo time no futuro
Não quero entrar em padrões de código e princípios de engenharia mais detalhados. O ponto aqui é que precisa existir um mínimo. Se não o mínimo vai ser a bagunça, e ela é pior que o rotativo do cartão (porque além de predatória ela não tem um número simples e mensurável).
O livro Accelerate é muito bom nesse assunto e em amarrar princípios, ferramentas e práticas técnicas ao resultado e motivação da equipe
Manter o código com qualidade aumenta a consistência e a performance da equipe, diminui o medo e aumenta a velocidade média do time no longo prazo
4. Ativamente reduzir complexidade
A entropia só aumenta. Se o time não dedicar nada de energia ativa em reduzir complexidade dos sistemas (remover código antigo que não usa mais, remover teste A/B depois de finalizado o experimento, atualizar versão do banco de dados), o time vai ficar mais lento com o tempo.
A quantidade de tempo e energia dedicados a isso deve ser sempre conversada entre as lideranças de produto (PM, Tech Lead, Product Designer).
5. Estimando: Um dos principais tradeoffs é o tempo pra estimar
5.1 Se vc usar pontos pra estimar, fica ainda mais caro
Esse é um debate polêmico, mas eu não acredito em “pontuar estórias de usuário”. Talvez eu não saiba fazer e pode ser que funcione pra algumas empresas, mas o mais comum que vejo é times gastando horas estimando as tarefas da semana (já ouvi sobre planning de 2 dias para sprint de 2 semanas em que boa parte do tempo era discutindo se aquela era uma tarefa de 3 pontos ou 5 e argumentando).
As plannings têm valor, seja para discutir o produto, o discovery, as priorizações, ou para discutir a abordagem técnica, arquitetura, tradeoffs de qualidade.
Meu ponto é que elas não deveriam incluir a estimativa, caso esse seja um processo demorado.
Porque além de ser caro, é impreciso (por tudo que já falamos).
5.2 Abordagem estatística: sem custo extra para estimar
Estimar pelo histórico, buscando fazer as menores estórias de usuário possíveis é mais eficiente
A abordagem que usamos na Liv Up também foi proposta pela Tati Ottenio (sou fã mesmo) e é uma abordagem estatística.
Ela consiste em colocar mais energia em quebrar as estórias de usuário no menor tamanho possível de maneira vertical (que entregue o valor, e não por etapas de desenvolvimento). Esse é o coração da agilidade. Idealmente, fazer uma estória bem pequena e já deployar, entregando valor constantemente e aprendendo constantemente.
Se o time tiver dificuldades em estórias realmente pequenas (1~ dia), o exercício de Carpaccio de Elefante é bem bom
Com as estórias cortadas ao máximo, basta você acompanhar a velocity do time (quantas estórias por semana) e a partir disso estimar, com determinado grau de confiança, quando algo ficará pronto. No nosso caso, montamos um dashboard no Jira para cada squad que mostrava, dentre outras métricas, o lead time do squad com diferentes níveis de confiança (ex: com 95% de confiança podemos dizer que essas 9 estórias vão demorar 2 semanas. Tem 70% de chance de ficarem prontas em 10 dias).
“Ah, mas cada estória é diferente da outra”. Sim, mas se você usar pontos e olhar a média dos últimos meses, elas vão convergir. Se a equipe estiver quebrando bem e de maneira consistente as estórias, a consistência aumenta.
O time de Engenharia do NY Times também trabalha assim, e explicou como eles fazem nesse artigo.
6. Caso seja algo com muita incerteza, estimar fica mais caro: é necessário colocar a mão na massa para ter alguma confiança
Existem situações em que o time vai usar uma tecnologia nova, ou mexer em uma parte muito legada, ou fazer algo muito diferente do dia a dia, ou o time mudou e ainda não tem histórico ou está começando em um projeto que não era seu.
Nesses casos, usar as estórias passadas perde o valor estatístico ou nem é possível.
E a solução passa por colocar a mão no código, fazer um protótipo e conhecer melhor o desafio. Mesmo assim, a incerteza da estimativa vai ser mais alta do que o normal.
Eaí vale a reflexão: quão importante é estimar com precisão?
E retomamos todos os desafios e tradeoffs disso.
Sugestão: colocar mais energia em minimizar gargalos no fluxo de delivery
Em que parte do processo a estória fica mais tempo parada? Refinamento? Desenvolvimento? Code review?
Existem várias formas de gerenciar isso. Uma das principais é limitar WIP. Além de outros benefícios (como focar em terminar mais do que começar), quando se faz isso fica explícito onde o time fica parado aguardando.
Uma gestão ativa, que acompanha o dia a dia do board, remove impedimentos e realinha expectativas interna e externamente caso já se perceba um atraso em alguma entrega importante, gera um impacto enorme no resultado.
“Com uma gestão ativa, gerenciando os gargalos de perto, você percebe desvios no tempo médio em cada etapa e consegue corrigir a rota, antes mesmo do atraso acontecer.”
Tati Ottenio
Com os gargalos explícitos, o time pode investigar como remover eles (mudar algum processo? algo que a gestão pode ajudar? automatizar alguma parte do fluxo?) e com isso ganhar eficiência.
Um time com menos gargalos, é também um time naturalmente mais consistente → mais previsível → com estimativas mais precisas.
“Estimar é tentar prever o futuro e torcer pra dar certo.
Se você gerencia gargalos e desvios do esperado, você atua no presente e no futuro”
Tati Ottenio
Conclusão: Entender os tradeoffs e dificuldades, não abrir mão da qualidade, usar o passado para estimar
Como todas as decisões complexas, não existe uma resposta simples ou certa.
Minha expectativa com esse texto é explicitar alguns tradeoffs e desafios de estimar software, sugerir algumas soluções que aumentam a consistência dos times e compartilhar alguns materiais que me ajudaram a entender melhor (os links ao longo do texto).
Uma coisa que não aprofundei mas que é fundamental para lidar com isso tudo é gestão de expectativas.
Quanto melhor forem as habilidades de gestão de expectativas do time todo (pessoas Engs. de Software, Tech Leads, PMs, Designers, Eng. Managers, Heads de Produto, CTO, …), comunicando o estado atual do time, atualizando mudanças assim que surgem, dando transparência dos desafios, discutindo os tradeoffs, menos as estimativas/prazos vão ser um problema.
“Não trabalhamos com cronogramas” é a pior resposta que você pode dar.
Claro que gestão de expectativas é um tradeoff também. Quanto mais o time já estiver na espiral do atraso e com pressão, mais ele tem que fazer uma boa gestão de expectativas para reconquistar confiança (e menos tempo para isso ele tem). Mas isso dá outro textão e vai ficar pra outro dia.
Os times que liderei às vezes eram mais consistentes, às vezes não. Às vezes isso foi intencional (tradeoffs), às vezes entraram no caminho mudanças não intencionais na equipe ou no planejamento. Eu não sabia de metade do que escrevi aqui e aprendi com os erros meus e de pessoas mais experientes.
Espero que esse texto ajude. Caso você discorde de alguma coisa, tenha uma visão diferente ou outros links / livros / referências que possam contribuir pra discussão, adoraria te ouvir!
