O Projeto Unicórnio

Ano passado, li O Projeto Fênix e postei aqui minhas percepções sobre o livro. Agora, finalizei O Projeto Unicórnio – outra produção de Gene Kim – o mesmo autor do O Projeto Fênix. Gostei igualmente dos dois livros. Acho que eles se complementam, e nos próximos parágrafos, comento um pouco sobre a trama e os pontos de conexão entre as obras.

No O Projeto Fênix, acompanhamos a trajetória de Bill Palmer, executivo de TI da Parts Unlimited – uma gigante do setor automotivo, – que enfrenta um período complicado frente a um mercado em constante evolução e que exige resultados financeiros que a companhia tem dificuldade para entregar. O "salvador da pátria" seria o Projeto Fênix, com a promessa de revolucionar a maneira como a organização interage com seus clientes, oferecendo um sistema de E-Commerce robusto e totalmente integrado com as demais áreas e plataformas da empresa. No entanto, devido a uma série de problemas estruturais – principalmente envolvendo processos, metodologias e comunicação – entre as áreas de operações e desenvolvimento de TI –, somado ao total desalinhamento com as expectativas e prazos das áreas de negócio, o go-live do projeto não é tão bom quanto o esperado. Isso faz com que diversos princípios sejam revistos, provocando uma mega reestruturação na TI; iniciativa que foi chamada de Projeto Unicórnio.

 

O Projeto Unicórnio – Um Romance sobre Desenvolvedores, Disrupção Digital e Sucesso na Era dos Dados

No livro que leva este nome, somos apresentados a Maxine Chambers – uma conceituada engenheira de software –, que acabou sendo realocada na estrutura de TI da companhia, onde se deparou com inúmeras falhas de planejamento, processo, comunicação e controle de qualidade – os bastidores do Projeto Fênix.

Enquanto em O Projeto Fênix conhecemos a história do ponto de vista de Bill, em O Projeto Unicórnio, acompanhamos pelo olhar de Maxine. Em O Projeto Unicórnio, alguns personagens que conhecemos no O Projeto Fênix aparecem – como o próprio Bill –, mas o contrário não acontece, pois apesar da cronologia da história relatada por ambos ser a mesma, O Projeto Unicórnio foi escrito depois do O Projeto Fênix.

Maxine – na sua jornada – encontra o mesmo mentor que ajudou Bill no primeiro livro. Um figurão chamado Eric, que apresenta à engenheira ao que é chamado de Os Cinco Ideais. Junto com alguns colegas – que compartilham dos mesmos incômodos experimentados por Maxine em relação a estrutura da empresa e a maneira que lidam com tecnologia e negócios, é formado um grupo de trabalho independente. Este time – inicialmente intitulado de A Rebelião – usa os ideais de Eric para fazer a diferença, trazendo à tona iniciativas de inovação nunca antes pensadas pela organização tradicional de TI, o que acaba sendo fundamental para a eficiência e os resultados financeiros requeridos para a empresa retomar sua posição no mercado.

Preciso ler um livro antes do outro?

O autor – Gene Kim – comenta na apresentação de O Projeto Unicórnio que não é necessário ler O Projeto Fênix primeiro. Não há uma dependência entre os livros. Retomando o que comentei, a história contada por ambos é a mesma, mas de pontos de vista diferentes. Avalio que isso foi muito bem-feito pelo autor, o que de modo algum faz com que um livro anule o outro ou mesmo não compense ler ambos.

P.S.: Um disclaimer que faço – e isso já havia me incomodado um pouco em O Projeto Fênix – é a tradução para português. Alguns termos mais técnicos – a maneira como são traduzidos não é a mais adequada. Contudo, compreendo que é complexo acertar este ponto e sei que há a versão em inglês também disponível. Mesmo assim, deixo aqui meu ponto de atenção quanto a isso, caso a sua ideia seja ler em português.

O Projeto Fênix e suas perspectivas realistas sobre a TI

