Nos últimos anos vivemos mudanças significativas que irão afetar de forma dramática o uso da tecnologia. Primeiro lembramos que a crise econômica de 2008 afetou todos os paises e que obrigou a todas as empresas a buscarem o “fazer mais com menos”. Isto levou ao questionamento do atual modelo de contratação de tecnologia, tanto de software como hardware. Provocou a rápida disseminação do modelo de cloud computing. Afinal porque a empresa deve assumir elevados custos upfront e somente usufruir o resultado muito tempo depois deste gasto? Depois tivemos o iPhone. Pode não parecer, mas de repente todos nós vimos que a tecnologia poderia ser fácil de ser usada e trazer um app era simplesmente busca-lo de uma App Store e baixa-lo. De imediato começamos a questionar porque os sistemas corporativos são tão complexos, sem intuitividade de navegação e exigem uma burocracia imensa e lenta do setor de TI para serem colocados em produção ou mesmo para requerer uma simples modificação…
A junção destas mudanças está desafiando os conceitos tradicionais de desenvolvimento de software. Claro que toda mudança traz certo desconforto, principalmente para quem está desenvolvendo há muitos anos no modelo atual, cliente-servidor, com metodologias e práticas bem arraigadas.
A atual e predominante estrutura organizacional de TI separa desenvolvimento e teste da operação. Embora esta organização seja adequada a sistemas complexos e com ciclos demorados de atualizações, não se encaixa em um mundo que demanda desenvolvimento ágil e rápido, para ambientes móveis. O ambiente de negócios está cada vez mais fluído e não existe mais tempo para se esperar 2 a 3 anos por um sistema. As demandas do negócio requerem respostas praticamente imediatas.
Este ritmo intenso e rápido bate de frente com as estruturas atuais, burocráticas e lentas nas resposta. Além disso, o ambiente de desenolvimento para apps demanda novas capacitações, com o foco do desenvolvimento cada vez mais centrado na experiência do usuário. Este paradigma praticamente não existia nos interfaces teclado-mouse do modelo cliente-servidor. Basta ver que quase não existe hoje, na maioria das tradicionais equipes de desenvolvimento, funções como UX designers ou designers voltados para User Experience.
É um desafio, pois elas tem ao mesmo tempo manter seus sistemas legados e criar novas apps, estas em um contexto diferente da qual estão acostumadas. Tem que conciliar processos voltados para grandes e complexos sistemas com métodos ágeis. Além disso, o cenário da mobilidade é bem mais diverso do cliente-servidor, com mais ambientes operacionais e tecnologias de interação com o usuário surgindo a cada instante. Devido a escassez de capacitação interna, a provavel primeira ação será contratar desenvolvimento de apps de terceiros, mas será esta a resposta estratégica para a empresa? Não dominar os conceitos de desenvolvimento móvel? Observei que no Brasil a maioria das empresas especializadas em desenvolver apps são de pequeno porte, sem muito conhecimento de negócios. Formam um pool de jovens e brilhantes engenheiros de software sem experiência corporativa. Mas como interagir com os executivos das linhas de negócio para atender suas demandas? Como integrar estas apps com os sistemas legados que são o mainstream das empresas?
Na minha opinião é necessário um repensar da estrutura organizacional de TI, no que tange a organização e processos de desenvolvimento e operações. Primeiro, está claro que a esmagadora maioria das futuras aplicações serão para ambientes móveis, explorando a potencialidade destes dispositivos e não apenas os usando como meio alternativo de entrega de informação. Estas apps serão integradas aos sistemas legados e não isoladas. O Gartner diz que em 2015 (praticamente amanhã…) 80% de todas as atividades de desenvolvimento serão direcionados para ambientes móveis. Depois é necessário amplo dominio de processos ágeis e modelos mentais baseados em MVP (Minimum Viable Product), com desenvolvimento em eterno beta. É uma mudança de paradigma nos modelos mentais de desenvolvimento de sistemas, que chegam a “congelar” novas requisições para terminar o projeto. Terceiro, o maior foco na experiência do usuario demandará novas funções (o UCD, ou User Centered Design será o cerne dos projetos de sistemas daqui para a frente. A propósito, como ponto de partida deem uma olhada no site da Usability Professionals), e por ultimo cada vez mais será necessário um processo automatizado e colaborativo que integre desenvovimento/teste com operações. Nós o chamamos de DevOps. Abordei o assunto em posts anteriores, mas devido a sua importância, retorno a ele aqui.
DevOps é o modelo que consegue, pela automatização, construir um ciclo continuo de desenvolvimento e delivery de sistemas. O processo de update tende a ser cada vez mais frequente e continuo. Não se espera mais frequências maiores que mensais… Talvez cheguemos até a frequência de updates semanais ou diárias…No modelo tradicional, o setor de desenvolvimento e teste é responsável pelo desenvolvimento e teste, e apenas na fase de deployment é que interage com o pessoal de operação. A partir dai a operação passa a ser o responsável pela execução do sistema. Portanto, desenvolvimento/teste e operações atuam em silos, bem separados, com pontos bem especificos de interação e colaboração. No DevOps o processo é colaborativo em todo o ciclo de vida do sistema. As equipes interagem desde o inicio. Mas, observem: não significa, como muitos pensam, que o desenvolvedor vai operar o sistema e nem que o pessoal de operações vai escrever código JavaScript…. O processo é que é colaborativo. O próprio ambiente de nuvem é um acelerador do processo DevOps.
DevOps não é futurologia. Uma recente pesquisa do Forrester em grande corporações americanas mostrou que 76% já tinham um estratégia ou mesmo uma solução para DevOps. E a maioria a aplicava em ambiente de nuvem. Vale a pena ler também este texto. Esta pesquisa sobre DevOps também é interessante
Na prática DevOps busca atender a demanda prioritária das empresas: desenvolver sistemas inovadores cada vez mais rápido. É questão de sobrevivência. Uma sugestão a mais: acessem para um caso real de uma empresa de um setor altamente regulado e considerado mais conservador, que é o de seguros. Vale a pena ler e analisar esta experiência. Você não precisa estar em uma empresa do mundo Internet como NetFlix ou Amazon para implementar DevOps. O conceito é altamente válido para toda e qualquer empresa.
[Crédito da Imagem: Desenvolvimento – ShutterStock]