O mundo está cheio de pessoas felizes, sorridentes, as redes sociais estão abarrotadas por todos os lados de adoradores de potássio(1). Acho que é hora de falar do mundo real, e de algumas frustrações.
A minha ausência se dá a um caso bem complexo na carreira, quando após entregar uma plataforma inteira, completamente escalável, altamente configurável e robusta, permitindo um ganho de mais de 1000% (mil) na capacidade de processamento da empresa, esbarrei em aspectos políticos, e na necessidade de manutenção do caos, exercida por alguns e alguns.
Ao sair da BRQ, em 2012, após mais uma entrega do Oragon Architecture, aproveitei a ociosidade para relaxar. Desde 2008 não tirava férias, portanto enquanto procurava algum projeto interessante para tocar, aproveitei para curtir 3 meses de muita paz. Claro, a cada dia que passava, essa paz se esvaía um pouco, dinheiro não era tão abundante ao ponto viabilizar um ano sabático, e portanto em algum momento me vi obrigado a buscar algo no mercado.
O caos
Em fevereiro de 2013 comecei minha jornada em uma grande empresa de mídia digital, uma startup que estava para ser comprada (eu não sabia disso na época), mas que sofria com o crescimento desordenado e desestruturado. O resultado é uma TI caótica: Muitos bancos de dados, dados duplicados, inconsistentes, mal modelados, muitas aplicações em muitas tecnologias, nenhuma plataforma unificada, apenas uma infinidade de executáveis, soltos, criados em quase todos os cenários sob o Gambi Pattern RCP, nenhuma coesão, nenhuma gerência de configuração, eram poucos os projetos que estavam atualizados no vovô SubVersion, nenhum servidor devidamente mapeado, e algumas soluções, sequer tinham código-fonte. Mediante o caos, fiz o de sempre: Gerencia de Configuração, Integração Contínua, Deploy Contínuo e reestruturação completa. Esse caos perfeito para criar uma plataforma unificada e robusta, com toda a gestão e controle, mas toda essa mudança exigia, naturalmente, muito trabalho e muito suor.
Para quem me conhece, sabe que eu sou workaholic, sou apaixonado pelo que faço e meu tesão é entregar muito com pouco, sem perder em qualidade. Minha intenção é “quebrar o sistema” dos 3 pilares, mostrando que é possível ser barato, rápido e bom. Para a maioria desses casos eu uso meu projeto pessoal, público, chamado Oragon Architecture. Sem entrar em detalhes, ele é minha caixa mágica de ferramentas, e há anos me dedico a usá-lo pra transformar pequenos projetos fracassados em escalabilidade e robustez em plataformas robustas e escaláveis. Ao longo do tempo escalabilidade se tornou um vício, tanto quanto a otimização do tempo de desenvolvimento. Graças a ele, pude pegar uma equipe que estava presa tecnologicamente em 2004 e fazê-la produzir bem com tecnologias de 2014. Para a maioria, ORM era um acrônimo esquecido em sua lista de materiais a serem estudados, AOP, um tema novo, talvez para poucos, uma lembrança da faculdade. Orientação a Objetos era definitivamente algo impensável. Embora sempre houvesse uma demanda muito grande por prazo, sempre foram os desenvolvedores que deram seus prazos ali. O compadecimento para com a estratégia de negócio era tão grande, que eles mesmos, tinham atitudes cancerígenas para o crescimento da empresa. Não fazer a coisa certa, gera um débito a longo prazo, e era notório, que o fim dos tempos estava próximo, o colapso era apenas uma questão de tempo.
Optar pelo comodismo de copiar e colar projetos inteiros, fazendo apenas pequenas mudanças, sem versionamento, ou simplesmente proliferando novos aplicativos que corrigiam brechas que aplicações antigas geravam, fazia parte do dia-a-dia. Levando em conta que estou falando de um backoffice, de uma plataforma de integração de conteúdo digital, absolutamente nada era executado sem que houvesse uma intervenção humana, nem que fosse para reconfigurar um único parâmetro e iniciar um processo que propositalmente tivesse sido parado ao fim da tarefa anterior. Sem filas (MQ), sem inteligência, sem automação. Mais à frente eu vou mostrar um mapa estratégico que criei para demonstrar as ações realizadas ali.
O que é atender aos interesses do negócio?
Atender aos interesses do negócio exige estratégia. É necessário ponderar entre o MVP sem fazer gambiarra, sem copiar e colar projetos inteiros. Ou se fizer, e sou totalmente contrário a essa abordagem, que o faça com o auxílio de um backlog de débito. Para corrigir aquilo que foi feito da forma errada.
E que esse backlog seja cada vez menor, pois se esse backlog crescer indefinidamente, será apenas um bloco de anotações que justifica a gambiarra alheia, cada item será apenas um grão de areia na praia.
Se de antemão você sabe que não há como atender a esse hipotético backlog, seja pela quantidade das demandas do dia-a-dia ou pela má gestão, então não o crie-o, simplesmente passe a fazer a coisa certa, sob a conseqüência inevitável do acréscimo de esforço, e prazo. Basta um único débito, morando no backlog por mais de X meses, para que você possa ter a certeza de que não pode trabalhar com um backlog de débito técnico.
Eu compreendo e aceito a diferença entre as pessoas, na forma como elas enxergam seu papel em uma corporação. Pessoas são complexas, são diferentes, usei o conceito do backlog como meio de viabilizar que essas pessoas tomem ciência a respeito da dimensão daquilo que estão fazendo e que atentem para a quantidade de obras não completas, que são criadas em empresas com esse perfil. Não é difícil compreender que essas pessoas entregam tudo incompleto. Faça uma única vez.
A missão
Bom, aceitei o desafio e já trabalhara nessa empresa em outro momento. Na época, era para a reestruturação da plataforma de e-commerce em .net. Dessa segunda vez, o target era o BackOffice. Eu não caí no canto da sereia, tinha total consciência de que o desafio era enorme, mas me venderam a ideia de que a empresa precisava se modernizar e investir em excelência, esse foi o principal motivador para embarcar nessa aventura. Acredito que a capacidade de entrega, tenha sido o fator fundamental para o incômodo das pessoas. Foram muitas e muitas madrugadas, programando, entendendo, refatorando código de negócio para que pudesse chegar a um produto escalável e totalmente configurável. Me dediquei prioritariamente aos projetos que impactavam mais a equipe, aqueles que demandavam muitas horas de trabalho braçal, para que pudesse reconverter, programadores, agora usados como digitadores, em programadores novamente.
A estratégia
Bom na contramão de tudo o que é pregado pelo mercado e por pensadores da área, eu não me aprofundo no negócio em si, mas apenas na visão tecnológica que o negócio precisa. Gosto de conversar com desenvolvedores que conhecem a fundo o negócio. Assim posso tirar minhas dúvidas com quem entende, essa é a forma que encontro para sempre ter uma visão agnóstica e imparcial, e assim evitar que o dia-a-dia me corrompa, esse é um vício muito comum em desenvolvedores, e por isso eles esquecem que o papel deles é viabilizar negócios com a tecnologia, mas de forma sustentável. A sustentabilidade da tecnologia tende a morrer quando você se aprofunda demasiadamente no negócio, esquece padrões, esquece boas práticas, e começa a proferir jargões como:
- “É só um programinha”
- “É só uma coluna, numa tabela”
- “É só um campo”
- “É só uma telinha”
- “É só chamar esse método aqui também”
Não sejamos hipócritas, há realmente casos em que é somente isso, mas na maioria das vezes definitivamente não! E em breve aquele programinha, tabela, coluna, tela, vira um programa inteiro. É preciso compreender a essência das demandas, pois muitas vezes requisitos incompletos geram esse tipo de caos. Mas venhamos e convenhamos: Você não é mais garoto para cair nessa história, certo?
Acima, como você pode ver clicando na imagem, criei um mapa estratégico, que mostra quarter-a-quarter, como a transformação foi conduzida. De cima pra baixo, a primeira camada apresenta os sintomas, positivos e negativos. Todos os restantes, mostram ações, e problemas. Em verde, pontos positivos, sejam soluções ou ações, em vermelho negativos, também em soluções ou ações. A realidade é que todo um trabalho de background foi necessário para efetivamente tornar a plataforma apta a expor interfaces para usuários finais. Muita coisa foi feita para tornar possível ter um fluxo de ALM decente e uma gestão efetiva sobre tudo o que nascia ali. Não demorou muito, com a estratégia montada, e apresentada, me deparei com barreiras políticas. De junho a setembro de 2014 tive uma dificuldade muito grande de entregar resultado, esbarrei nos interesses pessoais de alguns.
A frustração
A manutenção do caos é fonte de emprego de muitos, e estava claro que estávamos no caminho certo, mas cada vez mais sucateados, sem recursos para seguir em frente. Contando com uma infraestrutura dedicada, ínfima, sem previsão de disponibilidade. Entendi que a reestruturação era para ser limitada, eu não poderia esbarrar na ambição dos outros. O que é extremamente curioso, já que eu nunca almejei cargos executivos ou mesmo gerenciais. Meu interesse há algum tempo é criar um grande portfólio com o Oragon Architecture, que nesse caso era um case de sucesso, permitindo processar cada vez mais conteúdo, mais requisições, com maior paralelismo, suportando cada vez mais usuários e integrações, gerando impacto para a empresa e consequentemente para mercado. Organizacionalmente nunca me vi em uma posição que me deixasse afastado do código, gosto de código, sou apaixonado por código, e não me vejo longe dele.
Tentando contornar o incontornável
Não bastava ter aumentado vertiginosamente a capacidade de processamento do BackOffice (área de TI destinada às demandas de desenvolvimento para a plataforma interna e plataforma de suporte ao negócio), minha abordagem não estava preparada para lidar com facilidade com balanceamento de carga desigual, ou baseado em afinidades e requisitos. Eu vi na limitação da infraestrutura para a minha área, na impossibilidade financeira da utilização de cloud, uma possibilidade brilhante de fazer ainda mais. Possibilitar alocar grupos de máquinas por afinidade e localidade, de forma dinâmica, e permitir que a ociosidade em um ou outro nó, pudesse ser usada, eventualmente, sem a necessidade de redefinir um set inteiro de configurações. Eu vi a necessidade de viabilizar essa gestão, com alguns clicks. Assim nasceu o Oragon 7, contando agora não com apenas um Application Host, mas uma infraestrutura que mais se aproxima de um Application Server.
A versão anterior já permitia usar a infraestrutura de forma mais eficiente, garantindo o processamento contínuo e interrupto, mas não estava pronta para suportar variações de carga sem a necessidade de intervenção humana, ou para subir um novo worker, ou para reconfigurar um consumidor para atender a um outro segmento de filas. Essa dinâmica precisava ser totalmente automatizada. Mas a nova versão estava sendo criada para atender essa demanda e mesmo com mais de 70% do projeto desenvolvido e testado, fui barrado sumariamente quando quis apresentar o projeto para a presidência da empresa. Numa startup, onde a presidência estava na sala ao lado, fui sumariamente reprimido, com o pretexto de estar cometendo um bypass.
Minha intenção era mostrar que poderíamos não só sair do débito moral, mas alcançar um patamar de automação de dar inveja a concorrentes, podendo inclusive criar uma nova oferta de serviço, assim como alguns concorrentes o fazem. Minha intenção nunca foi sair do BackOffice , mas ter autonomia suficiente para transformar o BackOffice por si só, no lugar lhe é de direito, o coração da empresa, e com potencial para ser uma empresa inteira, e enxuta. Como disse, nunca me vi em uma posição qualquer que estivesse distante do código, é lá que eu moro, mas admito que aprendi ao longo do tempo a ter uma ambição muito grande por estratégia empresarial, e mesmo parecendo, ao primeiro olhar, conflitante, não é, é o futuro.
A anarquisição(2) – De funcionário do Ano a decepção do Ano
Onde mora o sucesso, pode morar a frustração. Em 2013, ganhei o premio de funcionário do ano, isso me abriu portas para expandir a minha atuação dentro da área, já que tinha autonomia parcial sobre algumas estratégias. De fato, 2014 foi um péssimo ano, a anarquisição(2) gerou medo de fazer a coisa certa em muitos, a intenção insana de manter as aparências, fazia com que muito trabalho burro fosse realizado, a troco de não entregar o que fosse realmente estratégico. Ter ciência de que estávamos dedicando mais de 40% do manpower em trabalhos burros, que poderiam ser automatizados, deixando de crescer com estratégia me tira o sono, me tira o humor, me tira a vontade.
Sou um tanto pragmático quanto a manutenção do caos, e por isso transito entre projetos e empresas com certa freqüência: Ou eu acabo com o caos, e então não tenho mais o que fazer, ou o caos acaba comigo e já não quero mais fazer. Sou movido a desafios, o caos só tem uma finalidade para existir: me abrir portas para eliminá-lo.
De fato encaro cada desafio pelo potencial de realização pessoal dentro daquele contexto, nessa empresa, meu desafio pessoal era bater de frente com grandes nomes do mercado, como Apple e Sony, provendo uma capacidade de processamento nunca vista na empresa, e uma capacidade de automação jamais vista pelo mercado. Meu case, era transformar o pior BackOffice do mundo da mídia, no melhor, tão simples quanto isso. E ao chegar no objetivo, queria melhorar, aumentar a distância entre nós e os concorrentes, talvez exportando projetos, tecnologias, e mindset.
Lamentável, mas assim reencontrei uma antiga amiga, chamada depressão, a frustração me consumia. Por fim, em novembro de 2014, optei por abandonar o barco, avisando apenas em janeiro. Ainda fiz uma das piores coisas que poderia ter feito, avisar com antecedência demasiada, minha saída. As 8 semanas seguintes/restantes para a minha saida foram algumas das piores semanas que tive na minha vida profissional. Meu corpo sucumbia à dissonância cognitiva, e já não fazia mais sentido algum, acordar, trabalhar, entregar, enfim, me doar. Para qualquer workaholic que se prese, a principal motivação, é fazer sentido!
E assim eu andei, andei frustrado!
Sei que é uma leitura densa, chata, e muito pessoal.
Mas, obrigado, obrigado por ler-me.
0 comentários