Você já ouviu falar sobre toil? O termo parece um tanto quanto esquisito e por mais que não soe familiar, provavelmente você já se deparou com esse processo.

Quem trabalha na área de tecnologia sabe que, muitas vezes, os projetos envolvem tarefas que deveriam ser resolvidas rapidamente, mas que acabam gerando um esforço desnecessário, ocasionando o desgaste do time.

Se deparar com processos complexos no dia a dia torna ainda mais difícil a busca pela solução ideal para o seu cliente, principalmente se essas etapas puderem ser evitadas desde o começo do projeto.

Por isso, separamos um conteúdo especial da Skalena – uma das unidades aceleradoras dos processos de transformação digital da SQUADRA – que atua com estratégias de API’s, para explicar o que significa toil na prática e como podemos diminuir sua porcentagem na empresa.

Confira o artigo na íntegra:

Toil: Você pode não saber o que é, pior ainda, já pode estar sofrendo com isto ↩

Trabalhar com palavras em inglês na área de tecnologia não deve ser problema, afinal de contas, estamos rodeados delas em nosso cotidiano. Entretanto, esta nova palavra: Toil, saiu dos escritórios hipsters do Vale do Silício e já faz parte das nossas organizações em território tupiniquim. Como uma imagem vale mais que mil palavras, observe a seguinte:

Gráfico com expectativa versus realidade de processos de desenvolvimento.

Expectativa vs Realidade ↩

Quantas vezes você vê isso nos seus projetos atuais, em resumo, muitas pessoas, mas também times inteiros e até organizações por completo esquecem de sua tarefa ou problema original a se resolver, e na ilusão de ter uma solução, acaba gerando um novo problema, que muitas vezes vira um loop quase que infinito que só chega ao fim tentando mais uma nova solução, que mais uma vez entrará no looping, e ao invés de ter um único problema, agora nesse cenário aqui descrito existem três.

O autor Vivek Rau, em seu livro, articula uma definição excelente:

“Toil é o tipo de trabalho vinculado à execução de um serviço de produção que tende a ser manual, repetitivo, automatizável, tático, desprovido de valor duradouro e que escala linearmente à medida que um serviço cresce.”

Vivek Rau

Imagine um Serviço de negócio para um Open Banking, como: Movimentação de Contas. Imagine fazer uma mudança de negócio que te custa 30 minutos, mas o deploy é tão complexo, são tantos yamls, tantos Istios, tantos kubectl apply …. Que faz com que o novo release leve 2 dias, e ainda com risco de erros.

Sim, isto está acontecendo, e está muito mais perto do que você possa imaginar, isto acontece usualmente na reinstalação inúmeras vezes de um cluster kubernetes que você achava que apresentava problemas por causa do provedor de nuvem, e depois de usar AWS, Digital Ocean, Oracle, Azure, você percebeu que o Ingress que estava tentando usar não tem suporte a certificados do tipo LetsEncrypt.

Nós passamos por um problema desses em uma combinação de ambiente, onde acabamos cometendo este erro, achando que o problema estava num lugar e ao invés de focarmos em averiguar a chave do problema, partimos para soluções no modelo go-horse, que no final, se tivéssemos sentado numa dailly e compartilhado esse problema de forma mais aberta e comunicativa, levaria 1 hora para ser resolvido, e não semanas. Perceba então o impacto negativo que Toil traz para as organizações.

Impacto nos Negócios ↩

Certamente o maior impactado do Toil é o negócio, que vai acabar tendo uma implementação que deixará a desejar, apenas para atender aos prazos das Sprints, ao invés de poder se focar essencialmente em algo que possa ser inovador, gerando diferencial competitivo para a área de negócio e empresa que você trabalha.

Calma, pode ser pior: Toil + Turn over ↩

Sim caro leitor, imagine alguém preso num toil que por incrível que pareça, recebe uma proposta e sai da empresa, sim, isso também aconteceu com a gente… Conclusão: Tivemos ainda mais trabalho para entender o que a pessoa estava tentando fazer, ou onde queria chegar, até termos um “q” de alguma sabedoria de nossa líder que disse: “E por que não recomeçamos do zero…”. Voila, resolvemos alguns destes toils de maneira muito mais efetiva.

Quando a frase “Tenha espírito de dono” destrói os ambientes ↩

Essa frase é linda, desperta empoderamento, sentimento de pertencimento, sentimentos apenas não tão fortes quanto a raiva e angústia gerada quando uma pessoa “cria um Toil para chamar de seu”, e simplesmente, além de não deixar ninguém tocar no problema, o protege mais que Gollum protegia a preciosa jóia da premiada estória de JR Tolkien: O Senhor dos Anéis. Estes membros de equipe geram problemas inclusive para os gestores, que pouco podem fazer para tentar que as coisas fluam no caminho certo.

Para finalizar ↩

Ao final deixaremos algumas ótimas referências que abordarão este assunto com uma maior extensão, porém, em nossos brainstormings, chegamos a conclusão que algumas ações e boas-práticas podem nos ajudar a reduzir ou pelo menos desviar de Toils complicados, abaixo alguns deles:

Se for usar Kubernetes, tentar usar alguma ferramenta que faça uma boa abstração dos ambientes que rodam em nuvens públicas, muitas vezes usar direto o AKS, e EKS e algumas ligeiras diferenças entre essas soluções, muitas vezes trazem uma certa dor de cabeça. Um bom orquestrador como o Rancher pode ser uma boa alternativa, para você começar a evitar e se possível eliminar os fã-boy de alguma nuvem específica, que muitas vezes puxam a sardinha para um lado específico, e esquecem que no final do dia, nós temos que fazer o que é bom para os negócios das empresas, e isto muitas vezes vai além de nossas preferências meramente pessoais. PS- Estamos testando recentemente o Platform9, em breve poderemos comentar um pouco sobre esta solução.
Na parte de CI/CD é interessante termos os pipelines escritos, ou representados de uma forma uniforme e comum, onde qualquer pessoa possa entender, nestes quesitos, ferramentas como o Harness tem apresentado um modelo de fluxo visual, que nos faz entender e seguir os passos que as tarefas estão passando, além de ser muito mais fácil de explicar para qualquer pessoa o que está acontecendo por de trás dos panos, ao invés de milhares de shell scripts, como chamadas de CURL, SSH, etc.
Seu backlog deverá ter o tempo de desenvolvimento da tarefa, e depois as fases de QA e Prod, se estas tarefas começarem a durar pelo menos a mesma coisa, ou pior, mais ainda que o tempo que você levou na construção, reveja se você não está começando a se prender em seu primeiro toil.