Desenvolvimento

17 jul, 2017

Estimativas são promessas – uma metáfora melhor

Publicidade

Se você não sabe, eu frequentemente respondo a perguntas no Quora. Siga-me lá – até agora, eu escrevi mais de 600 respostas, muitas das quais lembram meus enormes artigos.

Uma das respostas mais populares se refere a “Qual a coisa mais difícil que você faz como um engenheiro de software?”. E minha resposta está em “Estimativas são Promessas. Promessas devem ser cumpridas.”, que escrevi originalmente em português.

Em poucas palavras, você nunca pode dar uma estimativa que seja “correta”. Se pudesse, não seria uma “estimativa”, seria uma “previsão”.

Vamos assumir que não temos poderes de profecia nem bolas de cristal para nos contar o futuro.

Estimar algo é “adivinhar” o valor de algo. É sempre um palpite. É o mesmo que uma avaliação. E, como qualquer hipótese, nunca pode ser considerada “correta”. É apenas um provável candidato entre uma infinita gama de valores possíveis.

Não há conexão entre um palpite e o resultado. Compreenda esta verdade simples: dizer que algo pode acontecer não FAZ isso acontecer.

Estimar o clima de amanhã como chuvoso não FAZ chover. Estimar os resultados do Super Ball não FAZ isso acontecer. Portanto, não há correlação entre uma estimativa e o resultado real.

Afirmei em artigos anteriores que “Estimativas são promessas”. A intenção era provocar uma reação na medida em que a maioria dos indivíduos assume que as estimativas nunca podem ser promessas, exatamente por causa do que foi explicado.

O que torna as promessas especiais é que, uma vez que você promete algo, é esperado que você AJA para realizar isso.

 

Skin in the Game

 

Ninguém que não tenha “pele no jogo” deve dar estimativas.

Se você não é um jogador ativo no jogo, não deve dar qualquer palpite. Da mesma forma que ninguém faz promessas para outra pessoa.

Você pode realmente fazer promessas credíveis e cumpri-las? Sim, você pode, mas primeiro deve entender mais algumas verdades sobre a realidade.

Você provavelmente já viu muitos artigos explicando muitas metodologias e técnicas de gerenciamento de projetos. Eu acredito que a maioria deles consegue explicar os “quês” e os “comos”, mas, como de costume, eles falham em explicar os “porquês”.

Por que precisamos dessas metodologias? Por que elas são mesmo necessárias? Por que elas funcionam? Quais são os mecanismos ocultos que elas colocam em movimento?

O que torna as técnicas ágeis diferentes do seu clichê de autoajuda de homeopatia ou orçamento?

É sempre tudo sobre Paretto

Não existe algo como um escopo precido de projeto. Há um limite para adicionar detalhes depois, dos quais você apenas obtém retornos decrescentes.

O nível de detalhe mais preciso que um escopo de característica pode ter é a codificação real do recurso. Isto é importante: as linhas de código da programação NÃO são o resultado. A execução desse código em tempo de execução é o que os usuários finais realmente experimentarão.

A programação em si é o plano REAL. Os diagramas, os casos de uso, as histórias de usuários ou qualquer outra não-programação antes disso são apenas rascunhos, um mero esboço.

Um arquiteto ou designer ingênuo pode pensar que os diagramas detalhados ou os documentos de casos de uso e slides de powerpoint sofisticados têm o mesmo valor que um plano de engenharia. Mas eles não têm: são o equivalente a um esboço em um guardanapo. Voláteis, e principalmente sem valor, na verdade.

 

Napkin Sketch

 

Mas programação não é o mesmo que a fase de construção, colocando tijolos em cima de tijolos?” – NÃO, isso não é o que um programador faz. O trabalho de tijolos é tarefa do chamado intérprete de idioma ou do compilador “cuspindo” o binário que executa.

Esta é a metáfora que torna os não-programadores loucos: na engenharia, a construção em si é formada pelas partes mais dispendiosas e demoradas. Na programação, o blueprinting (a codificação) é a parte cara, e a “construção” é realmente trivial (apenas compilação de código, o que é automático).

