{"id":89062,"date":"2020-07-18T07:41:57","date_gmt":"2020-07-18T05:41:57","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli"},"modified":"2020-07-18T07:41:57","modified_gmt":"2020-07-18T05:41:57","slug":"devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/devops-ili-kak-my-teryaem-zarabotnuyu-platu-i-budushhee-it-otrasli","title":{"rendered":"DevOps ou como estamos perdendo sal\u00e1rios e o futuro da ind\u00fastria de TI.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

O mais triste na situa\u00e7\u00e3o atual \u00e9 que a \u00e1rea de TI est\u00e1 se tornando um campo onde n\u00e3o existe a palavra \u201cparar\u201d em rela\u00e7\u00e3o \u00e0 quantidade de responsabilidades para uma \u00fanica pessoa. <\/p>\n

Ao ler an\u00fancios de emprego, por vezes voc\u00ea j\u00e1 n\u00e3o v\u00ea 2-3 pessoas, mas uma empresa inteira representada em uma \u00fanica pessoa; todos est\u00e3o apressados, a d\u00edvida t\u00e9cnica cresce, e o legado antigo, diante de novos produtos, parece uma obra-prima, porque, afinal, pelo menos existe documenta\u00e7\u00e3o e coment\u00e1rios no c\u00f3digo. Os novos produtos s\u00e3o desenvolvidos a uma velocidade vertiginosa, mas, no final das contas, n\u00e3o podem ser utilizados por mais um ano ap\u00f3s sua cria\u00e7\u00e3o, e muitas vezes esse ano n\u00e3o gera lucros; al\u00e9m disso, os custos com a 'nuvem' s\u00e3o maiores que as vendas do servi\u00e7o. O dinheiro dos investidores est\u00e1 sendo gasto na manuten\u00e7\u00e3o de um servi\u00e7o que ainda n\u00e3o est\u00e1 funcionando, mas que j\u00e1 foi lan\u00e7ado como se estivesse operante.<\/a><\/noindex>
\nPor exemplo: uma empresa famosa, cujo remaster de um jogo antigo recebeu as piores avalia\u00e7\u00f5es da hist\u00f3ria da ind\u00fastria. Eu fui um dos que comprou esse produto, mas mesmo agora ele funciona de maneira horr\u00edvel e, teoricamente, ainda n\u00e3o deveria ter sido lan\u00e7ado \u00e0 venda nessa condi\u00e7\u00e3o. Devolu\u00e7\u00f5es de dinheiro, queda nas classifica\u00e7\u00f5es, um grande n\u00famero de banimentos de usu\u00e1rios em f\u00f3runs por reclama\u00e7\u00f5es sobre o funcionamento dos servi\u00e7os. O n\u00famero de patches n\u00e3o \u00e9 impressionante, mas aterrorizante; ainda assim, o produto n\u00e3o \u00e9 utiliz\u00e1vel. Se essa abordagem leva a tais resultados em uma empresa que desenvolve desde 91, a situa\u00e7\u00e3o \u00e9 ainda pior para empresas que est\u00e3o apenas come\u00e7ando suas atividades.<\/p>\n

Mas isso \u00e9 o que observamos em termos de resultados dessa abordagem do lado do usu\u00e1rio do servi\u00e7o; agora vamos analisar os problemas que surgiram para os funcion\u00e1rios. <\/p>\n

Eu frequentemente ou\u00e7o a afirma\u00e7\u00e3o de que n\u00e3o deve haver equipes DevOps, que isso \u00e9 uma metodologia, etc., mas o problema \u00e9 que as empresas, de algum modo, pararam de procurar nocks, dbas, infraestrutadores e engenheiros de build \u2013 agora tudo isso \u00e9 feito por um \u00fanico engenheiro DevOps. Claro, em algumas empresas espec\u00edficas ainda existem essas vagas, mas elas est\u00e3o diminuindo. Muitos chamam isso de evolu\u00e7\u00e3o, mas pessoalmente vejo isso como uma degrada\u00e7\u00e3o; \u00e9 imposs\u00edvel manter um bom n\u00edvel de conhecimento em todas as \u00e1reas e ainda conseguir trabalhar menos de 8 horas. Naturalmente \u2013 isso \u00e9 fantasia. Na realidade, muitos profissionais de TI s\u00e3o for\u00e7ados a trabalhar at\u00e9 12 ou 14 horas, das quais apenas 8 s\u00e3o remuneradas. E muitas vezes, sem fins de semana, porque \"me deram uma tarefa, os docs est\u00e3o ausentes ou s\u00e3o imprecisos, e o servi\u00e7o ainda custa dinheiro\", e com um erro na nuvem, voc\u00ea realmente pode n\u00e3o receber o sal\u00e1rio por alguns meses, especialmente se trabalha como aut\u00f4nomo. Na verdade, estamos perdendo a palavra nos neg\u00f3cios, juntamente com a divis\u00e3o 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\u00f3cios e o funcionamento do aplicativo, resultando em caos. <\/p>\n

Quando o caos come\u00e7a, os neg\u00f3cios querem encontrar um culpado, e aqui \u00e9 necess\u00e1rio um culpado universal; atribuir a culpa a mais de 10 pessoas \u00e9 complicado, ent\u00e3o os gerentes unificam as fun\u00e7\u00f5es, pois quanto mais responsabilidades um \u00fanico especialista tiver, mais f\u00e1cil ser\u00e1 provar sua neglig\u00eancia. Nas condi\u00e7\u00f5es do Agile, encontrar um \"culpado\" e o castigo \u2013 isso \u00e9 a base dessa metodologia de gest\u00e3o. O Agile j\u00e1 saiu da TI e seu conceito principal passou a ser \u2013 a exig\u00eancia de resultados di\u00e1rios. O problema \u00e9 que um especialista muito espec\u00edfico nem sempre ter\u00e1 um resultado di\u00e1rio, e, portanto, ser\u00e1 mais dif\u00edcil fazer um relat\u00f3rio, e essa \u00e9 mais uma raz\u00e3o pela qual os neg\u00f3cios querem \"especialistas em tudo\". Mas a principal raz\u00e3o, sem d\u00favida, \u00e9 a folha de pagamento \u2013 essa \u00e9 a principal raz\u00e3o de todas as mudan\u00e7as; por um aumento, as pessoas aceitavam trabalhar por si mesmas e por mais algu\u00e9m. Mas, no final, assim como em outras \u00e1reas, isso simplesmente se tornou uma obriga\u00e7\u00e3o, por uma remunera\u00e7\u00e3o menor por um maior n\u00famero de servi\u00e7os prestados. <\/p>\n

Atualmente, \u00e9 comum ver at\u00e9 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, \u00e0 queda na qualidade dos servi\u00e7os e dos desenvolvedores. H\u00e1 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\u00e7\u00f5es orm host, port, db, user, password e tudo mais... Mas o desenvolvedor sabe fazer deploys, escrever ymls... Contudo, j\u00e1 esquece sobre testes unit\u00e1rios e coment\u00e1rios no c\u00f3digo.<\/p>\n

Como resultado, vemos o seguinte \u2013 constantes re-trabalhos, busca por solu\u00e7\u00f5es para problemas fora do hor\u00e1rio de trabalho, aprendizado cont\u00ednuo aos fins de semana, n\u00e3o para crescimento de renda, mas para se manter \u00e0 tona. Os desenvolvedores s\u00e3o obrigados a ajudar o engenheiro de DevOps com CI\/CD, e se o desenvolvedor n\u00e3o tem tempo, ele come\u00e7a a se sobrecarregar, e os gerentes come\u00e7am a pressionar, e se isso n\u00e3o aumenta o desejo de trabalhar horas extras, come\u00e7am a aplicar penaliza\u00e7\u00f5es e multas. A pessoa busca um novo emprego, deixando para tr\u00e1s uma d\u00edvida t\u00e9cnica do tamanho do Everest; como resultado, a d\u00edvida come\u00e7a a aumentar tamb\u00e9m entre os desenvolvedores, pois eles s\u00e3o obrigados a escrever c\u00f3digo com menos refatora\u00e7\u00e3o, para conseguir ajudar o antigo ou novo engenheiro de DevOps, e os gerentes est\u00e3o satisfeitos, pois o culpado existe e \u00e9 facilmente identificado, e, portanto, a principal regra do Agile na gest\u00e3o foi cumprida: o culpado foi encontrado, e os resultados da sua puni\u00e7\u00e3o s\u00e3o vis\u00edveis. <\/p>\n

No passado, na ITGM, fiz uma apresenta\u00e7\u00e3o intitulada 'quando aprenderemos a dizer n\u00e3o' \u2014 os resultados foram muito reveladores. Um enorme n\u00famero de pessoas acredita que essa palavra \u00e9 um tabu, e enquanto n\u00e3o pararmos de pensar assim, os problemas s\u00f3 aumentar\u00e3o.<\/p>\n

Essa artigo foi parcialmente motivado por este artigo<\/a><\/noindex>, mas mais tarde talvez eu escreva de forma menos evasiva.<\/p>\n

Apenas usu\u00e1rios registrados podem participar da pesquisa. Entre<\/a><\/noindex>, por favor.<\/p>\n

Voc\u00ea j\u00e1 se deparou em seu trabalho com um empregador que tentava substitu\u00ed-lo por v\u00e1rias pessoas?<\/h2>\n