A fantástica fábrica de talentos
Se tem uma coisa da qual nos orgulhamos muito na engenharia do Grupo ZAP é a nossa cultura. Tem tanta coisa para falar sobre isso que a gente nem sabe por onde começar. Como não aguento mais esperar vou falar sobre alguns pontos dessa cultura e da forma que trabalhamos que potencializam o talento das pessoas, tirando barreiras e mostrando na prática que acreditamos e confiamos em cada uma delas.
0 — Decisões colaborativas que funcionam
Temos um processo colaborativo de decisão que funciona de verdade! Incentivamos que todas as pessoas participem das decisões e temos um processo prático para isso.
Acreditamos que decisões, ideias e planos são beneficiados pela colaboração porque conseguimos juntar as melhores ideias e experiências positivas em uma só. Elas demoram um pouco mais, mas normalmente são melhores que as soluções originais.
Claro que chegar nesse processo não foi fácil, mas acho que consigo resumir em alguns pontos:
- Ter um mediador: essa pessoa é responsável por garantir que a discussão tem foco e um fim, e que não ficamos viajando na maionese.
- Criar uma proposta inicial: normalmente 1 ou 2 pessoas fazem isso;
- Lapidar esta proposta em um fórum maior: este fórum pode ser o seu time ou outras pessoas que poderiam contribuir com novas ideias ou críticas para fortalecer a proposta original;
- Abrir a proposta para discussão: normalmente as discussões acontecem no github pra que todos da área tenham a chance de participar e pra que todas as contribuições fiquem documentadas;
- Ter uma data para o final da discussão: isso garante que nós não vamos cair em uma discussão infinita e que a proposta vai virar algo concreto;
- Revisar sempre que necessário: nenhuma ideia é boa pra sempre, por isso entendemos que elas devem sempre ser revisadas e discutidas a medida que os contextos onde elas se aplicam mudam.
Um bom exemplo de algo que foi criado usando este processo é a nossa trilha de carreira, que descrevo abaixo.
1 — Temos uma trilha de carreira feita de forma colaborativa
Em um dado momento fui levado a acreditar que, na nossa carreira, a única forma de crescer era arrumar outro emprego. Que era impossível criar e manter uma trilha de carreira em um ramo que muda constantemente. Mas isso mudou desde que comecei a trabalhar aqui. Temos uma trilha de carreira que foi feita por todos nós.
Isso começou antes de eu entrar na empresa, e ela segue a receitinha acima.
Todas as pessoas colaboram para melhorá-la e de uma forma bem conhecida entre nós desenvolvedores de software (pull requests). Sim, isso mesmo que você está lendo. A nosso trilha de carreira da Engenharia, ou a nossa Ladder de Engenharia como chamamos, é melhorada constantemente e de forma colaborativa por todas as pessoas da área fazendo pull requests diretamente no repositório onde documentamos a nossa cultura.
E parte que me assusta: ele é o mais próximo do objetivo que eu sequer pude imaginar. Falar de carreira, de todos os perfis, em um documento único, com o mínimo de subjetividade, é no mínimo disruptivo.
Veja um “pedido de alteração” (pull request) feito pelo Ricardo Bin:
Ainda não temos as discussões e os pull requests públicos, mas muita coisa já está aberta:
Nota de atualização: a partir de Nov/2020 o Grupo Zap faz parte da Olx Brasil
Site de cultura: https://olxbr.github.io/cultura
Trilha: https://olxbr.github.io/cultura/ladder/engineering-ladder.html
Como tomamos nossas decisões: https://olxbr.github.io/cultura/como-trabalhamos/como-tomamos-decisoes
2 — Temos autonomia e ela funciona
Os desenvolvedores tem autonomia para trabalhar, não existem acessos proibidos ou coisas que eles não podem fazer. Em contrapartida têm responsabilidades, você pode fazer tudo o que você quiser desde que você seja responsável por tudo o que você fizer. Na prática temos sistemas maduros, com qualidade, estabilidade dos sistemas, e muita praticidade.
Eu achava que a gente não controlava nada, mas de uma conversa com o Alan descobri que sim, controlamos tudo, controlamos garantindo que as coisas estão acontecendo como combinado, olhando e auditando, dando clareza. Mas sem nunca parar, nas palavras do mesmo Alan, “a carreta sem freio” da engenharia e ser atropelado por soluções de contorno, gambiarras.
A consequência disso se reflete em diversas outras coisas, algumas delas vou falar abaixo.
3 — Temos colaboração
A colaboração é o reflexo que mais me orgulha da nossa cultura. Ela sempre esteve conosco nos melhores momentos: se você tem uma boa ideia, tem autonomia, tem disposição para discutí-la, e sabe que as pessoas colaboram, ela acontece!
Mas e na hora do “pau”?
Faltava ver na prática em uma situação realmente forte, adversa, se éramos tão unidos. Eu apostava que sim, mas morria de medo de estar errado.
Eis que chegou o dia. Um bug de segurança muito crítico descoberto duas horas antes do jogo do Brasil na Copa.
O que eu vi foi: todas as pessoas juntas, cada uma resolvendo a sua parte e ajudando a tomarmos as melhores decisões e estabilizar o problema o mais rápido possível. E estamos falando de uma centena de pessoas.
Nos dias que se seguiram a esse evento nada mudou. Todos buscando se ajudar e a encontrar a melhor forma de resolver o problema. Não havia dedos sendo apontados e não havia pressão de nenhum lado, o que seria até estranho porque era claro que cada um tinha 100% de consciência de sua responsabilidade no problema e estava agindo.
Colaboramos tanto uns com os outros que é comum ver discussões como essa, em que alguns engenheiros quiseram auxiliar nosso RH para melhorar a abordagem a novos candidatos:
4 — Problemas são resolvidos de verdade
Esses dias um engenheiro (brennovich) me contou que ele teve um problema em um deploy, e como aquilo era cabuloso. Eles utilizavam como ID do deploy o hash simplificado do commit. Em alguns casos o hash começava com um número, seguido da letra E, seguido de outro número. O sistema então interpretava isso como um número exponencial, do tipo 10e10 (10 elevado a 10). Ele me contou como foi a saga para descobrir esse problema. Enquanto ele me contava a única coisa que eu pensava era: tudo isso só foi possível porque ele tinha autonomia e como a situação seria diferente em outros lugares, e como dificilmente ele teria a oportunidade de ir tão longe e consequentemente aprender tanto.
Conheço inúmeras histórias que o final é completamente diferente, e que geraram verdadeiros heróis que as vezes gastaram muito mais tempo e energia para conseguir fazer coisas até mais simples do que a que o brennovich fez, porque não tinham autonomia e não conseguiam enxergar como seus sistemas se comportavam na vida real, em produção, em todas as camadas necessárias.
Tenho certeza que mais situações de sucesso como essa acontecem frequentemente e a gente nem fica sabendo simplesmente porque é parte do nosso dia a dia e não mais um ato heroico de algum quase mártir.
O que a gente consegue ver são os reflexos: sistemas maduros.
5 — Não temos medo de errar
Essas histórias acima nos fazem não ter medo de errar, porque sabemos que podemos contar uns com os outros e porque sabemos que temos autonomia para corrigir nossos erros rapidamente.
6 — Gerentes da nova geração
Recentemente aconteceu uma outra coisa que significou muito pra mim: dois desenvolvedores viraram gerentes. Um deles participou de um processo formal e acabou sendo escolhido entre outros candidatos e o outro foi no “susto”, entendemos que ele tinha o perfil e a postura certa para a posição e fizemos uma proposta para ele.
O que tem de legal nisso?
Um dia eles estavam no time deles, no dia seguinte eles estavam no time de gestores. Sem burocracia ou grandes formalidades. Tão simples e natural quanto mudar de lugar.
Mas… e o que tem de legal nisso?
Pode soar natural para muita gente, mas para mim, em uma equipe do tamanho da nossa, uma pessoa simplesmente sair do time dela e ir para a gestão é muita coisa. Eles tinham todas as informações necessárias pra trabalhar na nova função simplesmente porque exercitamos a transparência no nosso dia a dia.
Eles também não foram escolhidos porque eram amigos de alguém, o processo planejado foi aberto a todos, sem restrição. E os motivos pelos quais escolhemos a segunda pessoa pra assumir a nova função foi explicada pra todos de forma muito natural.
A posição de gerente de engenharia é uma função diferente no time. E esse tipo de mudança é visto como um passo pro lado. É uma mudança de carreira e isso é tratado dessa forma aqui dentro. Ninguém é obrigado a “virar gerente” pra crescer. Todos entendem os desafios da mudança e o quanto o papel das pessoas que passam a fazer parte dos times desses novos gerentes é fundamental pra que a transição seja bem sucedida.
7 — NoOps, NoQA, NoDBA
Eu posso estar muito mal informado, mas não conheço outra empresa do nosso porte onde não existe uma equipe de operações, não tenha uma pessoa com a função de DBA e nenhuma com a função de QA.
A autonomia, a colaboração e o senso de responsabilidade faz com que esse tipo de trabalho seja diferente.
São vários fatores que contribuem para isso, desde seguir o “git-flow” até escolher as melhores ferramentas de administração.
Outras coisas que contribuem para isso:
- A cultura de matar legados o mais rápido possível;
- A cultura batizada pelo Kope de “FCQF” — Faz certo que funciona;
- Cada time ser responsável pelos sistemas que cria ou já criou;
- Todos os sistemas terem obrigatoriamente um dono, alguém para se orgulhar dele ou se incomodar a ponto de melhorá-lo ou substituí-lo por alguma solução melhor;
- Não ter um banco de dados gigante de difícil administração, e ao invés disso temos vários bancos menores gerenciados pela AWS;
- E deletamos sem pudor coisas que não sabemos o que é;
- Integração contínua simples, e o deploy contínuo simples, a ponto de nem precisarmos ter gerenciadores de configurações como Chef, Ansible e Puppet;
- Deploys e rollbacks acontecem quase instantâneos, a maioria em menos de 1 minuto, alguns em 5 segundos;
- Visibilidade através de métricas e logs.
Nosso ciclo de deploy automatizado é mais ou menos assim:
A nave rosa é o pipeline comum e a verde é o nosso.
Ué, mas quem cuida de toda essa automação? Existe uma equipe, chamada Plataforma, que como qualquer outra da engenharia, idealiza e mantém seus próprios sistemas e ferramentas para prover serviços para as demais.
8 — Muito trabalho, coragem e objetividade
Essas coisas dão muito trabalho, e necessitam muita coragem. Acredito que o que viabilizou tudo isso foi nossa liderança. Se a liderança não acredita, não apoia, não se esforça para nós não sairmos do plano, e não nos ajuda a tornar nossas ideias malucas em coisas claras e práticas, essas coisas viram esforços individuais que dificilmente dão em algo, só geram mártires.
Essa postura se reflete em todo o resto das pessoas.
Aprendemos a não ter medo de nada. Aprendemos a entrar em problemas só quando temos certeza que temos disposição para ir até o fim. Aprendemos a pensar de fora dos problemas, e as vezes até deixar de lado toda nossa experiência para conseguir pensar diferente. Antes eu achava que isso era desperdício de tempo e talento.
Aí vem os engenheiros… uma força coletiva maior que qualquer outra coisa que já vi, que sabe do seu poder e que exerce esse poder constantemente e com uma responsabilidade de dar orgulho ao tio Ben. ;)
Além disso, temos uma integração incrível com o time de Gente & Gestão (aka RH) para a gente não ficar maluco :) Essa integração adiciona ao nosso time competências que normalmente não vemos por aí. Não é um time que dificulta a nossa vida com processos morosos. Pelo contrário, é um time que facilita o nosso trabalho entendendo de verdade como funcionamos e qual a melhor forma de nos ajudar. Somos corajosos para “incomodar” as pessoas para que elas cresçam. Sem um apoio de quem estuda pessoas isso seria bem complicado, porque temos consciência que não somos melhores uns que os outros e ainda assim somos responsáveis pelo desenvolvimento mútuo.
O resultado disso é sempre querer encarar qualquer problema, porque hoje temos total confiança que sim, vai dar trabalho, mas vamos chegar na melhor solução possível e vamos nos orgulhar no final.
9 — Melhoramos sempre
Constantemente revisamos nossas ações aplicando a boa e velha retrospectiva proposta pelo Scrum. Retrô dos eventos, dos treinamentos, de cada ciclo de avaliação, do processo de contratação, etc. Muitas das melhorias propostas nos “pull requests” da nossa cultura vêm daí.
Quero “ibagens”
Eu acredito sinceramente que vivemos o futuro, e vejo os sinais quando leio coisas que pessoas dizem que é o futuro e sei que acontecem aqui, ou quando fazemos treinamentos nas melhores empresas do mundo e descobrimos que já aplicamos aqui as coisas que são ditas lá.
Outro reflexo importante é nossa eficiência operacional. Estamos sempre otimizando nossos custos, mesmo crescendo os sistemas, os custos diminuem.
Mas, de que adianta tudo isso sem “ibagens” e números?
Somos em torno de 180 pessoas em engenharia e produto, 125 são engenheiros. (Temos vagas , clique aqui :p ).
No momento que escrevo esse texto, temos 94 nós no Kubernetes (ele tem auto-scaling, facilmente passa de 130) e 1035 pods, rodam cerca de 260 microserviços.
Nesse exato momento nossos microserviços estão respondendo cerca de 60 mil requests por minuto. Não são os números de audiência do site, são as aplicações falando umas com as outras.
Nesse mesmo instante nosso cluster de Kafka está recebendo 242 mil mensagens por minuto.
E nosso Prometheus está recebendo 35 mil métricas por minuto.
E daqui pra frente ?
Pensando bem, acho que a dificuldade para escrever sobre essas coisas têm muito a ver com a velocidade com que elas mudam aqui dentro. Se um dia decidirmos escrever um livro com os detalhes dessas e de outras coisas interessantes, ao final ele já estaria desatualizado. Hoje temos uma equipe, o “Chapter Agile”, que apadrinhou a nossa “integração/melhoria contínua de cultura” e conseguiu formalizar mais um monte de outras coisas que antes eram subjetivas e têm a missão de deixar tudo isso público. Mas vou deixar para eles mesmos contarem essa parte. :)
Sem perceber abri uma caixa de pandora, acho faltava esse pontapé inicial para falarmos da nossa cultura e até esse texto virou colaborativo. Já nem posso mais dizer que é só meu.
Colaboraram: brennovich, Caio Silva, Jota Feldmann, Cássio, Marcio Rodrigues, Evandro F. Souza, Ariovaldo Carmona, Marcel Viana, Figaro.
