Estimativa em TI: dói, mas precisamos falar sobre isso
Em uma terça-feira chuvosa, uma promissora reunião com o seu PO apresenta para você e seu time de engenharia de software um grande ppt com um belo projeto. São diversos números, ganhos e satisfação do cliente, além de redução de custos, que vão ajudar a empresa a alcançar excelentes resultados pelos próximos meses.
Com a visão de negócio bem definida e uma análise de ganhos do produto clara, agora é momento de priorizar a demanda em TI e começar a colher os frutos da promissora iniciativa.
Mas, antes de finalizar a reunião, vem a temida pergunta que não é incomum.
Quando você acha que fica pronto?
Profissionais de TI não gostam de estimar. A alta complexidade da atividade de desenvolvimento de software gera um caminho tortuoso para as equipes. Não são difíceis encontrar imprevistos que bloqueiam o avanço das equipes no cronograma. Dependências externas, bugs até então desconhecidos, implementações pouco escaláveis, código complexos de difícil manutenção, alta rotatividade de profissionais na empresa são somente alguns exemplos de riscos que a atividade envolve.
O problemas é que a grande maioria desses é muito complicado de ser prevista. Como prever que aquele time, extremamente alinhado e focado com os requisitos do projeto, perderá um profissional chave nós próximos meses? Como saber se a alteração de um simples botão quebra a ponta final do fluxo, tecnicamente complexo e cheio de sistemas e dependências? E se uma lei aparece e obriga o time a investir tempo em outro projeto que, se não entregue, coloca a companhia toda em risco?
Isso nos leva a conclusão de que estimar é extremamente impreciso, pois gera datas e números que fatalmente se revelarão incorretos no futuro. Antes de efetivamente colocar a mão no código, desenvolvedores não tem o conhecimento necessário para entender o caminho por onde irão percorrer. E, ainda depois de colocar a mão no código, diversas outras variáveis recaem como uma bomba sobre a rotina e afetam a fluidez do trabalho, acarretando no aumento do tempo de entrega.
Se, por um lado, TI não tem segurança em apresentar uma data, as áreas de negócio dependem disso. São milhares de reais que devem ser investidos e que precisam de garantias de rentabilidade para os investidores. As metas agressivas das áreas de negócio por vendas não permitem erros de planejamento que levam a um investimento de risco.
Como escolher a melhor iniciativa a ser priorizada durante um semestre todo? Apesar de toda a complexidade que essa pergunta carrega, geralmente a resposta recai sobre o ROI (Return Over Investment). Assim, para se chegar ao ROI, preciso saber qual a grandeza do meu investimento, e somente assim sei se a iniciativa deve fechar no azul e se vale a pena colocar dinheiro nela.
Em resumo, sem estimativa, não há investimento.
No meio dessa ciranda, temos ainda o time de produtos, tentando equilibrar as necessidades que vem de negócio com as capacidades que apresenta o time de TI. Se priorizar é a principal atividade desse time, nada mais justo que ele tenha acesso a todas as variáveis dessa balança para justificar suas decisões. Produto é o time que deve ter mais embasamento para apresentar o quanto determinada iniciativa trará mais valor considerando todas as dimensões da organização.
Alguém tem que ceder
Você já deve ter percebido que entramos em um ciclo infinito. TI não consegue estimar sem ser priorizado, e negócios não consegue priorizar sem ter uma estimativa. Já dizia o velho filme: alguém tem que ceder. Sem que uma das partes assuma um compromisso e tome uma decisão sem ter acesso a todas as informações, estamos em um beco sem saída.
A experiência desse que escreve indica algo claro e frequente no mercado de trabalho: os números sempre falam mais alto. Não importa suas convicções, a possibilidade de colocar valor numérico para embasar suas decisões e usar isso para argumentar a seu favor invariavelmente te trás o troféu. Isso vale para todos os tipos de números. Por isso é tão importante gerar métricas. Elas tornam tangíveis percepções que somente quem está no dia a dia tem.
Se você tivesse que escolher entre dois empregos, quais seriam os seus critérios de seleção? Salário? Distância? Em quanto tempo você tem possibilidade de crescer? Qual dá melhor benefícios? Se tivesse que escolher um plano de saúde, provavelmente compararia mensalidade, cobertura ou prazo de carência.
Perceba que fazemos isso na vida pessoal o tempo inteiro. Estamos o tempo inteiro usando números para tomar nossas decisões. Porque seria diferente na vida profissional?
O vencedor da queda de braço
TI ainda caminha a passos lentos em métricas no mercado. Desenvolvedores ainda não conseguem ver valor na geração de números como Lead Time na tomada de decisões, e isso leva a um certo desleixo com esse tipo de abordagem. Tem casos em que dizem ser “desnecessário” pontuar todas atividades, gerar gráficos, preencher relatórios, que o mais importante é focar em desenvolver e gerar valor para o cliente. É bem incomum observarmos em conferências palestras sobre o tema, e quando acontecem, ainda estão em um nível de maturidade bem baixo, focando mais nos princípios sobre o assunto.
Ainda assim, mesmo nos cenários onde temos números para justificar decisões em um time, nem sempre esses números podem ser usados. Como usar o histórico de cadência de entregas de um time que mudou 30% do seu quadro recentemente? E nos casos de um projeto novo com time que nunca trabalhou junto? Como aplicar o histórico em um projeto de natureza completamente diferente da que propõe o projeto?
Perceba o quanto que, mesmo com números, o cenário de TI é complexo e carece de uma vista especial na execução dos trabalhos. Nem sempre temos números e, quando temos, são tão específicos de uma realidade que devem ser usados sempre com muito cuidado.
Dado esse cenário, o que vemos é que, por estar intimamente ligado aos ganhos financeiros, negócios geralmente trabalha muito mais orientado a dados que TI. Isso gera argumentos muito mais fortes do que “não tenho conhecimento para estimar” ou até mesmo Lead Time, que é extremamente situacional. Com isso, ele quase sempre ganha a queda de braço e consegue a estimativa que precisa para seguir em frente.
Com isso, temos que aceitar que a estimativa vai fazer parte do nosso dia a dia antes da demanda entrar em curso. Muitas vezes, mesmo que imprecisa, a estimativa serve de parâmetro. Sem um número, mesmo que errado, a companhia não tem dado relevante para tomada de decisão
Por consequência, isso nos gera um outro problema: sabemos que a estimativa é imprecisa, e isso independe de vontade ou esforço do time, mas sim de tempo de projeto. Como então garantir que a expectativa da área de negócios, que está financiando o projeto, seja atendida no que diz respeito a prazo e esforço?
E agora?
Para gerenciar esse tipo de situação, vale algumas dicas. Lembre-se sempre que não existe bala de prata. Todo o conhecimento compartilhado pela comunidade deve ser visto como ferramentas que podem ou não fazer sentido para um determinado contexto. Conhecimento é sempre bem vindo e a maturidade dos profissionais vai mostrar com o tempo o que cabe ou em cada situação.
Dedique um tempo exclusivo para isso
Já que temos que estimar, vale direcionar todos os esforços para essa atividade. Não negligencie paralelizando outras demandas, quando possível. Esse é o primeiro contato com a implementação, e por isso merece atenção especial. Assim, negocie com as áreas interessadas o foco exclusivo do time durante o período de tempo que julgarem necessário
Use todas as (poucas) informações que tiver
Comece levantando todas as informações que já temos sobre o assunto. Pode ser que sejam poucas, mas valem se forem úteis e tangíveis. É melhor do que ficarem apenas no campo das ideias e do achismo. Para isso, levante documentações disponíveis, procure outros profissionais que passaram por projetos parecidos, discuta com o time as alternativas, veja se as pessoas já tiveram experiências semelhantes.
Planeje, mas não muito
Tenha em mente que essa é uma estimativa preliminar, e por isso o time vai errar. Isso é uma constatação, basta saber se o erro é para mais ou para menos. O ponto é que isso será descoberto somente ao longo do projeto. Por isso, tenha sempre em mente que o bom é inimigo do ótimo, e que nesse momento muitas incertezas ainda existirão — e tudo bem. O esforço empregado deve ser razoável ao ponto de clarear as ideias, mas não necessariamente de ir ao detalhe. Como essa estimativa vai mudar, ir ao detalhe é desperdício e deve ser evitado.
Busque uma visão em vez de uma previsão
O planejamento deve ter um fim específico, que é dar visão ao time. Não devemos levá-lo a ferro e fogo. Ele deve ser uma forma de montar um campo de visão para responder a pergunta “onde queremos estar ao fim do projeto?”. Isso quer dizer que o planejamento deve discutir mais o que do que o como.
Para isso, quebre o projeto em entregas menores que possam gerar visão para os interessados da sua evolução. Não deixe as áreas terem contato com o projeto somente no fim, o que pode causar frustração e retrabalho por falta de alinhamento.
Foque nas entregas de valor
Ao levantar atividades, coloque o que entrega valor em vez de quais implementações são necessárias. É o que vamos ter de informação neste momento. Deixe um refinamento técnico específico de cada atividade para depois, para neste momento responder apenas qual o valor que queremos entregar.
Vale mais um “disponibilizar uma tela de cadastro” do que “implementar integração com o sistema XPTO”
Marque feedbacks constantes com todas as partes interessadas
Sabemos que a estimativa vai mudar, só não sabemos o porque e como vamos reagir a isso. Por conta disso, vale muito envolver todas as partes envolvidas em ciclos regulares de feedback, dando transparência não só das entregas, mas principalmente dos problemas que o time enfrenta. Isso gera compartilhamento de responsabilidade, empatia e pode trazer até aliados que suportem o time na remoção dos impedimentos.
Faça uma agenda semanal ou quinzenal com todos, alinhando previamente um horário que seja confortável para todos. A ausência de alguém nesse processo todo pode gerar ruído e problemas na comunicação da evolução
Por fim, ande devagar, mas ande sempre. Aplicar PDCA e priorizar o compartilhamento entre as partes é fundamental. Tome pequenas decisões, alinhe restrições, implemente e analise os impactos, repetindo o processo constantemente. É tudo sobre dar um passo de cada vez, entregando constantemente e validando com o cliente sempre que possível.
