Por: Cezar Taurion

A cultura de que volatilidade é um risco ainda está entranhada no inconsciente dos profissionais que lidam com desenvolvimento de software

Nas últimas décadas, o modelo organizacional e de gestão das empresas foi baseado no conceito que estabilidade operacional, desenhado para resistir à mudanças. Quando estas eventualmente surgem, as empresas criam projetos estratégicos de longo prazo, que tentam incorporar todas as prováveis mudanças que observam estar ocorrendo. O objetivo é criar um novo modelo, também estável, que seja de longa duração. E o ciclo se repete.

O modelo mental é claro: longos períodos de estabilidade, seguido por uma ruptura de grande porte, adaptação ao novo modelo e a consequente estabilização no novo contexto.

Obviamente que este modelo mental permeou as diretrizes e modelos de governança da área de TI. Seus processos e métodos refletem claramente a busca pela estabilidade e a resistência a mudanças. A própria bíblia de ITIL diz textualmente: “Goal: ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently to improve the the day-to-day operations of the organization.” É uma visão de mudança lenta e gradual, muitas vezes suportadas por entraves burocráticos de extensa lista de aprovações gerenciais.

A pergunta então é: o velho modelo mental se sustenta em mundo onde a instabilidade torna-se a regra? Onde tempo e adaptabilidade são essenciais para a sobrevivência da empresa?

Os processos, métodos e práticas de TI estão sendo ajustados à velocidade das mudanças do cenário empresarial de hoje? A TI está preparada para enfrentar competidores digitais que surgem inesperadamente em seu “consolidado” setor de negócios?

A TI está preparada para compreender que o sucesso do negócio é indistinguível do sucesso dos seus softwares?

Cada vez mais as inovações de negócios são baseadas em software e os negócios digitais movem-se muito rapidamente simplesmente porque software muda muito mais rapidamente que coisas físicas. Este contexto afeta qualquer setor de indústria. Uns já foram afetados, outros o serão em breve. Raros serão os que ficarão mais ou menos imunes a estas rupturas. E mesmo setores que se consideram imunes estão sujeitos a rupturas quando as fronteiras entre os próprios setores de indústria começam a desabar. A competição pode vir inesperadamente, tanto de uma empresa de software, como de empresas de um setor totalmente diverso.

É um cenário desafiador para as áreas de TI e os CIOs. Seus modelos mentais foram consolidados no espírito da estabilidade e do controle rígido, mesmo às custas da velocidade. O paradoxo da TI era velocidade versus estabilidade. E estabilidade sempre ganhava. Este modelo mental prestigia a ideia que “rápido e barato” é impossível em uma TI organizada. Se quiser assim, faça fora…

O processo de desenvolvimento de software conhecido por waterfall é emblemático deste modelo. Não se dá nenhum passo sem a observância de estritas regras de controle. O ciclo de desenvolvimento e entrega de sistemas é medido em tempos adequados a era da estabilidade: meses ou em alguns casos anos. Não é adequada a uma era de instabilidade contínua.

Vamos colocar aqui um questionamento. Será que este modelo taylorista de desenvolvimento de software, com especificações rígidas e departamentalização de tarefas, tem validade no novo cenário de negócios? Atende à velocidade das mudanças contínuas que a instabilidade como regra impõe às empresas?

Há algum tempo TI vem tentando ser mais rápida. Várias empresas conseguiram adotar processos ágeis em parte do seu ciclo de desenvolvimento. Mas, apesar deste esforço, ainda não é suficiente. A cultura de que volatilidade é um risco para TI ainda está entranhada no inconsciente dos profissionais que lidam com desenvolvimento e operação de software. Esta ideia está implícita na adoção de processos disciplinados como ITIL, que fizeram muito sentido em um mundo que muda mais lentamente, mas que hoje coloca em risco a capacidade de TI ser rápida.

DevOps na veia

A resposta está em um pensar diferente. Minha visão é que processos como DevOps, que rompem com este paradigma, apontam um novo caminho para o desenvolvimento de software. Em absoluto significa jogar fora ITIL, mas entender que implementar disciplinas rígidas não podem prevalecer sobre novos processos que possibilitem o desenvolvimento ágil e rápido. Quem demanda velocidade é o próprio cenário de negócios. A solução estará no balanceamento correto da estabilidade proposta pelo ITIL e velocidade proposta pelos métodos ágeis, entrega contínua e DevOps.

Uma mudança cultural e tanto. ITIL controla o processo de mudanças reduzindo a frequência destas mudanças e disparando processos de controle se uma ocorrer. De maneira geral o processo tradicional acumula as mudanças e faz entregas de uma vez, em Big Bangs. As famosas mudanças de releases. Esta espera é uma das causas de muitas áreas usuárias investirem, não por quererem, mas por necessidade, nas famosas iniciativas de “Shadow IT”, potencializadas pela oferta de novas alternativas em nuvem, fora do alcance da rigidez de TI. Entregar tarde demais é a mesma coisa que não entregar, pois não atende à demanda do negócio: foi a solução ao problema de ontem, não ao de hoje!

DevOps tem outra visão: sua filosofia é de entrega contínua, com pequenos pedaços de código a cada vez. Considera que as mudanças no contexto de negócio acontecem tão rápido e com tanta frequência que esperar acumular todas elas é colocar em risco o negócio.

Adotar DevOps não é algo que acontece de um dia para outro. É uma mudança conceitual e de modelo mental. Demanda conhecimento de novas práticas e uso intenso de tecnologia para automatizar ao máximo o processo de desenvolvimento de software. Muitas empresas terão dificuldades maiores devido a questões regulatórias, principalmente as que atuam sem setores muito regulados. Outras com imenso legado de sistemas provavelmente manterão processos tradicionais em alguns dos seus sistemas e adotarão métodos como DevOps em sistemas “customer facing” que exploram mobilidade.

DevOps é seu modelo mental. Empresas da Internet, em todo o mundo, já nascem desta forma: basta analisar os exemplos como Facebook, Google, Etsy, Amazon, NetFlix, Salesforce, Twitter e outras. Esta é uma sugestão: usá-las como benchmarks. Provavelmente a imensa maioria das empresas não serão Facebooks, mas porque não considerar estas empresas da Internet como benchmarks? Podemos aprender muito com elas e adaptar o que seja possível a para realidade das nossas organizações.

O primeiro passo é reconhecer que o modelo mental atual já envelheceu. O segundo é a decisão de mudar. DevOps envolve novas práticas como (a) entrega contínua de novas funcionalidades, em doses pequenas, (b) uso de equipes dedicadas, cross-functional e pequenas, (c) arquitetura loose coupling, (d) ambiente automatizado por excelência, (e) integração e testes contínuos e (f) ambiente interativo e colaborativo, com usuários, operação e desenvolvimento atuando em conjunto, sem fricções entre os setores, como vemos hoje.

A partir daí preencher o gap de expertise, adotar tecnologias para automatizar os processos e fazer as mudanças culturais e organizacionais, lidando com as inevitáveis barreiras psicológicas (reação adversa à mudanças no status quo, descrença, etc). Mas o fato é que a TI de hoje não pode mais atuar como a TI desenhada há 20 anos atrás. Simplesmente porque o mundo de hoje não é mais o que era há 20 anos!

Fonte: ComputerWorld

Texto original:
http://computerworld.com.br/por-que-o-velho-modelo-mental-da-ti-nao-serve-em-uma-cultura-de-devops