Diego Voltz
Diego Voltz, VP of Technology Umbler

Inside Umbler #4: a metodologia ágil dos times – Parte 1

Há três anos quando nascia a Umbler, tínhamos em mente a dominação mundial. Nossos objetivos estavam muito claros: tínhamos ambição, determinação, experiência de mercado e alguns grandes desafios pela frente – desafios jamais enfrentados por nós. Na época, estávamos replicando muitas de nossas ações do passado sem perceber, foi então que os mesmos problemas começaram a aparecer logo após o lançamento da marca.

Buscando uma alternativa para controlar o caos, resolvemos apostar em times ágeis. Essa história você confere aqui.

O velho e conhecido problema da indústria de TI

Sysadmins mantém. Desenvolvedores fazem features. Cada um em sua sala com suas tarefas. Até que, um belo dia, alguém quer implantar um novo sistema ou colocar uma nova feature no ar.

É sexta-feira, Deivid (Dev), finalmente termina de codificar aquela feature que com certeza vai alavancar a empresa. Ele faz seus últimos testes e se sente confiável para o último deploy. Com isso vem a pergunta: como faço esse deploy para a produção? Deivid se levanta e vai até Ricardo (Sysadmin). Ricardo já imagina a conversa que vem pela frente, até que Deivid o questiona sobre a implementação do novo sistema:

–  Bom dia, Ricardo. Preciso colocar no ar um sistema que vai fazer a empresa decolar. Como eu faço?

– Como assim, é aquela nova feature super importante? Por que não avisou antes? Quando eu ouvi falar sobre ela nos corredores já imaginei o tamanho da infra para suportar essa feature com excelência para que não caia.

–  Então, preciso colocar ela no ar hoje, meu chefe está me cobrando.

– Sexta-feira, cara! É coloca-lá no ar hoje que vai dar problema e teremos que trabalhar o final de semana todo. Não tem como, tem que planejar isso de forma antecipada e estou cheio de problemas para resolver. Não vai dar!

– Me dá um servidor que eu faço, então.

– Como assim você faz? Você não sabe configurar um servidor!

– Vocês são lentos demais e engessam todo o processo. Não vejo a hora do movimento NoOps chegar.  

– Como assim?! Vem aqui no dia da implementação, então.

– Esses caras da Infra são …

 

PRONTO! Está instalado o que eu chamo de a batalha dos 1000 dias, onde dois cavaleiros de ouro se enfrentam.

Saint Seiya GIF - Find & Share on GIPHY

 

Alguém já passou por isso?

Acreditem ou não, na Umbler não era diferente. Cenários como este eram cada vez mais frequentes entre os setores, não somente na engenharia, gerando embates intermináveis de ego, estresse e pessoas desanimadas no trabalho. Parecia que eram várias empresas diferentes dentro da mesma empresa. Não havia conversa entre os setores e, obviamente, o mais prejudicado nesse caso era o cliente.

O Caos:

Lembro de quando nos deparamos com dois times desenvolvendo o mesmo projeto. Na ocasião eram dois times bem conhecidos por seus embates: Infra e Programação. Cada um estava fazendo esse projeto como julgava ser a melhor forma, meio a essa confusão existia times como o de Marketing e de Vendas que eram incluídos somente no momento do lançamento de algum produto ou feature. O suporte, por algumas vezes, foi avisado de uma nova feature pelo cliente.

Algo estava errado, afinal estávamos crescendo de forma desordenada e desnorteada, precisávamos fazer algo. Neste período da história da Umbler já tínhamos alguns modelos implementados em alguns times como: Go horse, Scrum, Xp, Itil, Kanban, entre outras metodologias ágeis. Porém, no nosso caso, esses modelos mais atrapalharam do que ajudaram.

A pergunta que fica é: como modelos ágeis tão consolidados e utilizados por grandes empresas mundiais não funcionou na organização dos times na Umbler? Simples, ainda não éramos um time, era um bate cabeça.

Zidane GIF - Find & Share on GIPHY

Mudanças: disso nós entendemos bem