Da mesma forma, o escopo do projeto é apenas um conjunto de esboços. Devemos descartar a noção de que existirá um escopo “completo” de um projeto. Não há como dizer “100% do escopo” ou “escopo fechado”, porque o escopo do projeto de software é, por definição, sempre incompleto.

Além disso, eu argumentarei que aproximadamente 80% desse chamado “escopo” – o que eu prefiro chamar de esboço – são praticamente inúteis para a maioria das atividades dos usuários finais (a seção de administração, páginas institucionais que ninguém lê, processos complicados de inscrição etc.).

É por isso que cada lista de recursos DEVE ser priorizada. Você geralmente pode sobreviver com 20% dos recursos (isso é aproximadamente o que as pessoas querem dizer quando dizem “MVP ou “produto mais viável”). Lance o mais cedo possível, obtenha feedback dos usuários e aperfeiçoe o resto do “esboço”  que você chama de backlog.

Então, em vez de apontar para uma proposição de “tudo ou nada”, de ter que encontrar equações complexas estúpidas para descobrir uma estimativa “precisa” para um esboço incompleto, suponha que você possa realmente entregar CEDO – os primeiros 20% que realmente importam, e descubra o resto em iterações.

Ah, sim, isso é o que chamamos de “ágil”, por sinal.

Agile é sobre gerenciamento de riscos

As pessoas assumem que Agility é sobre o gerenciamento de projetos em termos de gerenciamento dos próprios instrumentos de “gerenciamento de projetos”: o backlog, os rituais, as métricas.

Ter instrumentos do tipo Agile não o torna ágil.

Ser ágil é manter o risco sob controle.

Em vez de pensar em projetos como um esforço de “tudo ou nada”, você deve começar a pensar nisso como um investidor pensaria em seu portfólio de ações. Você não espera que todo o portfólio produza lucros – você realmente assume que algumas ações vão apresentar um desempenho inferior. Você simplesmente não sabe quais, então você dilui seu risco.

 

Portfolio stocks

 

Tentar prever o mercado de ações é um exercício de futilidade.

Tentar prever a implementação precisa de um projeto – especialmente os longos – também é um exercício de futilidade.

Então, você deve lidar com a incerteza da maneira correta: tornando-se Antifragile.

“Algumas coisas se beneficiam de choques; elas prosperam e crescem quando expostas a volatilidade, aleatoriedade, desordem e causadores de pressão, e amam aventura, risco e incerteza. No entanto, apesar da onipresença do fenômeno, não há uma palavra para o exato oposto de frágil. Vamos chamar de antifragile. Antifragile está além da resiliência ou da robustez. O resiliente resiste a choques e permanece o mesmo, o antifragile fica melhor.”- Nassim Taleb

Em vez do exercício absurdo na futilidade de tentar prever incerteza e eventos aleatórios, você faz o razoável: você assume que os cisnes negros existem e que não pode prevê-los. Então, você se prepara para a incerteza da única maneira razoável: não tentar prevê-la.

Exponha os pequenos erros cedo, corrija-os com frequência. Implementar tudo em uma caixa preta e fazer uma implantação do Big Bang são o caminho mais fácil para o fracasso. Entregar frequentemente, expondo os bugs e corrigindo-os constantemente, é aceitar que os erros acontecerão e um modo de ganhar força no processo à medida que você evolui.

 

Antifragile

 

Uma melhor metáfora

 

Iron Ore Furnace

 

Imagine que você – o cliente não-programador ou você, o programador que não tem ideia de como explicar o processo ao seu cliente não-programador – possui um forno de minério de ferro para gerenciar.

Uma coisa sobre esses fornos é que se você aquecê-los demais, eles podem explodir em seu rosto. Se você esfriá-los demais, o minério irá endurecer.

Seu trabalho é adicionar carvão ao forno. Você decide em qual taxa. Se você for rápido demais, ele ficará extremamente quente. Se você for muito lento, pode extinguir o fogo e perder o forno.

