Agile DevOps Lean Six Sigma Projeto

A transformação do DevOps usando a teoria das restrições – Parte 1

Aprenda como a Teoria das Restrições pode ajudá-lo a abordar diferentes áreas de seus processos de DevOps para garantir que sejam eficazes.

Sei que já falamos aqui sobre DevOps mas hoje quero falar de algo um pouco diferente.

Vamos falar um pouco sobre a Teoria das Restrições

Por muitos anos, as empresas de TI foram expostas a mais e mais blogs e conferências falando sobre o DevOps, possivelmente o tema mais popular desde o Agile.

Aqueles que acompanham o movimento DevOps por algum tempo também devem ter notado que muitas apresentações e postagens de blogs repetidamente mencionam a Teoria das Restrições do Dr. Eliyahu M. Goldratt.

Na verdade, ” The Phoenix Project “, um livro que muitos consideram uma leitura obrigatória para qualquer gerente de DevOps, foi declarado por seu autor Gene Kim que foi escrito usando exatamente a mesma estrutura do best-seller do Dr. Goldratt ” The Goal “.

O movimento DevOps é cheio de ideias sobre como as empresas devem melhorar, essas ideias são criadas sobre os ombros de vários pensadores e fazedores gigantes que, por sua vez, transformaram indústrias inteiras com suas próprias ideias. Um desses gigantes é o Dr. Goldratt , outros incluem o Dr. Edward W. Deming , Taiichi Ohnoe até mesmo Henry Ford, os quais contribuíram muito para o gerenciamento na manufatura e em várias outras indústrias.

Toda vez que assisto a uma conferência ou assisto a um vídeo em que um palestrante menciona o ToC ou o Dr. Goldratt, fico muito satisfeito em ver que estamos aprendendo as lições do passado. Ao mesmo tempo, eu me pergunto: “Quantas pessoas na platéia leram algum livro do Dr. Goldratt ou do Dr. Deming?”.

Provavelmente, não há pesquisa que possa responder definitivamente a essa questão. Acredito que a Teoria das Restrições, juntamente com as conversas de DevOps, é uma vasta câmara de eco, ou muito mais provável que simplesmente uma grande parte da audiência não leu realmente nenhum dos livros ou descobriu o conhecimento para entender essa conexão de DevOps e ToC.

Aqueles que conhecem ToC e Lean podem ser claramente distinguidos, em muitos casos, essas pessoas não se calam sobre isso (no bom sentido).

Enquanto assistia a mais um vídeo de tal apresentação da conferência DOES16, chamada “ Beyond the Phoenix Project ” – eu decidi reler e re-ouvir as ideias do ToC e fornecer minha própria narração para colocar o ToC e o DevOps juntos.

Eu gostaria de citar o Dr. Goldratt e acender um holofote mais amplo sobre a indústria de TI usando minha interpretação do que ele poderia ter pensado.

(Isenção de responsabilidade: Eu releio os livros e assisti aos vídeos e ouvi gravações mais de uma vez na última década. Eu tento manter as explicações o mais próximo possível do que esses grandes homens e mulheres estão explicando, mas todo e qualquer erro de compreensão e interpretação são meus e só meus.)

Vamos começar com uma citação:

“A tecnologia pode trazer benefícios se e somente se diminuir uma limitação.” – Dr. Eliyahu M. Goldratt

O Dr. Goldratt começa com essa citação em seu livro ” Necessary but Sufficient “, em sua discussão sobre o papel da tecnologia. É também o primeiro tópico de seu audiobookAlém do objetivo ” e é explicado como a base de toda a lógica derivada para provar seu ponto. Ele repetiu essa suposição básica muitas vezes em outras palestras e apresentações.

Segundo o Dr. Goldratt, para produzir uma mudança baseada na tecnologia que terá efeito, é preciso responder as quatro perguntas. Todas as quatro devem ter respostas, ou então o benefício assumido de implementar essa tecnologia não pode ser obtido.

  1. Qual é o valor dessa nova tecnologia?
  2. Que limitação essa tecnologia diminui?
  3. Quais foram as políticas e regras que governaram antes de tentar adotar essa tecnologia?
  4. Quais devem ser as novas políticas quando esta nova tecnologia é usada?

Vamos tomar “DevOps” como um exemplo de “tecnologia” no sentido amplo da palavra e tentar responder a essas quatro perguntas.

Pergunta 1: Quais benefícios o DevOps traz?

A palavra-chave “DevOps” tornou-se tão sobrecarregada que raramente duas pessoas diferentes podem concordar sobre o que significa mais. Portanto, a resposta não é aparente. Primeiro, vou tentar definir o termo DevOps usando as mesmas noções empregadas por aqueles que cunharam a palavra, e não confiar na interpretação daqueles que adivinham seu significado após o fato.

