A TI é afeita a termos e letrinhas que surgem de tempo em tempo. No momento atual, os termos “transformação digital”, “microsserviços” e “DevOps” são tão modinhas quanto as músicas de qualidade ruim da Anitta.

E o problema das modinhas é que que todos querem dizer que estão fazendo, mesmo que tenham uma ideia distorcida do que estão realmente fazendo. A este respeito, tenho observado excelentes oportunidades DevOps sendo jogadas nos lixo por implementações equivocadas em pequenas e grandes empresas.

E se é para nos equivocarmos, gostaria de ajudar também. Vamos direto ao ponto e criar um guia rápida de como fracassar com DevOps.

É fácil. Siga os sete passos abaixo e falhe na sua implementação DevOps. É fracasso garantido ou o seu dinheiro de volta.

1. Contrate um “Analista DevOps”

Existem sim líderes técnicos, desenvolvedores, testadores e profissionais de qualidade, entre outros, que praticam DevOps. Ao mesmo tempo devemos nos lembrar, desde o início, que o DevOps é uma cultura. Ou seja, não existem *Analistas DevOps*.

Acreditar que você vai encontrar um “Analista DevOps” já é ruim. E para piorar alguns gestores acreditam que contratar um “Analista DevOps” é o suficiente para ter a sua implementação DevOps realizada.

2. Crie uma área especialista para fazer DevOps

Erro clássico, embora muito comum. Criar mais um silo em um departamento de TI que já tem áreas de gestores, analistas, desenvolvedores, testadores, homologação e produção trabalhando em locais diferentes definitivamente não irá ajudar.

O DevOps prega a quebra das paredes (físicas e invisíveis). E não adicionar mais uma área funcional dentro da sua TI.

3. Estabeleça um pipeline DevOps dentro da área de qualidade ou governança

Qualquer iniciativa de centralizar uma esteira DevOps vai intensificar o oposto do que a cultura DevOps promove. O DevOps é uma cultura que promove comunicação ampla e a quebra de silos.

Que fique claro: o DevOps ocorre NOS PROJETOS e não em uma torre de marfim de qualidade.

4. Mantenha testadores e desenvolvedores trabalhando em áreas diferentes

Apartar (no espaço e no tempo) testadores e desenvolvedores é um dos piores erros que gestores podem cometer. Isso gera adiamento na resolução dos defeitos, desalinhamento e dedos apontados sobre as culpas no final do projeto. E isso também mantem a nefasta cutural funcional e os malefícios que os processos cascata nos impuseram ao longo dos últimos 40 anos.

5. Não envolva o time de infraestrutura. Ou não envolva o time de desenvolvimento

DevOps sem Ops soa estranho, certo? Assim como uma iniciativa DevOps sem Dev. E mesmo assim estamos vendo muitas implementações DevOps que ocorrem apenas dentro da área de desenvolvimento ou da área de operações.

6. Implante as ferramentas DevOps em primeiro lugar

Muitos gestores acreditam que ferramentas como VSTS, Chef, Puppet, GitLab, Docker ou Ansible já trazem o DevOps dentro dela. É como se você comprasse uma panela de cerâmica laranja e esperasse que o seu jantar vá ter qualidade de restaurante três estrelas Michelin.

Embora estas e outras ferramentas sejam excelentes devemos nos lembrar que no mundo DevOps devemos:

• primeiro trabalhar as pessoas e a cultura,
• depois as práticas;
• e finalmente as ferramentas.

7. Venda o DevOps como a bala de prata que irá matar os lobisomens da sua organização

Não, o DevOps não é uma bala de prata. Ele não irá revolucionar a sua TI, não irá zerar o backlog e os defeitos, não irá garantir todas as entregas dentro dos prazos e também não irá fazer que pessoas deem as mãos em harmonia.

Apesar disso,  o DevOps pode lhe ajudar sim no contínuo caminho da melhoria contínua que buscamos nos ensinamentos do sistema Toyota de Produção e nas práticas Lean.

Algo está errado se os trabalhadores não olham ao seu redor cada dia e não encontram coisas tediosas ou aborrecidas para depois reescreverem eles mesmos os procedimentos. Mesmo o manual do mês passado deveria estar desatualizado hoje, Taiichi Ohno

Para combater essa e outras mazelas, recomendo o livro abaixo. Já um clássico dentro da recente e empolgante literatura DevOps.