Publicado em 2013, O Projeto Fênix, respondendo pelo título original em inglês, The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, foi um livro escrito por Gene Kim, Kevin Behr e George Spafford.

Como a própria obra traz no subtítulo – Um romance sobre TI, DevOps e sobre ajudar o seu negócio a vencer – trata-se da narrativa de Bill Palmer, um gestor de TI, que do dia para noite, se vê promovido ao cargo de head de operações de TI da Parts Unlimited, uma grande indústria de peças automotivas. Junto da sua nova posição, Bill recebe das mãos do CEO da empresa, o desafio de colocar em produção o Fênix, um projeto dado como mandatório para que a organização reconquiste seu valor no mercado.

Ao assumir a nova posição, o personagem depara-se com uma TI totalmente desorientada. Alguns exemplos da situação encontrada refletem em processos ITIL não sendo seguidos, não conformidade com auditorias e regulatórios, profissionais sobrecarregados e um backlog de atividades confuso, constantemente em conflito com prioridades internas e de negócio. 

Além da situação descrita, Palmer percebe que durante as tentativas de implementação de funcionalidades em sistemas e produtos corporativos, o desalinhamento entre desenvolvimento e operações de TI é nítido – e isso sem falar na baixa qualidade das entregas e a ausência no cumprimento de requisitos não funcionais.

Livro: O Projeto Fênix

No desenrolar da trama, o líder é apresentado a um consultor, que ao longo da sua jornada junto deste figurão, descobre que a TI tem muito mais um comum com a esteira de produção de uma fábrica, do que ele poderia imaginar. E com isso, lições valiosíssimas são aprendidas, comportamentos estes que vão ao encontro do que no livro eles chamam de “3 maneiras” e “4 tipos de trabalho". Juntamente disso, inúmeros outros aprendizados que promovem a TI, de uma área isolada, para uma aliada estratégica do negócio, são apresentados.

E vale mesmo a leitura?

Sim, muito! Mas vou confessar: Já faz mais de um ano que eu estava com essa leitura em andamento. Terminei semana passada. Logo no início, quando comecei, apesar de não ocupar um cargo de gestão, me identifiquei tanto com a história, que ao invés de estar me fazendo bem, acabava tendo um déjà-vu do que eu observava e algumas vezes até mesmo vivia durante meu dia a dia no trabalho. E isso me deixava desgastado e apreensivo, tanto que eu acabei parando de ler por um tempo.

Certamente quem é de TI também vai se identificar com os relatos, pois a abordagem é bastante realista, e apesar de nem sempre deixar tão explícita a prática adotada, é possível perceber do que se trata. Um pouco também pode ser a tradução, por sinal, essa sendo a minha única crítica, pois em alguns momentos parece meio “dura”. No final do livro, após os agradecimentos, os autores deixam registrado um guia dos recursos utilizados para construção de todo a composição, o que certifica a legitimidade do conteúdo.

DevOps e o que circunda essa cultura

Como já falei por aqui, DevOps está mais para uma cultura do que uma área, um processo ou até mesmo um framework. O assunto me interessa bastante, assim como metodologias ágeis e Transformação Digital, temas que estão totalmente conectados.

Ainda essa semana, vi que a CertiProf estava oferecendo a certificação DevOps Essencials de forma gratuita. Para me preparar, segui os conhecimentos predispostos no guia de preparação oferecido também pela entidade.

No entanto, não me atentei ao prazo, e ontem, ao tentar acessar a prova, percebi que não estava mais disponível. 😩 Presumo que deva ter ficado apenas durante os últimos dias do mês de julho/2020.

Em todo o caso, às leituras que fiz desde então, certamente não foram perdidas, pois revisitei conceitos como PDCA (Plan, Do Check, Act), JIT (Just in Time), SPT (Sistema de Produção Toyota), Bimodal (Gartner), além de WIP (Work in Progress), Definição de Pronto, Scrum, Kanban e até mesmo ITIL. Segundo o guia, todos esses termos sustentam a cultura DevOps. O material compreende uma breve definição de cada um deles, relacionando a uma noção geral do que é preciso para entender e implantar DevOps nas empresas.

