O que o Agile e o quiet quitting têm em comum?
Um novo termo surge nos assuntos de RH. Tecnologias sendo criadas e realidades aparecem na rotina das pessoas nas empresas. Enquanto coordenadores se adaptam para se tornarem Squad Leaders, mesmo com dúvidas se não são Tech Leads, surge uma novidade a ser compreendida: o que é o quiet quitting e como ele está presente no universo da tecnologia?
Quiet quitting é um movimento gerado nos Estados Unidos por profissionais insatisfeitos pela carga horária excessiva que vem exercendo no trabalho, além do acordado inicialmente em contrato. Não diferente do mundo corporativo no Brasil, o foco de líderes e equipes fica na entrega, ignorando se as 8h diárias dão conta da demanda. Só para de trabalhar quando tiver concluído o serviço, hoje.
Leia mais:
Afinal, a bolha de TI estourou?Embraer abre 300 vagas de estágio de nível técnico e superiorEmpresas dos Estados Unidos vão contratar mais de 20.000 refugiados
Eis que a pessoa muda seu raciocínio e passa a entregar o que é possível dentro do seu horário, buscando apenas uma qualidade de vida, inclusive esperada no momento que aceitou determinado emprego. Porém, se a empresa só quer aquele profissional se ele fizer além do que foi contratado, o caminho tende a ser a saída, por iniciativa da empresa ou da pessoa, quando ela entende que o ambiente ficou insustentável. Daí a tradução literária (e falha na criação da hashtag) de “demissão silenciosa”.
Virando a página, abrimos o capítulo do manifesto ágil. Uma evolução na gestão de projetos, o Agile vem para estruturar projetos mais orgânicos, ainda sem uma clareza no produto final, mas com entregas rápidas e pequenas. Sua origem se potencializou com a ascensão do universo tecnológico e o mercado de TI, especificamente na criação de soluções digitais. Diferentemente do Waterfall, ou método cascata no Brasil, o Agile está olhando o hoje e o amanhã, enquanto o método Waterfall visualiza projetos maiores e com clareza da entrega final, desde o início. Fazendo um comparativo, construir uma ponte de concreto, que vai ligar dois pontos claramente definidos e com uma estrutura que já se conhece, vai ser mais adequado um método Waterfall, o qual a qualidade da entrega vai ser mensurada na ponte finalizada. Já no Agile ou método Scrum, iria ser analisado o problema e, a partir daí, será proposta alguma solução para a travessia. Talvez, surja um transporte aéreo como proposta, implementado, testado e avaliado se foi efetivo. Pode também surgir como solução uma ponte de madeira, identificando que o material é mais sustentável e está mais disponível para a ocasião. O foco no Agile está no problema (ligar dois pontos), e não na solução proposta (ponte).
Ok, então voltando a pergunta original: tudo isso tem algo a ver com o tal quiet quitting? Vamos olhar como o manifesto ágil tem se comportado na prática:
Para conseguir entregas pontuais, é preciso de uma equipe com papéis muito claros, como Squad Leader para coordenar as equipes focadas na produção do projeto, Tech Lead para dar as orientações técnicas e mitigar impedimentos, Product Owner que orienta a efetividade das soluções desenvolvidas e a aceitação de mercado com o produto que está sendo gerado e o Scrum Master, que fica de olho se a aplicação do método está seguindo de acordo. Sem contar o próprio Desenvolvedor, que irá fazer toda a magia acontecer. Parece muita gente, e é. Por envolver muitos papéis, empresas contaram Squad Leader para fazer o papel de Scrum Master, CTO calçando o chapéu do Product Owner, e quando tem o Tech Lead, é o Desenvolvedor mais sênior. Resultado das pessoas envolvidas nessa equipe: sobrecarga de trabalho. Resultado da sobrecarga: borderline, Burnout, ansiedade… Ou quiet quitting.
Vamos para outra perspectiva: a terminologia das coisas. Assim como há uma interpretação errada na demissão silenciosa, o ágil do manifesto não é sinônimo de fazer a mesma coisa mais rápida. A agilidade da entrega se dá pelo fracionamento, ou seja, se algo grandioso será construído, haverá checkpoints para avaliar se esse é o caminho e testar se o que está sendo desenvolvido é efetivo. O prazo final do grande objetivo, tanto no Agile quanto no Waterfall, tende a ser o tempo parecido, com grande tendência do Agile perder nessa briga do prazo, considerando que há as análises e, muitas vezes, o recálculo da rota durante a construção. Mas, na prática… o grande projeto, aplicado no conceito ágil, sofre da interpretação fake de que será entregue mais rápido, acarretando assim uma cobrança excessiva sobre os Desenvolvedores e demais membros da equipe, exigindo prazo e sem perda de qualidade. Havendo a cobrança excessiva de uma entrega grande em menos tempo, há uma sobrecarga de trabalho e pressão constante sobre o time. Resultado disso, já sabemos.
É preciso olhar para a forma como as empresas e profissionais encaram o trabalho de maneira geral e, consequentemente, os projetos que a galera de tecnologia se envolve. Nem tudo é Agile, e nem tudo precisa de quitting. A comunicação é essencial para se criar um ambiente produtivo e saudável. Líderes e pessoas querem o melhor, para a empresa e para o seu sucesso profissional. A cobrança em fazer mais e melhor, geralmente, já está intrínseca na pessoa contratada para o job. Exercer mais pressão só irá “forçar a barra” na relação profissional, gerando desmotivação e a tal “vontade de não fazer mais parte”. Nesse sentido, a saída tende a ser ágil, e o resultado esperado pela empresa, silenciosamente baixo.
Já assistiu aos novos vídeos no YouTube do Olhar Digital? Inscreva-se no canal!
O post O que o Agile e o quiet quitting têm em comum? apareceu primeiro em Olhar Digital.