“[DevOps]… tem um tremendo impacto nos negócios. A equipe técnica começa a se unir como um só. Uma mentalidade de “todas as mãos no convés” surge, com todas as pessoas técnicas se sentindo capacitadas e capazes de ajudar em todas as áreas… a batalha de desenvolvedores vs. administradores de sistemas começa a se transformar em uma abordagem interdisciplinar para maximizar universalmente a confiabilidade… tem um efeito positivo a linha inferior – melhor confiabilidade e disponibilidade, clientes mais felizes, tempo mais rápido de lançamento no mercado, mais tempo para concentrar a energia da equipe nos principais negócios. ”Stephen Nelson-Smith

De acordo com Stephen, o principal benefício que o DevOps traz é reduzir o atrito entre engenheiros em uma organização que cria sistemas mais confiáveis ​​que são mais fáceis de usar, manter e melhorar com o tempo, bem como clientes mais felizes, que se traduzem em resultados reais.

Observe que não há nenhuma explicação prática sobre como isso é alcançado na prática, lendo artigos sobre o DevOps que raramente sabemos o que devemos fazer no dia seguinte no trabalho. A descrição dos efeitos é bastante detalhada, deixando o leitor adivinhar como obtê-los.

Pergunta 2: Qual limitação é diminuída pelo DevOps?

Segundo o Dr. Goldratt, em alguns casos, uma limitação pode ser reconhecida e aparente. E em outras situações completamente não reconhecidas, nós apenas aceitamos uma dada realidade, do jeito que as coisas são e não suspeitamos que ela deva mudar ou que é possível mudá-la. Para lidar com as limitações existentes, nosso pessoal inventa regras e políticas que nos permitem continuar alcançando o sucesso apesar da existência da limitação.

O mesmo artigo do blog sobre o DevOps explica claramente uma dada realidade atualmente prevalente em muitas organizações de TI.

“No setor de TI de software, há uma suposição tácita de que os projetos serão executados com atraso e, quando forem entregues (se forem entregues), terão um desempenho abaixo do esperado e não serão bem aplicados em relação ao investimento. Uma vez que um aplicativo está em produção, o negócio tende a ganhar um tremendo medo de mudança. Uma suspeita constante de que o software e a plataforma em que ele se encontra são um tanto frágeis e vulneráveis. Sistemas de gerenciamento de mudança burocráticos são colocados em prática, tornando dolorosamente longo para introduzir novos recursos ou corrigir problemas com o aplicativo. ”Stephen Nelson-Smith

A citação acima aponta para uma causa de novas políticas para uma empresa que está tentando oferecer uma experiência, serviço e produtos muito melhores para seus clientes – medo de mudanças.Embora a causa raiz exata disso não seja explicada – ela existe se não tivermos medo de remover várias camadas ocultas de raciocínio lógico, encontramos um conflito subjacente ao raciocínio.

Podemos ter medo de mudar e implantar com pouca frequência ou entregar produtos ainda mais rapidamente aos clientes mudando com mais frequência – ambos não podem existir ao mesmo tempo.

Engenheiros em organizações estão aprendendo rapidamente com a experiência, assim como seus gerentes. Aprender com a experiência também cria uma cultura onde a intuição ajuda a orientar-se para soluções que terão o melhor resultado. Os engenheiros e gerentes são pessoas inteligentes e estão realmente conseguindo feitos incríveis, apesar da existência da limitação, por quê?

Como a criação de sistemas de TI é um empreendimento complicado, sem dados e informações suficientes, os engenheiros e gerentes ainda enfrentam a necessidade de tomar decisões – eles podem não conhecer a melhor solução, mas precisam decidir, é nesse ponto que a intuição nasce.

A intuição que faz com que a TI atinja suas metas afirma que os sistemas de TI são frágeis, não muito confiáveis ​​e que tentar criar comunicação e colaboração interorganizacionais é praticamente inútil. E ainda existem dezenas de engenheiros extremamente talentosos que estão conseguindo atingir seus objetivos, criando resultados significativos para empresas, governos e organizações sem fins lucrativos.

O que acontece quando introduzimos uma nova tecnologia como DevOps ou contêineres Docker ou uma nuvem pública? A limitação é diminuída pelo fato de que começamos a usar “ferramentas DevOps” ou práticas?

Sim provavelmente. Mas obtemos todo o potencial benefício do uso dessas ferramentas e práticas, deixando inalteradas nossas intuições e políticas?

Vamos responder às outras duas perguntas no próximo artigo. Você já leu sobre a Teoria das Restrições?

Coimbra, PMP on FacebookCoimbra, PMP on LinkedinCoimbra, PMP on TwitterCoimbra, PMP on Youtube
Coimbra, PMP
Como fundador da Projetos e TI, ajudo as organizações a se tornarem ecossistemas adaptativos, responsivos e auto-organizáveis, implementando novas práticas, estruturas, ritmos e tecnologias que permitam transparência, abertura, inovação e uma forma progressiva de liderar. Caso queira saber mais entre em contato comigo, inscreva-se na minha newsletter, ou me convide para uma palestra.

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.