Trabalho com tecnologia da informação desde 1992 (caramba! 26 anos já!). Lá no início e durante boa parte da minha carreira, na transição de sistemas centralizados baseados em Mainframe para computação distribuida, impulsionada pela popularização dos PCs, as equipes de desenvolvimento de aplicativos trabalhavam no mesmo lugar e todos eram responsáveis por todas as partes do aplicativo (banco de dados, interface de usuário, segurança, fazia os testes, etc.), bem como todos eram também responsáveis por fazer a análise do sistema, a arquitetura, a implementação e o suporte. Se o aplicativo era muito grande ou complexo existiam pequenas equipes cuidando de partes do sistema (o cadastro de usuários, interface com outras aplicações, relatórios, etc.), mas cada uma destas pequenas equipes (que tinham uma coordenação central) cuidava de todos os componentes e fases.

Entre o final dos anos 90 e início dos anos 2000, com a onda de reengenharia e terceirização, algum “guru dos negócios” (que nunca deve ter escrito um “hello world” na vida) resolveu achar que separar as funções iria trazer algum ganho. E como ocorre muitas vezes na área de tecnologia (em geral, não só da informação), alguém em algum posto alto tem uma idéia e força a implementação sem a menor idéia de quais as consequências na execução do plano. E como geralmente ocorre no meio empresarial, basta um fazer para todo mundo copiar.

Depois de uma década de projetos infinitos e bilhões de dólares desperdiçados em aplicativos que nunca se estabilizam (isto quando não são abandonados), finalmente chegaram à conclusão de que era melhor da forma antiga (ah vá!). Foi quando surgiu o movimento DevOps, que no fundo é uma volta àqueles tempos (com o auxilio de tecnologias e metodologias recentes para aumentar a produtividade da equipe). Alguns destes métodos já são utilizados há décadas em manufaturas e cairam como uma luva em TI. A Teoria das Restrições (Theory of Constraints) traz alguns destes métodos e ferramentas.

The Phoenix Project traz as agruras causadas por esta segmentação (time de desenvolvimento, de suporte/operações, de segurança, de testes, etc.) e a transformação deste modelo novamente para um modelo de times integrados, responsáveis por todos os componentes e fases do ciclo de vida de um software, inclusive além das fronteiras de um projeto (ou melhor ainda, não limitados por um projeto). Mas o legal do livro é que ele faz isto através de uma estória, com personagens, enredo, ambientação, início, meio e fim. E é impossível para quem viveu os dois mundos (ou três, se considerar o estado anterior, como no meu caso) não identificar as situações e os personagems e fazer paralelos com situações vivenciadas e pessoas com as quais trabalhamos ao longo da carreira. O livro é tão interessante que cheguei a ler 60 páginas de uma vez só, pois ao final de cada capítulo tinha um gancho que me fazia ler o seguinte.

O livro é interessante mas deixa uma sensação de “não precisava ter passado por isto”, já que a maioria das pessoas que “botam a mão na massa” já imaginava que a segmentação era uma aposta muito arriscada. Dá vontade de soltar um “eu não disse?”. Como disse o CIO da minha empresa outro dia, “DevOps é tão anos 90!”

Be happy 🙂