Começamos a perceber que antigos métodos já não funcionavam mais, conforme a Umbler continuava a crescer – e crescer rápido – nossa ambição também aumentava. Era preciso investir mais tempo em como organizar os times de uma forma que fosse escalável. Tínhamos em mente a criação de um ecossistema que permitisse, de forma orgânica, o surgimento de novos líderes e de pessoas com muita vontade de fazer as coisas acontecerem, reduzindo o modelo hierárquico tradicional.

Era preciso um modelo no qual o trabalho coletivo prevalecesse, o que não era nada fácil, já que estávamos acostumados a trabalhar de forma desordenada. Sabíamos que a mudança era vital para a empresa e, com isso, tínhamos duas certezas:resistência por parte de alguns setores e que a estagnação não era uma opção.

Bora misturar tudo?

Será que um time de futebol só de zagueiros ou só de atacantes vai ganhar o campeonato? Um time precisa de zagueiros, laterais, meio campistas, goleiros e atacantes. Então, como achamos que uma empresa vai crescer só com os esforços de um setor? Assim como um time de futebol precisa de jogadores com várias habilidades, uma empresa precisa de um time diverso, com mentes diferentes, pensando em prol de um único objetivo.

Os primeiros times Multidisciplinares da Umbler

GIF by Power Rangers - Find & Share on GIPHY

Já estávamos com um ano de empresa e possuíamos um estilo setorial que focava em servidores, códigos, vendas, suporte ou campanhas. Precisávamos pensar diferente, caso contrário teríamos times focado em melhorias setoriais. Então, nosso mindset mudou e, com isso, começamos a montar times focados em produto, afinal de contas a Umbler é centrada no cliente e nosso cliente precisa de um produto absurdamente incrível.

Naquela ocasião formamos um time multidisciplinar para desenvolver a nova plataforma da Umbler. Tínhamos três Sysadmins, dois desenvolvedores um PO – que na ocasião era eu. Esse time teve um início bem turbulento, já que não era unânime essa junção, e que estávamos começando a mudar uma cultura de trabalho. Mudança de cultura sempre é muito complexo, mas tínhamos certeza que aquilo ia fazer a Umbler crescer no futuro, precisávamos ser perseverantes no decorrer do processo.

Levamos um certo tempo para nos acostumar. Discussões continuavam frequentes, porém, dessa vez, estávamos discutindo sobre o mesmo objetivo. Foi então que percebemos o valor que estávamos entregando, o valor que os clientes precisavam. Obviamente teríamos algumas desavenças, afinal estávamos aprendendo a jogar juntos, como um time. Mas ainda faltava alguns elementos para trazer mais valor para o cliente, precisávamos que todas as áreas da empresa participassem da construção do produto e suas features.

Praticamente em paralelo a todas estas mudanças, outro evento extraordinário estava acontecendo em outro time. Um time com foco no produto de e-mail, uma pessoa de Marketing e outra do Suporte estavam se juntando ao time, agregando ainda mais a visão do cliente. Essas pessoas foram a cereja do bolo, algo mágico estava ocorrendo na Umbler.

Juliana Spitaliere

“Lembro que quando sugeriram meu nome para atuar junto a uma equipe de desenvolvimento/infraestrutura, aceitei de imediato, mas pensei: ‘Isso não faz sentido! Eu sou de humanas, não tenho muito a contribuir’. Já nos primeiros dias, desmistifiquei completamente a ideia de que alguém de Marketing não pode colaborar em uma equipe técnica. Minha experiência foi incrível e mudou diversas percepções que tinha tanto sobre profissionais desenvolvedores quanto sobre o impacto de suas atuações no negócio. A troca de conhecimentos e backgrounds foi absurdamente rica. Me aproximei tanto do time e me senti tão participativa que, inclusive, estendi meus aprendizados para a equipe de Marketing e os levo comigo na minha carreira. Trabalhar com metodologias ágeis, principalmente com planejamento, estimativa de tempo e review, foi algo que realmente abrilhantou minha visão de Marketing, conteúdo e gestão”.

 

