O Engenheiro DevOps está sendo um dos cargos mais procurados no mercado quando se fala de profissionais de TI. Além de ser um paradoxo em relação à demanda, aparentemente está muito claro o que se entende por ele.
Um novo herói em TI?
Encontramos na Internet dicas de como se tornar um, quanto ganham e quais os percursos para ter um bom desempenho. Geralmente são exigidas competências técnicas muito profundas (ou seja, conhecer várias ferramentas equivalentes, de vários fornecedores para disciplinas específicas) como amplas conjunto deles (dominar todo o ciclo de vida, com um conjunto amplo de ferramentas para todas as disciplinas do DevOps).
Dá a impressão que surge um novo herói em TI, alguém que realmente resolva tudo, conhece todas as ferramentas de mercado e ainda mais, sabe tirar o melhor proveito delas. Será que isso é viável?. Será que existem profissionais de TI que passaram por todas as áreas e conhecem muito bem todas as especialidades? Uma coisa está clara: seu papel é automatizar e otimizar todo o ciclo de vida da entrega.
Engenheiro DevOps
Um dos fundamentos do DevOps é a capacidade de construir um modelo altamente colaborativo entre os especialistas, a fim de minimizar as barreiras e restrições, desperdícios e falta de qualidade, com a finalidade de ser mais assertivo, eficiente e mais eficaz. Se a origem do DevOps está em integrar de maneira orquestrada as áreas especialistas da TI, com a finalidade de ter resultados sorprendentes, claramente um pilar disso é a automação.
Gargalos do processo
Quando analisamos os gargalos do processo, também precisamos dar a devida atenção à sobrecarga de trabalho dos profissionais, à descompensação de conhecimentos e responsabilidades. Neste ponto, os herói na TI precisam se articular de uma maneira diferente da tradicional, já que eles podem criar desequilíbrio nas competências, conhecimentos e na alocação dos profissionais.
Antigos heróis da TI
Muito bem exemplificado no livro “O projeto Fênix”, os antigos heróis da TI, passam a ser uma restrição no processo, precisamos equacionar melhor as competências das equipes. Se pensarmos nesta justificativa, a eliminação dos concentradores de trabalho faz parte da adoção do DevOps, em ambientes de maior colaboração e empatia.
Cargo x Papel do Engenheiro DevOps
É aqui que vemos se consolidando um modelo do avesso ao DevOps quando falamos do Engenheiro DevOps, entendido como cargo e não mais como papel. Aqui uma reflexão que deixo. Se olharmos para órgãos de certificação de TI como Exin, DevOps Institute e DASA (DevOps Agile Skills Association) nenhum deles tem sequer uma certificação ou curso que vise desenvolver este cargo ou papel. Sabemos que as próprias ferramentas ficam obsoletas muito rapidamente, o que pode realmente ser um problema para estes profissionais.
Se olharmos o “papel” do Engenheiro DevOps, fica mais claro seu lugar no contexto Devops. Quando falamos de papel nos processos, temos que os profissionais transitam em vários papéis durante suas atividades diárias. Às vezes com o papel de “Desenvolvedor”, outras “Analista de Incidentes” quando há alguma falha em produção, outras como “Analista da Liberação” quando realizamos a construção e empacotamento da solução. Assim, fica mais claro que quando estamos automatizando alguma atividade que é de domínio da nossa especialidade, estaremos no papel do “Engenheiro DevOps”. Ou seja, todos automatizamos e neste espaço, que melhor que o próprio especialista, aquele que tem domínio específico, se ocupe de melhorar suas atividades com a automação.
Conclusão
Existe uma grande confusão em Devops, tanto do seu significado como da sua adoção. O Engenheiro DevOps visto da maneira de cargo, será delegado uma responsabilidade imensa de melhorar a TI, sendo que eles só ter poder de decisão restrita frente ao ferramental. DevOps é mais uma adaptação das práticas tradicionais do que a automação deles. a Automação é consequência. Como dizia Patrick Debois, conhecido como o padrinho do DevOps, DevOps é principalmente um problema humano. Assim como a astronomia não é sobre telescópios, DevOps não é sobre automação”, Christopher Little.
Artigos relacionados:
