Agile DevOps Lean Six Sigma Projeto

A Transformação do DevOps usando a Teoria das Restrições – Parte 2

Aprenda como a Teoria das Restrições pode ajudar desenvolvedores e administradores de DevOps a examinar suas políticas para adotar o DevOps com sucesso.

Este artigo é uma continuação da Parte 1, aqui. Não deixe de ler antes de começar a parte 2!

Pergunta 3: Quais políticas existem antes de implantar o DevOps?

A terceira questão é da maior importância e não tem uma resposta fácil. Mesmo quando as políticas atuais são bem conhecidas, em muitos casos, há tantas políticas que causam tantos problemas que é difícil encontrar e abordar todas elas.

E é imperativo abordá-los, ou então não podemos obter todos os benefícios resultantes da eliminação da limitação.

Por exemplo, se a promessa do DevOps é que podemos responder ao capricho de cada cliente e solicitar sobre nossa plataforma em menos de um dia – essa é uma vantagem competitiva significativa. Podemos realmente fazer isso se as implantações forem feitas por política uma vez por mês? Não, essa política deve ser abolida.

O Dr. Goldratt adverte que é fundamental encontrar primeiro a raiz da complexidade, o principal é que, se a mudarmos, todo o resto se encaixa.

O método ToC para mapear todos os efeitos indesejáveis ​​e expor esse conflito central é chamado de Processos de Pensamento Lógico, encontrando logicamente todas as relações de causas e efeitos.

É semelhante ao método Five Whys do Lean, mas muito mais rigoroso. Simplesmente não há espaço suficiente aqui para explicar todos os Processos de Pensamento Lógico, mas um livro excelente que se aprofunda para elaborá-los foi escrito por Lisa J. Scheinkopf,  chamado de “Thinking for a Change.”

Políticas de sucesso

Permita-me tentar descrever algumas das políticas que permitem o sucesso das empresas na era “pré-DevOps”, onde a concorrência tinha mais ou menos as mesmas limitações que nós.

  • Deve haver uma equipe de operações separada (com seu próprio gerente) sendo responsável pelos aplicativos em um ambiente de produção. Porque os desenvolvedores não querem ou não sabem como operar sistemas em produção.
  • A equipe de operações está sendo encarregada de realizar implantações, pois elas podem lidar com falhas mais rapidamente. Como a implantação de alterações tem um risco substancial, as taxas de falha geralmente são altas e a restauração de um serviço contra falhas geralmente leva muito tempo.
  • A introdução de um novo papel chamado SQA / QA / QC (uma equipe inteira) garantirá a alta qualidade de todas as mudanças introduzidas. Como os gerentes geralmente não esperam que um código de software de alta qualidade seja escrito e, na prática, ele muitas vezes falha de maneiras espetaculares.
  • Os gerentes aplicam os prazos adicionando outra função chamada Gerente de liberação / Engenheiro. O Release Manager gerenciará o cronograma e os deliverables implementados na produção. Como os desenvolvedores escrevem códigos e os testam para obter qualidade, demoram demais e precisam ser apressados, e os lançamentos devem acontecer de forma mais ordenada do que simplesmente ad-hoc.
  • Implantações uma vez por semana (ou uma vez por mês, ou 15 dias) são obrigatórias como uma política. Eles estão programados até mesmo no primeiro dia da semana, mas as entregas de Dev-Qa-RelEng-Ops movem constantemente essa ocorrência para o último dia da semana. Muitas vezes, os operadores agem como heróis e estão fazendo implantações durante o final de semana. A razão para essa política seria uma realidade em que a mudança rápida é ditada por concorrentes de alta velocidade, cada empresa deve fornecer recursos mais rapidamente.
  • O desenvolvimento de novos recursos prioriza o tempo e o orçamento, além da confiabilidade ou da melhoria da qualidade, e investe todas as mãos na criação de mais recursos novos, em vez de mais confiabilidade. A razão mais provável é a intuição dos gerentes, que guia a empresa na crença de que produtos melhores e mais clientes pagantes devem se originar de novos recursos.

Ser negado por competência e a grande verdade nas empresas

Vários anos atrás, eu estava pessoalmente participando de uma reunião urgente em uma empresa para resolver o problema onde as implantações ocorriam (com problemas) sempre no fim de semana. Minha sugestão foi de fazer as implantações com mais frequência, ou manter a equipe que desenvolveu e preparou o cutover de plantão (diminuindo consideravelmente os erros de preparação e seguindo o plano, afinal quem quer perder seu fim de semana?).

Esta proposta foi recebida com um olhar estranho e um definitivo “NÃO!”. A explicação da gerência era que as implantações eram muito arriscadas e que a empresa e o cliente não pode sofrer paradas para implantações com maior frequência – fui contratado para gerenciar os projetos, mostrar os gargalos e resolvê-los, mas ter ideia própria  e resolver estes gargalos, não estava dentro do meu contrato (ainda CLT) da época – e assim a empresa continuou utilizando janelas de finais de semana para realizar implantações, bem, hoje já não sei o que dizer, mas espero que tenham mudado o jeito de fazer.

Este é a clássica negação de quando a gerência fala e você empregado obedece.

Por que os gerentes decidem priorizar novos recursos em vez da confiabilidade de seus serviços? Aqui, na verdade, chegamos um pouco mais perto da causa raiz do porque as organizações raramente obtêm qualquer benefício das práticas de DevOps.

A forma como os gestores decidem no seu dia-a-dia e sentem-se bem é na base da intuição, que sempre provou ter sucesso no passado.

O problema é que essa maneira de tomar decisões é de longe melhor do que apenas tomar decisões arbitrárias. Devido à escassez de informações, um gerente raramente pode tomar qualquer decisão sem se comprometer. Uma decisão tomada com base em ótimas ideias em geral não será tão ruim quanto uma aleatória.

Ao mesmo tempo, é muito pior do que priorizar com base em uma avaliação do pensamento sistêmico ou holística do efeito de uma decisão.

Os novos competidores estão fazendo exatamente isso, medindo o efeito das decisões em seus resultados, e estão colhendo todos os benefícios de sua abordagem holística. Um grande exemplo vem da Etsy, que explica como eles fazem ” Design for Continuous Experimentation “.

A adoção do “novo velho” ou do “provitivo” (provisório mas definitivo)

Como consultor, muitas vezes confesso que “grandes organizações de alta velocidade raramente chamam especialistas para obter ajuda”. Por estar constantemente visitando muitas empresas de tecnologia nos últimos cinco anos, posso dizer definitivamente que as políticas e regras acima ainda são verdade, na maioria das organizações com as quais eu tive algum contato.

Conversar com outros consultores no em campo revela que essa é uma verdade global, mesmo empresas que têm uma “equipe de DevOps” ou “Engenheiro de DevOps”, ou que usam as mais recentes e melhores ferramentas de DevOps.

Na maioria dos casos, usam suas antigas regras e políticas, e não recebem quase nenhum benefício de sua adoção do DevOps. A tomada de decisão dos gerentes nessas organizações não mudou, e nenhuma das vantagens prometidas pelo movimento DevOps pode ser encontrada em qualquer lugar.

Uma empresa pode adotar Docker, Kubernetes, Cloud, Serverless, mas ainda assim ter uma total desconexão entre os desenvolvedores e as necessidades dos clientes – e ter implantações com tanta frequência quanto um eclipse solar.

Em exemplos narrados pelo Dr. Goldratt em sua série de áudio “Beyond the Goal”, ele explica que os primeiros adeptos da tecnologia são aqueles que entendem o benefício e obtêm as recompensas.

Quando a indústria começa a tomar nota, todos querem um pedaço do bolo – mas raramente sabem como agir.

A adoção de tecnologia, ferramentas e “keywords” (não adianta colocar um SQUAD ai!)

No mundo do DevOps, esses primeiros adotantes seriam empresas como Netflix, Flickr, Etsy, Amazon, Spotify. Uma vez que essas empresas são muito bem sucedidas por causa de suas novas tecnologias, outras empresas querem replicar as coisas que fizeram para competir.

As empresas que tentam se tornar o próximo Netflix ou Etsy replicam a tecnologia, as ferramentas, as palavras-chave. E uma negligência em mudar as políticas e regras existentes os deixa desorientados, sem entender por que nada melhorou.

Agora que há uma grande e nova “Equipe de DevOps” cheia de “Engenheiros de DevOps” usando as mais recentes e melhores “Ferramentas de DevOps”, elas ainda não conseguem entregar o software mais rápido do que antes.

A conclusão óbvia? “O DevOps não funciona”, “O DevOps não traz nenhum benefício”, os gerentes veem isso apenas como trabalho adicional e politicagem que não tem impacto real na empresa, sem perceber que estão apenas fazendo a coisa errada da melhor forma.

Uma multiplicidade de políticas impede as empresas de se adaptarem ao mundo em rápida mutação. Os gerentes acham que apenas usar esse conceito de DevOps, imediatamente, fará com que a empresa se mova muito mais rápido, “Ágil”, que na maioria dos casos está apenas fazendo a coisa errada mais rápido sem entender porque correr mais rápido não é o mesmo que avançar.

Este conflito dos “Devops errados” infligidos pelos gerentes a seus funcionários está causando todos os tipos de problemas para funcionários e organizações. Eu pessoalmente testemunhei desenvolvedores, DevOps e “engenheiros de devops” vivendo em constante frustração. Histórias de burnout e muito piores, empresas faliram, serviços quebram e “queimam”.

As empresas que têm um legado de grande sucesso com margens enormes mantêm o fogo queimando ao lado de funcionários que não estão fazendo nada ou fazendo muito para efeito negativo, apenas investindo em novas iniciativas.

Manopla do DevOps

Manter as políticas antigas e avançar com uma “equipe de DevOps”, “Engenheiro de DevOps” e “Ferramentas de DevOps” raramente alterará o valor dos negócios. Hoje todo mundo é um “Engenheiro de DevOps” e toda empresa tem uma “equipe de DevOps”.

Ele foi até mesmo votado como o segundo melhor papel baseado em salário e satisfação pela Glassdoor “50 Best Jobs in America” em 2017! Observe que nem existia como profissão na lista de 2016.

Essas empresas desfrutam das vantagens da estabilidade, qualidade e estão avançando mais rapidamente do que seus concorrentes? A maioria dessas organizações ainda está presa às mesmas políticas e regras que tinham antes da transformação.

É preciso um gerenciamento inteligente para sugerir mudanças em uma organização que possibilite os benefícios. Porque mesmo que funcionários talentosos possam contribuir com melhorias gerais, fazendo as coisas da maneira certa e dando um exemplo pessoal.

Eventualmente, o poder sobre a mudança de políticas e regras, para estabelecer novos padrões de trabalho, está nas mãos da administração.

Podemos fazer melhor do que isso, basta pensar e ter coragem para mudar comportamentos entrincheirados e adotar comportamentos mais adequados.

Pergunta 4: Que novas políticas devemos adotar para uma transformação DevOps?

Segundo o Dr. Goldratt, esta é a questão mais difícil de todas, e também a mais importante.

Dr. Goldratt e Dr. Deming nos ensinam a olhar para uma organização como um todo, se o objetivo da organização é melhorar os resultados finais – então as decisões em toda a organização precisam se alinhar de forma holística a essa meta. Continuar avançando sem olhar os dados, sem medir como as práticas atuais estão servindo ao sistema, deixa os gerentes em sua própria bolha de regras ótimas locais.

As empresas mencionadas Netflix, Etsy, Amazon, têm muitas medidas e coletam dados para ajudar a organização a escolher melhores decisões e práticas que realmente melhorem o resultado final.

Então, antes de contratarmos nosso primeiro “Engenheiro de DevOps”, ou começarmos uma nova “Equipe de DevOps”, ou procurarmos a melhor “Ferramenta de DevOps”, como conteinerização, que tal começar algumas medições?

Medir o valor entregue aos clientes e fornecer uma visibilidade clara dessas medidas para nossos gerentes e funcionários, isso pode ter um efeito tremendo.

  • Acreditamos que a qualidade afeta o resultado final?
  • Vamos então inspecionar nossa política em relação à qualidade. Nós temos uma boa definição de como a qualidade se parece?
  • Estamos produzindo qualidade, medindo qualidade e melhorando a qualidade como topo das prioridades da nossa empresa?
  • A qualidade está embutida no desenvolvimento de software, ou existe uma política que tenta martelar a qualidade nas mudanças de software depois que elas foram criadas?
  • A nossa organização exige que todos os nossos desenvolvedores escrevam testes de unidade de software?
  • Como também nossos desenvolvedores front-end?
  • Esses testes são usados ​​para fornecer feedback imediato e aumentar a confiança na confiabilidade do nosso serviço?
  • Medimos o efeito da má qualidade em nosso serviço ou o produto tem em nossa linha de produção?

As novas regras e políticas não podem ser ajustadas a todos, precisamos fazer alguma pesquisa de alma e encontrar os padrões relevantes para nossa organização.

Sim, e isso é um trabalho duro, requer investir algum tempo pensando em vez de gastar tempo em apagar incêndios. Ele manda aprender e ler ideias de homens incríveis como o Dr. Goldratt e o Dr. Deming, e tenta aplicar suas ideias com todos.

O Dr. Goldratt, por exemplo, tem um grande conhecimento sobre como lidar com incêndios, parte dessa discussão sobre Motores de Desarmonia. Há muito mais nos magníficos livros escritos pelo Dr. Goldratt, seus seguidores e seus professores.

Não vou escrever todos os novos regulamentos e políticas que uma empresa deve adotar. Isso será deixado para você, o leitor.

Convido você a iniciar uma discussão sobre o que essas novas políticas podem ser. Há muitas listas e ideias sobre essas atividades na Internet, mas nenhuma tem desvantagem, e nenhuma se encaixa em todas as organizações como uma luva, o contexto é muito importante e a experimentação faz parte da diversão!

Epílogo

Ter ideias dos métodos poderosos, utilizados pelos gigantes que formam a base do movimento DevOps, pode nos ensinar muitas novas e interessantes maneiras de pensar e abordar o gerenciamento e a engenharia.

Neste post, eu escrevi as quatro questões que avaliam a tecnologia pela visão do Dr. Goldratt e tentei colocar minha própria interpretação sobre isso para aplicar ao DevOps.

Livros mencionados nesta série

Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
CEO do portal, apaixonado por gestão de projetos, metodologias, minha família, professor, consultor de outsourcing de projetos com mais de 6 anos de experiência em projetos de TI e 18 anos de experiência em tecnologia da informação. Com experiencia trabalhando com supply-chain, e-commerce, e-procurement, compliance, agilidade e planejamento.

Graduado em Gestão de Tecnologia pelo Centro Universitário Barão de Mauá.
Pós-Graduado em Gerenciamento de Projetos, com as práticas do PMI® pelo SENAC.

Certificado como PMP® pelo PMI®. Six Sigma White Belt pela Voitto.
Especializado em BPMN2 pela Anelox, PMCanvas pela PM2.0 e Análise de requisitos

Mentor e influenciador de gestão de projetos, agilidade e transformação digital.

Comentários

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *