Sim… a pergunta é essa mesma!

Se você está atuando como líder técnico, coach, consultor de ALM, Scrumaster, [alguma coisa] DevOps… a sua meta é, ou pelo menos deveria ser, a de perseguir a sua irrelevância.

Parece ser um contra-senso… mas não é! E vou explicar o por quê.

Revisitando o manifesto

No longínquo ano de 2001 algumas pessoas interessadas em melhorar o processo de desenvolvimento de software se reuniram e escreveram o que ficou conhecido como Manifesto Ágil, que você já deve conhecer, certo? Afinal, nos dias atuais, não existe quem não se diga ágil. Pois bem, os doze princípios do manifesto… hã?! Sim, são doze princípios, apesar de se perpetuar somente aquelas quatro principais frases, a ideia é mais abrangente, então seguindo a página do manifesto, o primeiro link leva aos doze princípios:

1 – Nossa maior prioridade é satisfazer o cliente
através da entrega contínua e adiantada
de software com valor agregado.

2 – Mudanças nos requisitos são bem-vindas,
mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das
mudanças visando vantagem competitiva para o cliente.

3 – Entregar frequentemente software funcionando,
de poucas semanas a poucos meses,
com preferência à menor escala de tempo.

4 – Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto.

5 – Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário
e confie neles para fazer o trabalho.

6 – O método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de desenvolvimento
é através de conversa face a face.

7 – Software funcionando é a medida primária de progresso.

8 – Os processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo
constante indefinidamente.

9 – Contínua atenção à excelência técnica e bom design
aumenta a agilidade.

10 – Simplicidade–a arte de maximizar a quantidade de
trabalho não realizado–é essencial.

11 – As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis.

12 – Em intervalos regulares, a equipe reflete sobre como
se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

Depois de ler tudo isso, você é capaz de responder: como um time, uma empresa, um produto; pode depender do conhecimento centralizado em apenas uma pessoa para conseguir fazer tudo isso aí funcionar?

O profissional DevOps

Quando escrevi o post de DevOps anterior, questionei a ideia de um profissional DevOps ser apenas o conhecedor de ferramentas, que ele deveria estar alinhado com o manifesto ágil, trabalhar com uma cultura diferente da Cultura da Culpa, por exemplo; mas principalmente esse profissional deve se tornar irrelevante.

Como já afirmei, não existe um cargo DevOps, existe a cultura DevOps, não existe um analista DevOps, existe o desenvolvedor e o administrador de infra trabalhando em conjunto. Para realizar a mudança de cultura é preciso evangelizar, ou seja divulgar uma nova maneira de trabalho, por esse motivo algumas pessoas tornam-se as pessoas de DevOps na empresa. Alguns até mesmo viram consultores, trabalhando para diversos clientes.

Esses profissionais conheceram ferramentas, técnicas, processos que podem ajudar a perseguir os princípios, entregar frequentemente, entregar funcionando, entregar com qualidade. Por isso estes assumem uma missão, de dar agilidade ao processo, automatizando-o, melhorando-o, tornando-o seguro. E dependendo da liberdade na empresa e maturidade da equipe, essa evolução será mais rápida ou se dará a pequenos passos, quase tão pequenos que talvez seja bem difícil de ser observar.

Em algum momento, o processo estará mais maduro… mas repare, que em momento algum eu digo que se chega ao fim, se termina uma “implantação” de DevOps, pois isso simplesmente não existe! Nada é estático, sempre teremos softwares novos, independente se isso ocorra em um período de meses ou de anos; teremos novas ferramentas, teremos mudanças, muitas, se você estiver em uma start-up. Se a entrega é contínua, o cuidado em se manter o processo também será. Portanto não é possível que apenas um profissional se autor de toda essa mudança.

Dividir para conquistar

Anos atrás li um livro que contava a história de como Michael Dell iniciou a Dell Inc., que por coincidência é a máquina que estou usando para escrever esse post. Ele não é tão conhecido como Steve Jobs, mas talvez ele seja muito mais responsável pela popularização dos computadores, do que este último.

E neste livro uma “norma” da Dell me chamou muito a atenção, um gerente que agregava muito valor a empresa, ou seja, que crescia ganhava como “prêmio” ter a sua equipe dividida, ou seja, liderar menos pessoas! Contra-senso? Não! Apenas uma evolução, a equipe desse profissional cresceu tanto, ele evoluiu pessoas, formou outros líderes, que agora é preciso dividir com outros a responsabilidade!

Distribuindo conhecimento

A maioria das pessoas sente medo ao repassar conhecimento, parece que essa receita de bolo, aquela técnica, ou ter estudado uma ferramenta é o seu ganha pão, é a maneira que você irá se manter na empresa, no time; mas não é! Para outra pessoa aprender por ela mesma só é preciso querer, atualmente o conhecimento está disponível quase que infinitamente e através de várias mídias, reter só fará você perder um aliado e a sua chance de partir para outra aventura de conhecimento, de explorar o desconhecido já que você teria alguém para te dar esse suporte.

E para atingir, ou pelo menos perseguir com afinco, os princípios ágeis, só repartindo o conhecimento que você tem de uma ferramenta, técnica, automação; com o time.

Tornando-se irrelevante

Não, você não será irrelevante… no sentido literal do termo… você só tornará outros tão relevantes como você. E isso não o levará a situação de perda do seu emprego. Afinal como eu coloquei acima, manter esse ambiente todo perseguindo os princípios ágeis é uma missão de longo percurso, fora a manutenção dessa missão. Isso tudo, deixará mais tempo livre para que você possa criar coisas realmente relevantes para a empresa, resolver problemas de negócio ou mesmo criar novos negócios.

Conhecer uma ferramenta ou técnica não é o fim e sim o meio. Por isso o conhecimento tem que ser diluído na equipe e ter só um profissional com o título de Analista de DevOps, por exemplo, não faz sentido. Um desenvolvedor deve saber o funcionamento da infra, tanto quanto um sysadmin deve saber como subir uma aplicação. O conhecimento deve ser espalhado.

Hoje, atuando como consultor ALM, quando inicio um trabalho em um cliente, me pergunto: como posso me tornar irrelevante aqui? E busco passar o conhecimento que possuo de ferramentas, processos, cases, técnicas, … dessa maneira terei atingido um dos maiores objetivos em DevOps: ser colaborativo e contar com a colaboração do time.

Emmanuel Brandão