Agora, tente fazer uma estimativa de uma ingestão constante de carvão para manter seu forno em boa forma.

Você não consegue.

A saída mais fácil é instalar um termômetro que acompanhe a temperatura atual do forno.

Você está seguro dentro de uma margem de temperaturas e acelera ou diminui o consumo de carvão, verificando o termômetro o tempo todo.

TODO O MALDITO TEMPO.

 

Iron Furnace

 

Isto é o que a “velocidade” baseada em Agile (ou qualquer uma das simulações de Monte Carlo mais sofisticadas) é realmente: um termômetro.

Se a velocidade é muito alta, ou sua equipe provavelmente está trabalhando extra ou entregando código de qualidade inferior. Isso vai dar errado, porque ou sua equipe vai se queimar muito rápido ou o código está acumulando dívidas técnicas de forma muito rápida, e você não poderá pagar. A velocidade irá parar quando você mantiver essa alta (explosão do forno).

Se a velocidade for muito baixa, sua equipe está relaxando, seu backlog é uma droga inútil que ninguém consegue entender mesmo após reuniões de 10 horas. Ou você já deixou a velocidade muito alta e agora está pagando a dívida técnica, ou sua equipe está morta após a queima (extinção de fogo).

Você quer manter a velocidade estável, constante. Ser Agile é sobre: manter o olho no termômetro e responder.

A triforça dos projetos

 

Iron Triangle

Bem-vindo ao Triângulo de Ferro da Gerência de Projetos.

Repita depois de mim: se eu quiser bloquear o tempo, o custo e o escopo, eu sou um idiota.

Repita novamente.

Você deve bloquear o tempo e o custo, e se você leu até aqui, sabe que nunca pode bloquear o “escopo” – você pode apenas torná-lo gordo (e não necessariamente mais valioso). É por isso que sempre digo que a própria definição de um Gerente de Produto ou Proprietário do Produto deve ser o bastião do ROI (Retorno sobre Investmento).

Agora, por quê?

Porque o Triângulo de Ferro tem o seguinte corolário:

 

Project Triangle

 

  • Se você quiser que algo seja rápido e bom, não pode ser barato.
  • Se você quiser que algo seja rápido e barato, não pode ser bom.
  • Se você quiser que algo seja bom e barato, não pode ser rápido.

Isso é uma lei, e você não pode mexer com ela. Faça sua escolha.

 

Make your choice

 

Então como eu mantenho as promessas?

Agora, com estas três verdades à mão:

  • Você não pode almoçar e comê-lo também (barato, rápido e bom).
  • Você está gerenciando a temperatura do forno.
  • Você só precisa de 20% do “esboço” que você chama de “escopo”.

Sim, qualquer desenvolvedor experiente pode dar uma estimativa ballpark. Um ballpark é assim:

  • 1 mês (talvez 1 mês e meio, mas definitivamente menos de 2)
  • 3 meses (mais de 2 meses, menos de 6 meses)
  • 6 meses (mais de 4 meses, menos de 9 meses)
  • mais de 6 meses, provavelmente menos de 1 ano

Nem tente granular mais do que isso. É inútil.

Bloqueie o tempo. E bloqueie o custo (isto é, a quantidade de desenvolvedores vezes a taxa horária vezes a quantidade total de horas estimadas). É isso aí.

Agora anote o que o cliente chama de “escopo” como histórias de usuários em um backlog e faça com que ele o priorize.

Comece as iterações. Após cada iteração, libere para um ambiente de teste. Não-programadores, cuidado: SEMPRE certifiquem-se de que qualquer programador que você contrate sempre entreguem versões testáveis das histórias entregues para uma URL acessível publicamente que você possa realmente visitar e testar.

Se o seu programador se recusar a fazer isso ou der desculpas: DEMITA-O.

Se o seu programador ou empresa ou qualquer coisa que lhe promete um preço de “escopo fechado”, promete fazer tudo e você acredita neles, você é muito crédulo.

Você acha que é divertido jogar esse estúpido jogo de “Eu vou fingir dizer que eu sei a verdade, e você vai fingir que você acredita no que eu digo”.

 