Lucas Pfeiffer

“Trabalhar em um time multidisciplinar te faz entender todas as áreas do produto no qual você trabalha. Te faz sair da sua zona de conforto, pois, muitas vezes, ao ajudar a equipe, você terá que realizar atividades outrora não realizadas, com ferramentas e em áreas que você não tem muito conhecimento, tendo que aprender por conta a resolver um problema realmente novo. Assim você ajuda a equipe e cresce aprendendo coisas novas que em uma equipe de “mesma skill” não teria a oportunidade de aprender”

Shia Labeouf Magic GIF - Find & Share on GIPHY

Nessa ocasião estávamos usando Scrum como metodologia Ágil para estes dois times. Considero dois pontos fundamentais para a cultura de times multidisciplinares que o Scrum nos ajuda, ou melhor, o método ágil: as Daily meetings e as retrospectivas, ambas instigavam o time a conversar, coisa que raramente ocorria no passado. Na retrospectiva lembro de ser uma reunião bem estressante, que no fim gerava um resultado muito bom para os times. Em termos de jogar junto, percebemos que o time estava começando a resolver seus próprios problemas, sem precisar que chefes funcionais mediassem os conflitos.

Demoramos uns três meses para que todos se adaptassem a nova metodologia, começando a jogar junto de verdade. Tínhamos um único objetivo, sentávamos juntos, fazíamos reuniões e resolvíamos os conflitos internos em conjunto. Após conseguirmos provar na prática o valor de um time com habilidades diversificadas tínhamos em mente expandir para o restante da empresa.

O Caos Controlado

Desde o início da Umbler o caos foi uma característica do dia a dia. Como diria o especialista em criatividade, Murilo Gun: “entre o caos e a organização, fique com o caos.”

Isso porque a organização excessiva mata a criatividade e a velocidade de mudança de uma empresa, gerando burocracia. Porém, o caos sem algum tipo de organização e alinhamento gera retrabalho, desalinhamento e perda de energia.

A Umbler já possuía dois anos de vida, a empresa estava crescendo e contava com cerca de 40 colaboradores, era chegada a hora de expandir essa cultura para o restante dos times.

Estávamos sendo arrancados da nossa zona de conforto, a melhor e mais rápida forma de crescimento do ser humano é estar fora de sua zona de conforto. Tínhamos uma grande oportunidade de fazer isso dar certo, e deu muito certo.

Tínhamos em mente não apenas colocar algumas pessoas dentro dos times, mas sim fazer isso da forma certa e de maneira profissional. Então começamos a pensar com algumas premissas antes de expandir para o restante da empresa, como:

  • Liberdade para criar
  • Autonomia para tomar as próprias decisões
  • Objetivos claros para os times
  • Acabar com o modelo tradicional de setores
  • Despertar o senso de dono em todos
  • Diversidade de pensamentos, ter múltiplos pontos de vista
  • Alinhamento

Com isso em vista, procuramos algumas empresas que já estavam passando por uma transformação parecida de cultura que pudéssemos usar como fonte de inspiração. Queríamos achar algum framework que favorecesse a criatividade e a entrega dos produtos, foi neste momento que encontramos uma metodologia bem consolidada usada pelo Spotify e Nubank por exemplo.

Chegou a hora de uma nova mudança na Umbler!

Não vou dar mais detalhes neste post (hehe). Na segunda parte desse conteúdo vou mostrar como fizemos, explicando detalhes da metodologia usada e como a adaptamos para a nossa realidade, bem como os benefícios e os novos desafios enfrentados.

Até o próximo post pessoal!

Se identificou com a nossa história? Conta pra gente aqui nos comentários, vamos adorar ouvir a sua experiência.

Diego Voltz
Diego Voltz, VP of Technology Umbler

Crie sua conta na Umbler e ganhe até R$ 100 em créditos para sites e e-mails!

Ganhe até R$ 100 em créditos para sites e e-mails. Cadastre-se na Umbler sem compromisso ;)