🥇DevOps ou como perdemos nosso salário e o futuro da indústria de TI

O mais triste na situação atual é que a área de TI está se tornando um campo onde não existe a palavra “parar” em relação à quantidade de responsabilidades para uma única pessoa.

Ao ler anúncios de emprego, por vezes você já não vê 2-3 pessoas, mas uma empresa inteira representada em uma única pessoa; todos estão apressados, a dívida técnica cresce, e o legado antigo, diante de novos produtos, parece uma obra-prima, porque, afinal, pelo menos existe documentação e comentários no código. Os novos produtos são desenvolvidos a uma velocidade vertiginosa, mas, no final das contas, não podem ser utilizados por mais um ano após sua criação, e muitas vezes esse ano não gera lucros; além disso, os custos com a 'nuvem' são maiores que as vendas do serviço. O dinheiro dos investidores está sendo gasto na manutenção de um serviço que ainda não está funcionando, mas que já foi lançado como se estivesse operante.
Por exemplo: uma empresa famosa, cujo remaster de um jogo antigo recebeu as piores avaliações da história da indústria. Eu fui um dos que comprou esse produto, mas mesmo agora ele funciona de maneira horrível e, teoricamente, ainda não deveria ter sido lançado à venda nessa condição. Devoluções de dinheiro, queda nas classificações, um grande número de banimentos de usuários em fóruns por reclamações sobre o funcionamento dos serviços. O número de patches não é impressionante, mas aterrorizante; ainda assim, o produto não é utilizável. Se essa abordagem leva a tais resultados em uma empresa que desenvolve desde 91, a situação é ainda pior para empresas que estão apenas começando suas atividades.

Mas isso é o que observamos em termos de resultados dessa abordagem do lado do usuário do serviço; agora vamos analisar os problemas que surgiram para os funcionários.

Eu frequentemente ouço a afirmação de que não deve haver equipes DevOps, que isso é uma metodologia, etc., mas o problema é que as empresas, de algum modo, pararam de procurar nocks, dbas, infraestrutadores e engenheiros de build – agora tudo isso é feito por um único engenheiro DevOps. Claro, em algumas empresas específicas ainda existem essas vagas, mas elas estão diminuindo. Muitos chamam isso de evolução, mas pessoalmente vejo isso como uma degradação; é impossível manter um bom nível de conhecimento em todas as áreas e ainda conseguir trabalhar menos de 8 horas. Naturalmente – isso é fantasia. Na realidade, muitos profissionais de TI são forçados a trabalhar até 12 ou 14 horas, das quais apenas 8 são remuneradas. E muitas vezes, sem fins de semana, porque "me deram uma tarefa, os docs estão ausentes ou são imprecisos, e o serviço ainda custa dinheiro", e com um erro na nuvem, você realmente pode não receber o salário por alguns meses, especialmente se trabalha como autônomo. Na verdade, estamos perdendo a palavra nos negócios, juntamente com a divisão de responsabilidades; estou cada vez mais enfrentando o problema de que os gerentes se intrometem nos processos de desenvolvimento, sem entender nada a respeito; eles confundem dados de negócios e o funcionamento do aplicativo, resultando em caos.

Quando o caos começa, os negócios querem encontrar um culpado, e aqui é necessário um culpado universal; atribuir a culpa a mais de 10 pessoas é complicado, então os gerentes unificam as funções, pois quanto mais responsabilidades um único especialista tiver, mais fácil será provar sua negligência. Nas condições do Agile, encontrar um "culpado" e o castigo – isso é a base dessa metodologia de gestão. O Agile já saiu da TI e seu conceito principal passou a ser – a exigência de resultados diários. O problema é que um especialista muito específico nem sempre terá um resultado diário, e, portanto, será mais difícil fazer um relatório, e essa é mais uma razão pela qual os negócios querem "especialistas em tudo". Mas a principal razão, sem dúvida, é a folha de pagamento – essa é a principal razão de todas as mudanças; por um aumento, as pessoas aceitavam trabalhar por si mesmas e por mais alguém. Mas, no final, assim como em outras áreas, isso simplesmente se tornou uma obrigação, por uma remuneração menor por um maior número de serviços prestados.

Atualmente, é comum ver até artigos que afirmam que os desenvolvedores devem saber fazer deploy e lidar com infraestrutura ao lado dos engenheiros de DevOps. Mas a que isso leva? Corretamente, à queda na qualidade dos serviços e dos desenvolvedores. Há apenas 2 dias, eu expliquei a um desenvolvedor que se pode escrever e ler a partir de diferentes hosts, e eu fui convencido com fervor de que nunca tinham visto isso; havia apenas nas configurações orm host, port, db, user, password e tudo mais... Mas o desenvolvedor sabe fazer deploys, escrever ymls... Contudo, já esquece sobre testes unitários e comentários no código.

Como resultado, vemos o seguinte – constantes re-trabalhos, busca por soluções para problemas fora do horário de trabalho, aprendizado contínuo aos fins de semana, não para crescimento de renda, mas para se manter à tona. Os desenvolvedores são obrigados a ajudar o engenheiro de DevOps com CI/CD, e se o desenvolvedor não tem tempo, ele começa a se sobrecarregar, e os gerentes começam a pressionar, e se isso não aumenta o desejo de trabalhar horas extras, começam a aplicar penalizações e multas. A pessoa busca um novo emprego, deixando para trás uma dívida técnica do tamanho do Everest; como resultado, a dívida começa a aumentar também entre os desenvolvedores, pois eles são obrigados a escrever código com menos refatoração, para conseguir ajudar o antigo ou novo engenheiro de DevOps, e os gerentes estão satisfeitos, pois o culpado existe e é facilmente identificado, e, portanto, a principal regra do Agile na gestão foi cumprida: o culpado foi encontrado, e os resultados da sua punição são visíveis.

No passado, na ITGM, fiz uma apresentação intitulada 'quando aprenderemos a dizer não' — os resultados foram muito reveladores. Um enorme número de pessoas acredita que essa palavra é um tabu, e enquanto não pararmos de pensar assim, os problemas só aumentarão.

Essa artigo foi parcialmente motivado por este artigo, mas mais tarde talvez eu escreva de forma menos evasiva.

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.