Actions and Words

 

Nenhum profissional sério tem tempo para jogar jogos estúpidos, e a única coisa honesta que qualquer um pode dizer sobre qualquer projeto de software é: “dada a minha experiência, acredito que a estimativa para esse tipo de projeto está dentro de X meses, dado os pressupostos Y e Z”.

Mas você não precisa acreditar nele. Você só precisa começar a verificar o termômetro. Qualquer não-programador poderá avaliar a qualidade da entrega com base nas entregas frequentes dos recursos priorizados.

“Mas e se depois de duas semanas não gostar dos resultados?”. Fácil: DEMITA-O.

E às vezes “demitirr” nem sequer é a palavra correta. Às vezes, o relacionamento é difícil, e a melhor coisa a fazer seguir caminhos separados.

Você precisa aceitar perder duas semanas – ou qualquer curto período de tempo – como parte da gestão de riscos. É melhor aceitar perder duas semanas de valor do orçamento do seu projeto do que ter que acreditar cegamente em alguém por seis meses, e ter que perder todo o orçamento do projeto e mais.

Paretto novamente: a agilidade é sobre gerenciamento de riscos. Você aceita que perder 20% do seu orçamento está certo. E você brinca com isso. Mas isso também está ok, porque você realmente precisa de um pouco mais de 20% do escopo esboçado que você possui.

Viu o que acabei de fazer com a matemática aqui?

Paramos de brincar com o jogo fingido e realmente gerenciamos os riscos do projeto. Você colabora no termômetro equivalente, que é uma combinação do backlog priorizado (a escala), da velocidade (a temperatura), e você observa as entregas parciais no ambiente de teste.

Conclusão

Então, sim, as estimativas devem ser levadas tão a sério quanto as promessas. Você pode dar estimativas razoáveis desde que possa gerenciar os riscos e que o cliente aceite as regras do jogo (não há “escopo fechado, completo”, “prioridades primeiro” e “testando e aceitando recursos entregues todas as semanas”) .

A ideia por trás das promessas é que você tem que gerenciar para cumpri-las. A melhor maneira de fazer isso é parar frequentemente, reavaliar e depois continuar. Parece que você está perdendo tempo, mas, na verdade, está se salvando do tempo perdido.

Se você não tem uma pele no jogo, recue.

A velocidade deve ser mantida constante. Não deve aumentar sempre. Não é sempre volátil e imprevisível. Mantenha a velocidade em uma taxa previsível e use a variação como indicação de ser muito rápido ou muito lento, ajustar outra variável, medir novamente e prosseguir. Assim como um termômetro de forno.

Existem várias versões de “termômetros” – desde o Agendamento Baseado em Evidências, de Joel Spolsky, até as simulações sofisticadas de Monte Carlo e outros processos estatísticos (todos eles são termômetros, e NÃO ferramentas de estimativa).

O que impede você de fazer isso é usar as metáforas erradas e as referências erradas.

Em vez de tentar encontrar metáforas equivalentes no negócio de construção, fábricas e outras montagens de hardware, você deve procurar em outro lugar, onde você encontrará outros processos de software.

Os músicos têm prazos. Os pintores têm prazos. Os coreógrafos têm prazos. Os esportes têm prazos. Os laboratórios de pesquisa possuem prazos. Como eles os cumprem? Verificando constantemente o estado atual e comparando os objetivos, avaliando se o que eles estão fazendo está realmente funcionando e mudando o que não funciona.

 

Conducting Star Wars

 

Hollywood tem prazos. Eles têm variáveis muito piores para controlar do que qualquer projeto de software que você possa encontrar, e eles conseguem entregar. E lucrar.

Aceite que você não pode controlar todas as variáveis, então pare de tentar. Pense nisso como os mercados financeiros. Um dia, você terá o Ethereum disparando 4.000% e, no dia seguinte, ele terá caido em cinzas em um crash instantâneo.

Não pretenda se tornar resistente ou resiliente. Prepare-se para se tornar Antifragile.