Execução da modernização de arquitetura: em que momento a estimativa virou prazo?
(domainanalysis.io)- A modernização de software legado dificulta definir todo o escopo apenas com as informações visíveis antes do trabalho, por isso a estimativa inicial deve ser tratada como uma referência ajustável, não como um prazo fixo
- Como num reparo automotivo, no começo é possível fazer uma estimativa como US$ 18.000 e 30 dias, mas depois da desmontagem e inspeção podem aparecer danos ocultos, exigindo orçamento complementar e nova aprovação
- Em projetos de modernização também surgem complexidades ocultas, como falhas de integração ou comportamentos inesperados, e forçar o encaixe na estimativa original entra em conflito com a realidade
- Uma liderança saudável, em vez de perguntar “por que isso não foi visto antes?”, questiona a complexidade, as soluções, os trade-offs, os contornos possíveis e decide se deve continuar ou interromper
- Em contextos complexos, mais do que um manual de regras fixas, é preciso repetir ciclos de tentativa, experimento e descoberta, e o papel da liderança é criar um ambiente onde padrões possam emergir, em vez de impor controle excessivo
Estimativa não é prazo, é uma referência de andamento
- Em modernização de software complexa, tratar estimativas como prazos fechados entra em choque com a realidade revelada no trabalho real
- A estimativa inicial é feita com base nas informações visíveis externamente e na experiência, mas novas complexidades podem surgir depois que o trabalho começa
- “Estimativa” é uma aproximação do valor real, e em modernizações complexas é difícil prever perfeitamente todos os resultados antes do início
Analogia com reparo automotivo: danos invisíveis e orçamento complementar
- Em reparos automotivos, o perito do seguro primeiro envia à oficina uma estimativa de danos, e a oficina também envia sua própria estimativa à seguradora
- Como exemplo, o perito do seguro estima danos de US$ 15.000
- A oficina estima US$ 18.000 em danos e 30 dias de prazo de reparo
- O perito do seguro e os especialistas da oficina avaliam os danos em conjunto e, quando a seguradora aprova a nova estimativa, o reparo começa
- Durante o reparo, podem ser descobertos danos que não eram visíveis no início
- Ao desmontar peças, danos adicionais podem aparecer
- É possível inspecionar danos no unibody frame com uma máquina de alinhamento de chassi
- É preciso verificar não só o ponto de impacto, mas também se o efeito foi transmitido para a parte traseira da estrutura
- Se os danos adicionais exigirem mais US$ 20.000, a oficina envia uma solicitação complementar à seguradora, que então decide se continua com o reparo ou se trata o veículo como perda total (total loss)
- Recusar os US$ 20.000 adicionais apenas porque a estimativa original era de US$ 18.000 não corresponde a um processo de reparo realista
A complexidade oculta também aparece na modernização de legado
- A modernização de software legado pertence ao campo do software complexo
- É possível criar uma estimativa inicial com base em problemas que parecem claros externamente, mas na execução real surgem mais camadas de complexidade
- Assim como no reparo automotivo aparecem danos ocultos ou danos estruturais, na modernização também podem surgir problemas que não estavam na estimativa inicial
- Nessas situações, em vez de ficar preso à estimativa original, é preciso definir os próximos passos por meio de aprovação adicional e reavaliação
As perguntas que bons líderes fazem
- Em um ambiente saudável de desenvolvimento de software, quando um problema aparece, a reação não é procurar culpados, mas fazer perguntas necessárias para decidir
- Quão complexo é este problema?
- Quais são as formas de resolvê-lo?
- Quais são os trade-offs de cada abordagem?
- Existem contornos ou soluções alternativas?
- Em contrapartida, quando a conversa deriva para “por que essa complexidade não foi vista?”, “por que isso está demorando tanto?” ou “por que o prazo estimado original não foi cumprido?”, a equipe fica presa à estimativa original
- Em projetos de modernização, tanto continuar quanto interromper são possibilidades reais
- Se o custo complementar for aprovado, o projeto avança para a próxima etapa, repetindo esse processo até se aproximar da conclusão
- Se o custo superar o valor esperado, o projeto pode ser interrompido
- A decisão entre continuar e parar não é simples, e frameworks e workshops de tomada de decisão podem ser usados para definir a direção
A diferença entre contexto complicado e contexto complexo
- No Cynefin framework de A Leader’s Framework for Decision Making, reparo de automóveis ou manutenção de motocicletas pode estar mais próximo de um contexto complicado (complicated context)
- No reparo automotivo, especialistas ouvem o cenário do acidente e analisam ou testam vários fatores, como danos invisíveis ou danos estruturais, para decidir a melhor ação
- Em um contexto complexo (complex context), só é possível julgar o que está certo ou errado depois de tentar
- Uma integração que parecia que funcionaria pode falhar
- Pode ser necessário incorporar novos comportamentos antes desconhecidos que forem descobertos
- Na modernização de sistemas legados complexos, não existe um caminho fixo nem um manual a ser seguido
- Modernização é repetir o processo de tentar, experimentar, descobrir, resolver e seguir para a próxima parte
A bola curva não é exceção, é a realidade
- Se a modernização de aplicações está entre o complexo e o complicado, é preciso um painel de controle adequado para julgar o progresso e o sucesso
- Aplicar um processo simples de estimativa a um contexto complexo é como tentar resolver todos os parafusos e porcas com um martelo
- As mudanças inesperadas em projetos de modernização são a realidade
- Não é possível prever todos os resultados com antecedência
- Por mais análise prévia que seja feita, não se chega a um modelo de dados perfeito
- Há novo aprendizado em quase todas as etapas
- O modelo de dados precisa mudar de acordo com a complexidade descoberta
- Quando as estimativas mudam, em vez de reagir com raiva, culpa ou análises obcecadas em forçar o cronograma, é preciso encontrar uma forma de seguir em frente
Como a cultura organizacional lida com a bola curva
- O modelo de cultura organizacional de Ron Westrum distingue como a organização trata quem comunica mudanças inesperadas e como lida com falhas
- Organizações Power-Oriented atiram no mensageiro que anuncia a bola curva, e o fracasso leva à busca de bodes expiatórios
- Organizações Rule-Oriented ignoram o mensageiro que anuncia a bola curva, e tratam o fracasso como um problema de implementação da definição
- Organizações Performance-Oriented treinam o mensageiro que anuncia a bola curva, e transformam o fracasso em investigação
- Se o problema que se quer resolver continua relevante e atende às necessidades do negócio, é preciso avançar uma etapa de cada vez
- O alvo final do software que se quer modernizar é o usuário
Domínios complexos exigem gestão experimental
- Líderes que não reconhecem um domínio complexo podem ficar ansiosos quando os resultados esperados não aparecem rapidamente
- Em domínios complexos, a capacidade de tolerar falhas é importante, e a falha é um elemento essencial para o entendimento experimental
- Controlar demais a organização bloqueia a chance de padrões úteis emergirem
- Líderes que tentam impor ordem à força em um contexto complexo fracassam
- Líderes que preparam o palco, recuam um passo, deixam os padrões emergirem e avaliam quais padrões são desejáveis podem ter sucesso
1 comentários
Opiniões do Hacker News
Já passei por uma fase em que a liderança tratava estimativas como prazos, continuava mudando as especificações e, ainda assim, não queria nem ouvir por que elas poderiam mudar
Nessas horas, passei a adotar uma reação de “veado paralisado diante dos faróis” para qualquer coisa que não fosse trivial. Quando eu dizia: “Isso pode ser algo bem grande. Acho que alguém da equipe precisa passar mais ou menos uma hora olhando o que realmente será necessário”, o gerente invariavelmente perguntava por algo “mesmo que aproximado”. Então eu dava um número alto o suficiente para fazê-lo saltar da cadeira, e esse número ficava na memória. Depois de uma hora de diligência, eu evitava ao máximo dar qualquer número diferente daquele aproximado e, no fim, concluía “antes do previsto”, parecendo bem na fita
Com bons gestores, essa estratégia nunca foi necessária, o que era ótimo; mas, com pessoas que não tinham intenção de aprender as competências do próprio cargo, era assim que eu acabava respondendo. As reuniões também ficaram muito mais divertidas
A equipe de design, a de front-end, a de back-end e a de QA inflavam cada uma desse jeito; o gerente de projeto aumentava a soma novamente em 150% a 200%; e o gerente de contas e a equipe de vendas ainda acrescentavam outros 150% a 200% antes de calcular o custo
Como resultado, a manutenção de um site que uma equipe dedicada de 8 a 10 desenvolvedores web/full-stack decentes daria conta de tocar custava quase US$ 1 milhão por mês. Tirando o suporte 24 horas, acho que alguns bons desenvolvedores Rails ou Django, ou até uma pessoa com um designer gráfico em meio período, teriam resolvido
Alguns anos depois, o cliente percebeu a situação, e a direção da empresa estragou tudo de vez: cerca de 100 pessoas perderam o emprego e direitos não pagos. Naquele dia, eu também perdi cerca de US$ 26 mil
A capacidade total era, por exemplo, 40 pontos, e mudava um pouco quando alguém saía ou entrava na equipe. Velocity era a vazão média vista em pontos por pessoa/dia
Volatility era o quanto a sprint mudava. Remover um ticket de 5 pontos e colocar um de 3 e outro de 2 pode até ser aceitável, mas, se isso acontecer 12 vezes em uma sprint de duas semanas, a sprint não será concluída, mesmo que o total fique abaixo de 40 pontos
Tirávamos um snapshot diário da sprint para ver o volume de tickets adicionados e removidos, e conseguíamos mostrar aos gestores que, quando a volatilidade era baixa, quase sempre concluíamos; quando era alta, falhávamos independentemente de ter ultrapassado ou não a Velocity. O motivo é que não havia tempo para planejar direito e deixar os requisitos claros. Fazer o time de produto olhar para mais de duas semanas à frente ajudava em certa medida
Engenheiros que davam estimativas infladas demais para tarefas simples também tinham maior probabilidade de ser profissionais de baixo desempenho. Isso pode funcionar com pessoas que não julgam entregas lentas ou com gestores que não conhecem o contexto, mas gestores que conhecem percebem rapidamente
Em vez de um único valor fixo, é preciso dar também uma margem de erro, como “3 meses, ±4 semanas”. A maioria dos engenheiros sabe que suas estimativas têm margem de erro, mas, por algum motivo, foi condicionada a esquecer de dizer isso
Do ponto de vista de gestão, o tamanho da margem de erro também mostra imediatamente a confiança na estimativa e permite discutir riscos. Torna possível uma conversa como: “No momento temos 30% de erro para cada lado; quais são as principais causas e dá para investigar por alguns dias para reduzir uma ou duas delas?”
Não entendo como uma profissão de engenharia não consegue falar direito sobre risco, probabilidade e intervalos de confiança. Isso também não é responsabilidade apenas dos gestores
Dá para entender quando é um gestor inexperiente ou alguém cobrindo temporariamente a posição de outra pessoa, porque não estão acostumados à incerteza; fora isso, não há desculpa
O texto fala de projetos de modernização, e esse tipo de projeto tem prazos flexíveis, porque o software existente continua rodando enquanto o substituto é desenvolvido
Há pressão de orçamento, compromissos e expectativas dos usuários por novos recursos, mas não é uma catástrofe se o substituto atrasar um dia
Por outro lado, se você vai lançar uma sonda espacial e a posição dos planetas deixa de servir para a assistência gravitacional, a nave não chega ao destino. Se uma pequena fabricante de ferramentas, com US$ 100 milhões de receita anual, assina um contrato com a Ford para entregar até março moldes para a linha de produção da F150 2026, com multa de US$ 20 mil por minuto em caso de atraso, não dá para dizer em fevereiro: “Surgiu uma surpresa, não vai dar”. Só se deve assinar quando houver certeza de que é possível cumprir
A Ford ou a NASA não se surpreendem se a elaboração do orçamento custar dezenas de milhares de dólares. Elas entregam uma ECO e, mesmo que uma peça pareça algo que poderia ser feito à mão em 30 minutos, aceitam que sejam necessárias 3 semanas e US$ 8 mil, porque sabem que nisso estão incluídos o risco de prazo, etapas de aceite, etapas de inspeção, planos de contingência etc.
Mas, no grupo de modernização do OP, se alguém disser que “por termos informações incompletas, uma tarefa de 30 minutos para mudar o texto de um botão pode levar até 3 semanas e US$ 8 mil”, será posto para fora. Estimativas otimistas são recompensadas, estimativas pessimistas são reprimidas, e estimativas precisas deixam de importar. No fim, todos estão sempre atrasados e ninguém fica muito surpreso
Isso pode incluir manutenção para mudanças de hardware, upgrades de sistema operacional e novos recursos. Já vi projetos rodando em paralelo assim por mais de 10 anos
Em 1505, Michelangelo estimou que levaria 5 anos para concluir o túmulo do Pope Julius II
Na prática, levou cerca de 40 anos por causa de pequenos trabalhos paralelos, como o teto da Sistine Chapel
Como o prazo baseado na estimativa não foi cumprido, o escopo do projeto foi bastante reduzido. Isso aconteceu porque Pope Julius II morreu antes da conclusão, houve pedidos de mudança do cliente Julius e de seus herdeiros, problemas na cadeia de suprimentos, renegociação de contratos, disputas trabalhistas, falta de mão de obra qualificada e esgotamento dos recursos devido à longa duração
Então, pelo menos desde 1505, esse tipo de coisa já acontecia. O curioso é que o papa nem está enterrado naquele túmulo
Aprendi algo importante no começo da carreira. O primeiro número apresentado é o que fica na memória
Infelizmente, na prática isso acontece com frequência, e as pessoas continuam dizendo: “você não tinha dito X no começo?”. “Sim, mas obtivemos novas informações” nem sempre funciona
Quem sabe disso acaba evitando apresentar números, o que também gera um efeito colateral
Scotty: “Claro, capitão. É assim que mantenho minha reputação de fazedor de milagres”
Por exemplo, dia→semana, semana→mês, mês→trimestre. Se algo levaria um dia, digo 3 semanas. Parece muito, mas no fim, por causa de burocracia, processos e dívida técnica, geralmente acaba ficando por aí
Há um trecho que diz: “Você consegue imaginar uma seguradora discutindo com a oficina que o orçamento original era de US$ 18.000, então ela não pagará os US$ 20.000 adicionais? Absurdo, não? Eu também acho. Felizmente, a realidade não funciona assim”, mas em seguros isso acontece o tempo todo
Vale não só para seguro de automóvel e residencial, mas também para seguro-saúde. Muitas vezes se negocia até um ponto razoável, mas nem sempre; o tom confiante de “a realidade não funciona assim” é surpreendente
A perda total pode sair mais cara, mas o teto fica claro e a indenização pode ser encerrada. Seguradoras detestam sinistros em aberto
Esta última, também chamada de “tarifa preferencial” no seguro automotivo, é um contrato amplo em que determinados tipos de serviço são cobrados por uma tarifa fixa negociada
Isso é muito diferente de um orçamento vinculante. Um orçamento vinculante normalmente é uma cotação pontual para um trabalho específico, em que quem estima assume o risco e promete concluir naquela tarifa mesmo que o trabalho seja muito mais complexo do que o esperado
Um truque, sempre que possível, é estimar apenas um escopo fixo e excluir os desconhecidos que não podem ser conhecidos
Não estime “implementar o recurso X”; estime “motor do recurso X”. Se descobrir trabalho adicional, acrescente como marcos descobertos, como “refatoração do código existente” ou “integração dos recursos X+Y”
Mas essa nomenclatura e esse entendimento precisam subir na hierarquia para funcionar. Se alguém trocar o marco “motor do recurso X” por “recurso X concluído” mantendo a mesma estimativa, deu ruim
Também vi um problema relacionado: lideranças que acham que prazos são “motivação”. É como pessoas que querem aquecer a casa a 72F, mas ajustam o termostato para 80F “para ir mais rápido”
Uma vez, os outros participantes esqueceram que eu, um engenheiro de baixo escalão, tinha sido convidado para uma reunião de liderança. Quando alguém admitiu que seria muito difícil cumprir o prazo X e perguntou se deveríamos mudar para uma data mais realista, um PM sênior respondeu: “Nós nunca movemos prazos! A engenharia sempre usa todo o tempo que recebe!”
Nesse caso, a engenharia devolveu o tempo quando eu saí daquela equipe
Também é verdade que muitas equipes de engenharia usam todo o tempo que recebem
Mas gestores deveriam preparar a organização para estouros, em vez de transformar estimativas e planos em prazos rígidos diante dos engenheiros. Se, quando a data prevista de conclusão se aproxima, o desenvolvedor consegue explicar quais partes demoraram mais e por quê, isso deve ser entendido de forma razoável
Gestores também devem impedir que clientes, vendas e superiores tratem a data planejada de conclusão como um prazo final. Se for preciso assumir um compromisso, o prazo voltado ao cliente deve ficar consideravelmente depois da data prevista de conclusão
Radiadores elétricos também podem ter efeito na prática. Afinal, eles não vão desligar imediatamente só porque o ar perto do radiador esquentou
Depois de ver muitas “estimativas chutadas” virarem prazos finais rígidos, passei a defender a abordagem No Estimates junto aos stakeholders
No começo, naturalmente há resistência. Para aliviar as preocupações, ajuda explicar que estimativas suficientemente precisas para serem usadas de forma legítima no planejamento, na verdade, só são possíveis em dois casos
A) Quando o trabalho restante é quase uma cópia de trabalho anterior. Por exemplo, provisionar pela segunda vez um data center no mesmo sistema
B) Quando a equipe julga que o trabalho restante de novos recursos entrou no último quartil e está bem definido, incluindo os riscos restantes que poderiam impedir o sucesso
Microestimativas viabilizam microgerenciamento. Equipes saudáveis encontram o trabalho de maior prioridade com base no risco para o sucesso do projeto e o executam em ordem decrescente
0 - https://www.youtube.com/watch?v=MhbT7EvYN0c
1 - https://www.goodreads.com/book/show/30650836-noestimates
Chamou minha atenção uma fórmula divertida que vi antes no HN. Ela parece elaborada e bacana, mas, como outros métodos de estimativa, não tem validade formal e é apenas uma fórmula arbitrária baseada em experiência pessoal
https://news.ycombinator.com/item?id=37965582
Minha matemática de estimativa: R = t × [1.1^ln(n+p) + 1.3^X]
R é o tempo real necessário; t é o menor tempo possível quando não há necessidade de comunicação; n é o número de pessoas envolvidas no processo, incluindo o cliente e a organização de desenvolvimento; p é a maior distância de comunicação dentro do projeto; X é o número de novas ferramentas, bibliotecas e técnicas usadas no processo
Por exemplo, se um projeto em que um desenvolvedor escreve o código leva 2 semanas (t=2), envolve 5 pessoas no total (n=5), tem 1 ferramenta nova (X=1) e a maior distância de comunicação é 4, então 2×(1.1^ln(5+4) + 1.3^1) = 4,5 semanas
É preciso somar quantidades de X não só para os desconhecidos conhecidos, mas também para os desconhecidos desconhecidos
Infelizmente, estimativas são negociação. Quem dá o número primeiro geralmente perde por causa da “careta”
“Qual é a estimativa?” “Não sei bem.” “Nem que seja por alto.”
“Então para quando vocês precisam?”
Essa é a armadilha em que gestores iniciantes caem toda vez. Se você dá a resposta, bingo. É aí que eles mostram a “careta”. Inspiram por entre os dentes, fazem uma expressão de desaprovação e dizem: “Ah, isso é totalmente irrealista. De onde saiu esse número?”, e então apresentam um número várias vezes maior ou sugerem reduzir o escopo do trabalho. Algo como: “Puxa, nesse prazo, com muita sorte e cortando o recurso Y de outro projeto, só daria para fazer o recurso X”
O importante é, faça o que fizer, não dar o número primeiro. Como no pôquer ou na compra de um carro, leva um tempo para pegar o jeito. Tempo é dinheiro até em grandes empresas, e deve ser tratado assim. É um jogo de soma zero
Onde eu trabalho, em nome da eficiência, as estimativas continuam diminuindo, e trabalho transferido para o próximo período também não é permitido
Passei mais de um ano em um estado quase de crunch, sem tempo de recuperação. Continuei esperando que melhorasse, mas parece que só piora. Além disso, todo mundo fica sendo realocado continuamente para áreas diferentes do produto, sem opção de escolha. Ainda estou tocando em frente, mas sinto que estou completamente esgotado mentalmente