{"id":41818,"date":"2020-02-16T20:46:08","date_gmt":"2020-02-16T17:46:08","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/sem-arhetipov-prevrashheniya-po-princzipam-devops"},"modified":"2020-02-16T20:46:08","modified_gmt":"2020-02-16T17:46:08","slug":"sem-arhetipov-prevrashheniya-po-princzipam-devops","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/sem-arhetipov-prevrashheniya-po-princzipam-devops","title":{"rendered":"Sete arqu\u00e9tipos de transforma\u00e7\u00e3o segundo os princ\u00edpios do DevOps","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A quest\u00e3o de \"como implementar DevOps em sua empresa\" j\u00e1 \u00e9 debatida h\u00e1 alguns anos, mas n\u00e3o h\u00e1 muitos materiais bons dispon\u00edveis. \u00c0s vezes, voc\u00ea se torna v\u00edtima da propaganda de consultores n\u00e3o muito inteligentes, que s\u00f3 querem vender seu tempo, independente de como. Outras vezes, s\u00e3o palavras obscuras e extremamente gen\u00e9ricas sobre como os navios de megacorpora\u00e7\u00f5es navegam pelos vastos espa\u00e7os do universo. Surge a quest\u00e3o: e n\u00f3s, o que ganhamos com isso? Prezado autor, poderia resumir suas ideias de forma clara e em forma de lista?<\/p>\n

Tudo isso se deve ao fato de que a pr\u00e1tica real e a compreens\u00e3o dos resultados das transforma\u00e7\u00f5es culturais nas empresas s\u00e3o escassas. Mudan\u00e7as na cultura s\u00e3o processos de longo prazo, cujos resultados n\u00e3o aparecer\u00e3o em uma semana ou um m\u00eas. Precisamos de algu\u00e9m com bastante experi\u00eancia, que tenha visto como empresas foram criadas e destru\u00eddas ao longo dos anos.<\/p>\n

\"Sete
\n
\nJohn Willis<\/b> \u00e9 um dos pais do DevOps. John tem d\u00e9cadas de experi\u00eancia colaborando com in\u00fameras empresas. Recentemente, ele come\u00e7ou a notar padr\u00f5es espec\u00edficos que se manifestam no trabalho com cada uma delas. Usando esses arqu\u00e9tipos, John guia as empresas no verdadeiro caminho da transforma\u00e7\u00e3o DevOps. Mais informa\u00e7\u00f5es sobre esses arqu\u00e9tipos est\u00e3o na tradu\u00e7\u00e3o de sua apresenta\u00e7\u00e3o na confer\u00eancia DevOops 2018.
\n<\/a><\/noindex>
\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Sobre o palestrante:<\/b><\/p>\n

Mais de 35 anos em gest\u00e3o de TI, participou da cria\u00e7\u00e3o do predecessor do OpenCloud na Canonical, esteve envolvido em 10 startups, duas das quais foram vendidas para a Dell e Docker. Atualmente, \u00e9 Vice-Presidente de DevOps e Pr\u00e1ticas Digitais na SJ Technologies.<\/p>\n

A seguir, um relato na voz de John.<\/b><\/p>\n

Meu nome \u00e9 John Willis, e voc\u00ea pode me encontrar facilmente no Twitter, @botchagalupe<\/a><\/noindex>. Esse \u00e9 o mesmo apelido que uso no Gmail e no GitHub. E neste link<\/a><\/noindex> voc\u00ea pode encontrar os v\u00eddeos das minhas palestras e suas respectivas apresenta\u00e7\u00f5es.<\/p>\n

Tenho muitas reuni\u00f5es com CIOs de grandes empresas. Eles frequentemente reclamam que n\u00e3o entendem o que \u00e9 DevOps, e todos que tentam explicar falam sobre algo pr\u00f3prio. Outra reclama\u00e7\u00e3o comum \u00e9 que o DevOps n\u00e3o funciona, embora pare\u00e7a que os diretores fazem tudo conforme explicado. Refiro-me a grandes empresas que existem h\u00e1 mais de cem anos. Depois de conversar com eles, cheguei \u00e0 conclus\u00e3o de que para muitos problemas, solu\u00e7\u00f5es de tecnologia relativamente simples s\u00e3o mais adequadas do que alta tecnologia. Passei semanas apenas conversando com pessoas de diferentes departamentos. O que voc\u00ea v\u00ea na primeira imagem do post foi meu \u00faltimo projeto, a sala parecia assim ap\u00f3s tr\u00eas dias de trabalho.<\/p>\n

O que \u00e9 DevOps?<\/h2>\n

\nDe fato, se perguntar a 10 pessoas diferentes, elas dar\u00e3o 10 respostas diferentes. Mas o interessante \u00e9 que todas essas dez respostas estar\u00e3o corretas. N\u00e3o h\u00e1 resposta errada aqui. Tenho me aprofundado no DevOps por cerca de 10 anos, fui o primeiro americano no primeiro DevOpsDay. N\u00e3o vou dizer que sou mais inteligente do que todos que trabalham com DevOps, mas \u00e9 dif\u00edcil encontrar algu\u00e9m que tenha investido tanto esfor\u00e7o nisso. Acredito que o DevOps surge quando o capital humano se une \u00e0 tecnologia. Muitas vezes esquecemos a dimens\u00e3o humana, mesmo falando muito sobre diversos tipos de cultura. <\/p>\n

\"Sete
\n
\nAtualmente, temos muitos dados, cinco anos de pesquisas acad\u00eamicas, a verifica\u00e7\u00e3o de teorias foi estabelecida em larga escala. Essas pesquisas nos dizem o seguinte: se em uma cultura organizacional combinarmos alguns padr\u00f5es de comportamento, podemos alcan\u00e7ar um aumento de 2000 vezes. Esse aumento corresponde a uma melhoria semelhante na resili\u00eancia. Esta \u00e9 uma medida quantitativa da vantagem que o DevOps pode oferecer a qualquer empresa. Alguns anos atr\u00e1s, falei sobre DevOps para o CEO de uma empresa da lista Fortune 5000. Quando me preparei para a apresenta\u00e7\u00e3o, fiquei muito nervoso, pois precisava resumir anos de experi\u00eancia em 5 minutos. <\/p>\n

No final, eu dei a seguinte defini\u00e7\u00e3o de DevOps<\/b>: \u00e9 um conjunto de pr\u00e1ticas e padr\u00f5es que permite transformar o capital humano em capital organizacional de alto desempenho. Um exemplo \u00e9 a maneira como a Toyota opera h\u00e1 50 ou 60 anos.<\/p>\n

\"Sete
\n
\n(Aqui e adiante, tais esquemas s\u00e3o apresentados n\u00e3o como material de refer\u00eancia, mas como ilustra\u00e7\u00f5es. Seu conte\u00fado diferir\u00e1 para cada nova empresa. No entanto, a imagem pode ser visualizada e ampliada separadamente a partir deste link.)<\/a><\/noindex><\/i><\/p>\n

Uma das pr\u00e1ticas mais bem-sucedidas \u00e9 mapeamento do fluxo de valor<\/b>. V\u00e1rias boas obras foram escritas sobre isso, com o autor mais bem-sucedido sendo Karen Martin. Mas, no \u00faltimo ano, cheguei \u00e0 conclus\u00e3o de que at\u00e9 mesmo essa abordagem \u00e9 tecnicamente excessiva. Ela, sem d\u00favida, possui muitas vantagens, das quais me beneficiei bastante. Mas quando o CEO pergunta por que sua empresa n\u00e3o pode mudar de foco, ainda \u00e9 cedo para discutir o mapeamento do fluxo de valor. Existem muitas quest\u00f5es muito mais fundamentais que precisam ser respondidas anteriormente. <\/p>\n

Creio que o erro de muitos dos meus colegas \u00e9 dar \u00e0 empresa um guia de cinco pontos e depois voltar seis meses depois para ver o que aconteceu. Mesmo um bom esquema como o mapeamento do fluxo de valor tem, digamos, zonas mortas. Ap\u00f3s centenas de entrevistas com diretores de v\u00e1rias empresas, desenvolvi um padr\u00e3o que permite decompor o problema em partes e agora discutiremos cada uma dessas partes com calma. Antes de aplicar qualquer solu\u00e7\u00e3o tecnol\u00f3gica, utilizo esse padr\u00e3o, e o resultado \u00e9 que todas as minhas paredes acabam cobertas de esquemas. Recentemente, trabalhei com um fundo m\u00fatuo, e acabei tendo 100-150 desses esquemas.<\/p>\n

Uma cultura ruim consome boas abordagens no caf\u00e9 da manh\u00e3<\/h2>\n

\nA ideia principal \u00e9 a seguinte: nenhum Lean, Agile, SAFE ou DevOps ajudar\u00e1 se a cultura da organiza\u00e7\u00e3o for ruim. \u00c9 como mergulhar em profundidade sem um cilindro de oxig\u00eanio ou operar sem uma radiografia. Em outras palavras, parafraseando Drucker e Deming: uma cultura organizacional ruim absorver\u00e1 qualquer bom sistema e n\u00e3o se engasgar\u00e1. <\/p>\n

Para resolver esse problema principal, \u00e9 necess\u00e1rio tomar as seguintes medidas:<\/p>\n

    \n
  1. Tornar Todo o Trabalho Vis\u00edvel:<\/b> \u00e9 preciso tornar todo o trabalho vis\u00edvel. N\u00e3o no sentido de que ele deva obrigatoriamente ser exibido em alguma tela, mas no sentido de que ele deve ser observ\u00e1vel.<\/li>\n
  2. Consolidar Sistemas de Gest\u00e3o do Trabalho:<\/b> \u00e9 necess\u00e1rio consolidar os sistemas de gest\u00e3o. No problema do conhecimento 'tribal' e do conhecimento institucional, em 9 casos de 10, o gargalo s\u00e3o as pessoas. No livro \u00abPhoenix Project\u00bb<\/a><\/noindex> o problema estava em uma \u00fanica pessoa, Brent, cuja aus\u00eancia levou o projeto a um atraso de tr\u00eas anos. E encontro 'Brents' por toda parte. Para desfazer esses gargalos, utilizo os seguintes dois pontos na nossa lista. <\/li>\n
  3. Metodologia da Teoria das Restri\u00e7\u00f5es:<\/b> teoria das restri\u00e7\u00f5es.<\/li>\n
  4. Truques de colabora\u00e7\u00e3o:<\/b> truques de colabora\u00e7\u00e3o. <\/li>\n
  5. Toyota Kata (Coaching Kata<\/a><\/noindex>):<\/b> n\u00e3o vou falar muito sobre Toyota Kata. Se voc\u00ea estiver interessado, no meu GitHub h\u00e1 apresenta\u00e7\u00f5es<\/a><\/noindex> quase sobre cada um desses temas. <\/li>\n
  6. Organiza\u00e7\u00e3o Orientada ao Mercado:<\/b> organiza\u00e7\u00e3o orientada para o mercado.<\/li>\n
  7. Auditores Shift-left:<\/b> auditoria nas fases iniciais do ciclo.<\/li>\n<\/ol>\n

    \"Sete
    \n
    \nCome\u00e7o a trabalhar com a organiza\u00e7\u00e3o de uma forma muito simples: vou \u00e0 empresa e converso com os funcion\u00e1rios. Como vemos, n\u00e3o s\u00e3o necess\u00e1rias tecnologias avan\u00e7adas. Tudo que preciso \u00e9 ter algo para escrever. Re\u00fano algumas equipes em uma sala e analiso o que me dizem sob a perspectiva dos meus 7 arqu\u00e9tipos. Depois, dou a eles um marcador e pe\u00e7o que escrevam no quadro tudo o que j\u00e1 disseram em voz alta. Geralmente, em reuni\u00f5es desse tipo, h\u00e1 uma pessoa que anota tudo e, na melhor das hip\u00f3teses, ela consegue registrar 10% da discuss\u00e3o. Com meu m\u00e9todo, essa taxa pode ser aumentada para cerca de 40%. <\/p>\n

    \"Sete
    \n
    \n(Separadamente, esta ilustra\u00e7\u00e3o pode     ser vista pelo link<\/a><\/noindex>)<\/i><\/p>\n

    Meu enfoque \u00e9 baseado no trabalho de William Schneider (William Schneider, The Reengineering Alternative<\/a><\/noindex>). A base do enfoque \u00e9 a ideia de que qualquer organiza\u00e7\u00e3o pode ser desmembrada em quatro quadrantes. Este esquema \u00e9 geralmente o resultado do trabalho com aquelas centenas de outros esquemas que surgem durante a an\u00e1lise da organiza\u00e7\u00e3o. Suponha que temos uma organiza\u00e7\u00e3o com alto n\u00edvel de controle, mas com baixa compet\u00eancia. Esta \u00e9 uma situa\u00e7\u00e3o extremamente indesej\u00e1vel: quando todos seguem as regras, mas ningu\u00e9m sabe o que deve ser feito. <\/p>\n

    Uma op\u00e7\u00e3o muito melhor com um alto n\u00edvel de controle e compet\u00eancia. Se uma empresa \u00e9 lucrativa, talvez ela n\u00e3o precise de DevOps. \u00c9 mais interessante trabalhar em uma empresa que tenha um n\u00edvel alto de controle, baixa compet\u00eancia e colabora\u00e7\u00e3o, mas ao mesmo tempo uma alta cultura (cultivation). Isso significa que h\u00e1 muitas pessoas na empresa que gostam de trabalhar l\u00e1, e a rotatividade de funcion\u00e1rios \u00e9 baixa. <\/p>\n

    \"Sete
    \n
    \n(Separadamente, esta ilustra\u00e7\u00e3o pode     ser vista pelo link<\/a><\/noindex>)<\/i><\/p>\n

    Acredito que os m\u00e9todos com recomenda\u00e7\u00f5es r\u00edgidas acabam por atrapalhar a busca pela verdade. Em particular, no value stream mapping, existem muitas regras sobre como estruturar a informa\u00e7\u00e3o. Nos est\u00e1gios iniciais de trabalho que menciono, essas regras n\u00e3o s\u00e3o necess\u00e1rias. Quando uma pessoa com um marcador na m\u00e3o descreve em uma lousa a situa\u00e7\u00e3o real da empresa \u2014 esse \u00e9 o melhor modo de entender a situa\u00e7\u00e3o. Essa informa\u00e7\u00e3o n\u00e3o chega at\u00e9 os diretores. Nesse momento, \u00e9 tolo interromper a pessoa e dizer que ela desenhou uma seta de forma errada. Nessa fase, \u00e9 melhor usar regras simples, por exemplo: uma abstra\u00e7\u00e3o em m\u00faltiplos n\u00edveis pode ser criada simplesmente usando marcadores coloridos. <\/p>\n

    Reitero, nada de alta tecnologia. Com um marcador preto, a realidade objetiva \u00e9 desenhada, como tudo funciona. Com um marcador vermelho, as pessoas marcam o que n\u00e3o gostam na situa\u00e7\u00e3o atual. O importante \u00e9 que isso est\u00e1 sendo escrito por elas, e n\u00e3o por mim. Quando ap\u00f3s a reuni\u00e3o vou at\u00e9 o diretor de tecnologia da informa\u00e7\u00e3o, n\u00e3o ofere\u00e7o uma lista de 10 coisas que precisam ser corrigidas. Busco encontrar conex\u00f5es entre o que as pessoas da empresa dizem e os padr\u00f5es j\u00e1 testados existentes. Finalmente, com um marcador azul, s\u00e3o sugeridas solu\u00e7\u00f5es poss\u00edveis para o problema. <\/p>\n

    \"Sete
    \n
    \n(Separadamente, esta ilustra\u00e7\u00e3o pode     ser vista pelo link<\/a><\/noindex>)<\/i><\/p>\n

    Um exemplo desse enfoque est\u00e1 ilustrado acima. No in\u00edcio deste ano, trabalhei com um banco. Os funcion\u00e1rios do departamento de seguran\u00e7a estavam convencidos de que n\u00e3o deveriam participar das avalia\u00e7\u00f5es de requisitos e projetos (design and requirement reviews). <\/p>\n

    \"Sete
    \n
    \n(Separadamente, esta ilustra\u00e7\u00e3o pode     ser vista pelo link<\/a><\/noindex>)<\/i><\/p>\n

    Ent\u00e3o, conversamos com pessoas de outros departamentos e descobrimos que, cerca de 8 anos atr\u00e1s, os desenvolvedores de software exclu\u00edram os trabalhadores de seguran\u00e7a porque eles estavam atrasando o trabalho. E depois isso se transformou em uma proibi\u00e7\u00e3o que foi encarada como um fato consumado. Embora na realidade n\u00e3o houvesse nenhuma proibi\u00e7\u00e3o. <\/p>\n

    A nossa reuni\u00e3o seguiu um rumo extremamente confuso: por cerca de tr\u00eas horas, cinco equipes diferentes n\u00e3o conseguiam me explicar o que estava acontecendo entre o c\u00f3digo e a constru\u00e7\u00e3o. E isso deveria ser a coisa mais simples. A maioria dos consultores de DevOps presume que isso j\u00e1 \u00e9 do conhecimento de todos. <\/p>\n

    Depois, a pessoa respons\u00e1vel pela governan\u00e7a de TI, que havia permanecido em sil\u00eancio por quatro horas, de repente se animou quando chegamos ao seu tema, e nos manteve ocupados por bastante tempo. No final, eu perguntei o que ele achava da reuni\u00e3o, e nunca esquecerei sua resposta. Ele disse: \"Antes eu pensava que no nosso banco havia apenas duas maneiras de entregar software, mas agora sei que existem cinco, e eu nem suspeitava de tr\u00eas delas.\" <\/p>\n

    \"Sete
    \n
    \n(Separadamente, esta ilustra\u00e7\u00e3o pode     ser vista pelo link<\/a><\/noindex>)<\/i><\/p>\n

    A \u00faltima reuni\u00e3o neste banco foi com a equipe que lida com software para investimentos. Foi com eles que ficou claro que \u00e9 melhor escrever esquemas com um marcador em uma folha do que em uma lousa, e at\u00e9 melhor do que em um quadro inteligente. <\/p>\n

    \"Sete
    \n
    \nAs fotos que voc\u00ea v\u00ea s\u00e3o como a sala de confer\u00eancias do hotel parecia no quarto dia da nossa reuni\u00e3o. E esses esquemas foram usados para procurar padr\u00f5es, ou seja, arqu\u00e9tipos. <\/p>\n

    Ent\u00e3o, eu fa\u00e7o perguntas aos funcion\u00e1rios, e eles anotam as respostas com marcadores de tr\u00eas cores (preto, vermelho e azul). Eu analiso suas respostas em busca de arqu\u00e9tipos. Agora vamos discutir todos os arqu\u00e9tipos na ordem. <\/p>\n

    1. Make All Work Visible: Tornar Todo Trabalho Vis\u00edvel<\/h3>\n

    \nNa maioria das empresas com as quais trabalho, h\u00e1 uma alta porcentagem de trabalho desconhecido. Por exemplo, isso acontece quando um funcion\u00e1rio se aproxima de outro e simplesmente pede algo. Em grandes organiza\u00e7\u00f5es, at\u00e9 60% do trabalho \u00e9 n\u00e3o planejado. E at\u00e9 40% do trabalho n\u00e3o \u00e9 documentado de forma alguma. Se fosse a Boeing, eu nunca mais entraria em um de seus avi\u00f5es. Se apenas metade do trabalho \u00e9 documentada, n\u00e3o se sabe se esse trabalho est\u00e1 sendo feito corretamente ou n\u00e3o. Todos os outros m\u00e9todos se tornam in\u00fateis \u2014 n\u00e3o faz sentido tentar automatizar qualquer coisa, porque os 50% conhecidos podem ser a parte mais organizada e clara do trabalho, cuja automa\u00e7\u00e3o n\u00e3o trar\u00e1 grandes resultados, enquanto o que h\u00e1 de pior est\u00e1 na metade invis\u00edvel. Sem documenta\u00e7\u00e3o, \u00e9 imposs\u00edvel encontrar todos os tipos de gambiarras e trabalho oculto, n\u00e3o encontrar gargalos, aqueles Making Work Visible<\/a><\/noindex>. Ela identifica cinco diferentes \"vazamentos de tempo\"<\/b> (thieves of time):<\/p>\n