Além disso, o conteúdo supracitado também traz uma visão analítica do modelo tradicional de trabalho (desenvolvimento de um lado e operações do outro), quando existe uma área dedicada a DevOps (como uma camada intermediária), e também, o que é apontado como modelo ideal, tudo funcionando em DevOps.

Modelo tradicional de trabalho: Desenvolvimento de um lado e Operações do outro

Equipes dedicadas a DevOps: Como uma camada intermediária

Tudo funcionando em DevOps

Me agrada o fato da DevOps prezar pela colaboração, transparência e comunicação no desenvolvimento de uma atividade. Quanto a rápida adaptação às mudanças, considero que mudar é bom, pois sempre existem oportunidades de crescimento em cada mutação, mesmo que algumas vezes, meu lado conservador tente impor a ideia de que a metamorfose assusta, traz dor de cabeça e desconforto.

O único ponto disso tudo que ainda necessita lapidação quanto ao meu entendimento é a exigência dos profissionais em serem multifuncionais e multidisciplinares. Na verdade, no cenário proposto, entendo o fato de não haver mais espaço para especialistas na tecnologia "A" ou "B", mas profissionais que entendam das tecnologias "A", "B", "C", D" e "E". Contudo, não haver mais pessoas especializadas em determinadas ferramentas ou áreas de atuação, me preocupa, pois existem esferas de conhecimento tão complexas que em uma crise, por exemplo, acho que um expert pode fazer toda a diferença e perceber comportamentos que um generalista não encontraria. Mas isso é assunto pra outro post.

Como se aplica Agilidade e DevOps em uma teia de aranha?

Semana passada participei de um webinar voltado ao entendimento dos desafios e aprendizados da transformação digital nas empresas. Considerando que Agilidade e DevOps estão fundamentalmente conectados com este tema, a imagem abaixo surgiu como uma reflexão.

E aí, se identificou com essa realidade? As etapas sugeridas fazem sentido?

E assim, nasceu o Docker

Sim, o Docker. Aquela plataforma "famosinha" entre a galera de DevOps, por sua característica de implementar com agilidade aplicações em um ambiente segregado da máquina original, com o uso de containers (recurso computacional necessário para rodar uma aplicação). O mascote da empresa é uma simpática baleia azul. 😎

DevOps pra combater os silos

Nessa semana participei de um webinar promovido por um fornecedor da empresa onde eu trabalho, no qual, o tema abordado foi Transformação Digital e DevOps. A agenda foi composta por definições, vínculos com a ferramenta desse parceiro e de uma demonstração prática.

Vamos focar na definição. Transformação Digital e DevOps são assuntos que frequentemente aparecem nas conversas que a equipe em que eu trabalho tem com gestores e áreas técnicas da companhia. Afinal, parte do nosso papel como uma área de Governança de TI é compreender os relacionamentos e participar ativamente de todo e qualquer movimento provocado pela TI, assim como também, na TI.

Achei bacana o ministrante defender que DevOps não se trata de uma ferramenta, um padrão ou um produto, mas sim, uma cultura entre os Times de Desenvolvimento (Dev) e Operações (Ops) que suporta a criação de diversas práticas, a fim de promover a "quebra" dos silos presentes em uma organização.

 Saga de um código entre silos

O grande objetivo da DevOps é manter um pipeline contínuo, promovendo a interação entre os profissionais envolvidos em um projeto, no intuito de compreender a construção, a integração, o monitoramento, os testes e a implantação de um produto, serviço ou componente.

Cultura DevOps

A cultura DevOps, faz parte da Transformação Digital, que como eu defendi ao longo do meu TCC (mesmo que não mencionando diretamente esse termo) beneficia os consumidores com entregas mais rápidas e contínuas. Face a isso, existe uma realidade onde as pessoas estão cada vez mais impacientes, informadas e exigentes, o que provoca uma reação dinâmica em uma esfera que até então não estava  preparada para lidar com esse movimento, mas que aos poucos está se adaptando.