Suposições implícitas e tempo de validação: como eles podem influenciar o seu trabalho

Em tempos de constantes mudanças, nós somos cada vez mais cobrados por entregar mais, melhor e mais rápido, e por diversas vezes, trabalhamos muito e não entregamos o suficiente. Ou ainda, entregamos muito “internamente”, mas apenas uma pequena parte consegue completar o ciclo de validação e seguir para o cliente.

Alguns fatores contribuem para a nossa eficácia profissional e pessoal, e eu gostava de falar sobre dois deles: a consciência das suposições que fazemos no dia a dia e o tempo de validação delas.

---

“Estou em casa com uma dor na garganta, ligo para a farmácia e compro um anti-inflamatório. Depois de 3 dias começo a ter febre e decido ir ao médico”.

Conclusão: estava com uma infecção e precisava de um antibiótico. 

Esse é um exemplo de que eu, como “cliente/paciente”, assumi que o que eu quero é o que eu preciso. Comprei um remédio que eu achava que resolveria o meu problema (suposição implícita), ao invés de explorar o problema e ter o tratamento adequado a doença.

No nosso dia a dia fazemos suposições implícitas a todo momento e não nos damos conta disso. Olhem este outro exemplo de um programador:

“Terminei a funcionalidade de pagamento e agora só falta testar.”

- diz o programador.

Reparem que “terminei” e “só falta testar” não são fatos, mas suposições. Mas o programador, a sua equipa e os gestores comunicam e tomam decisões assumindo que estes são fatos. Quando estamos no cenário de uma empresa, podemos encontrar estas suposições implícitas em todas as tarefas, reuniões, conversas e decisões. Torná-las conscientes pode mudar o rumo de uma importante decisão e influenciar um sistema de trabalho.

Outro importante fator que contribui para desenharmos sistemas de trabalho mais ágeis é a velocidade em que validamos as suposições inerentes ao nosso trabalho. Atualmente tudo muda muito rápido: tecnologia, mercado, necessidade das pessoas. Fazemos sistemas cada vez mais complexos e para clientes cada vez mais exigentes, o que gera uma pressão maior na velocidade do ciclo “fazer, validar e entregar”.

Por exemplo, você desenvolve uma nova funcionalidade, o cliente valida e aprova. Antes de mostrar esta funcionalidade a ele, a aprovação era uma hipótese. Depois que ele aprovou, isto se tornou um fato. Semanas depois, as incertezas aumentaram pois o cliente não havia utilizado na prática para ver se aquilo resolve de fato o seu problema. Ou seja, você acha que vai resolver o problema pois ele aprovou, mas isto é uma suposição. Após o cliente usar na prática ele liga a dizer que resolveu o problema dele, está tudo certo. Então agora você tem um fato novamente.

"Fatos e suposições formam uma dualidade, como o dia e a noite, anulando-se um ao outro indefinidamente."

Vale, Alisson. A Fórmula da Eficácia (p. 74). Software Zen. Kindle Edition.

---

Podemos dizer que tudo o que fazemos passa por um Ciclo de Validação de Hipóteses. Se você é programador e já passou a experiência de escrever código em um editor de texto comum e só conseguir validar após todo o programa escrito, sabe como as correções e verificações eram complicadas. Cada linha de código era uma hipótese, a ordem das linhas era uma hipótese. Você supõe que a sintaxe e a ordem estão corretas fazendo com que aquela sequência de código proporcione o resultado esperado. Quando você consegue validar? Após escrever todas as dezenas ou centenas de linhas de código e compilar. Ou seja, após horas ou dias produzindo você consegue validar algumas ou - com muita sorte -  todas estas hipóteses.

Com o avanço da tecnologia, as IDEs de desenvolvimento já mostram, ao pressionar cada tecla, erros de sintaxe, uso inadequado da linguagem e até conformidade com padrões de arquitetura. Esta validação imediata reduz o ciclo de validação de hipóteses que antes levavam horas, dias ou semanas para poder ser realizado.

Agora que já temos validação imediata da sintaxe, precisamos garantir que o código faça a coisa certa. Nesse caso, o tempo do ciclo de validação de hipóteses é proporcional a quantidade de código e funcionalidade que desenvolve. Se 10 funcionalidades são desenvolvidas antes de testar pela primeira vez, provavelmente ocorrerão problemas na validação e correção de bugs. Se apenas 1 funcionalidade for desenvolvida, menos hipóteses no código e menor tempo de ciclo de validação.

Vamos escalar este pensamento para uma empresa com várias equipas de desenvolvimento, que desenvolvem sobre a mesma base de código. Ou seja, a equipa X pode desenvolver algo que afeta a funcionalidade da equipa B, mesmo que esta estivesse ok. Considerando cada código como uma hipótese, ao desenvolver uma parte do sistema neste cenário de escala, eu suponho que esta parte de código:

• Está a funcionar conforme esperado 
• Não quebrou nenhuma outra parte do código
• Não alterou o resultado esperado de outras partes do código  

Executar estes tipos de testes (integração, regressão) pode durar segundos ou semanas. Como assim, Fabio? Analisando os dois extremos temos:

1. Ausência de qualquer teste automatizado 
2. ~100% de cobertura de testes automatizados -  pipeline de integração e entrega automatizado

Para quem não é técnico basta entender que no primeiro cenário temos que fazer tudo manualmente, e esse “tudo” é muita coisa. E, no segundo cenário, com apenas um clique ou um comando, centenas de validações são feitas automaticamente. Esse é o principal motivo que permite empresas como Amazon e Netflix atualizem o  código em produção várias vezes em apenas um dia, mesmo tendo várias equipas de desenvolvimento trabalhando num mesmo produto.

---

A mensagem principal que eu quero deixar é que a velocidade com que trabalhamos não tem uma relação direta com a velocidade que entregamos o que foi pedido, tampouco com a qualidade e eficácia esperada. Entretanto, quanto mais rápido passamos pelo ciclo de validação, mais rápido aprendemos, corrigimos e entregamos. Esta forma de pensar não é restrita a TI, ela abrange qualquer pessoa de qualquer área, inclusive na nossa vida pessoal.

Também não se esqueça do fator transparência: a cada conversa, reunião, decisão que você participar com sua equipa, família ou amigos perceba as suposições implícitas que podem estar direcionando o contexto e simplesmente as tornem explícitas. Garanto que o resultado será muito mais assertivo.

Este texto foi inspirado pelo livro A Fórmula da Eficácia de Alisson Vale.