Liderando Engenharia: O despertar do Spark
Completei um ano como líder de tecnologia na Matchbox Brasil e gostaria de registrar algumas vitórias e lições aprendidas durante esse período
Fala galera, tudo bom?
Nesse post gostaria de fazer uma retrospectiva de tudo que fizemos aqui na Matchbox nesse último ano, e é no plural mesmo, porque não fiz nada sozinho desde que entrei em maio de 2021.
Só para contextualizar a todos, a Matchbox é uma HR Tech (startup do ramo de RH) paulista fundada em 2017 e no final de 2020 lançamos o Spark, nosso SaaS B2B, uma plataforma de marketing para o RH.
Recentemente li um post do Thiago Ghisi muito interessante sobre os 4 Pilares de uma Carreira de Sucesso e vou tentar esboçar esse post usando esse framework.
E por isso não vou seguir uma ordem cronológica dos fatos, mas quero citar principalmente nossos principais avanços e as lições aprendidas.
Plataforma
1º Pilar -> Plataforma — a base de código, os scripts, a infraestrutura, o pipeline CI/CD, os batch jobs, os padrões de arquitetura, os bancos de dados, suas habilidades técnicas com um paradigma ou linguagem de programação particular, framework, ferramenta ou biblioteca. Tudo aquilo que, em geral, apenas os engenheiros podem ver e avaliar. É o cerne do trabalho do engenheiro, a capacidade de resolver problemas com ferramentas — Thiago Ghisi
Como plataforma evoluímos muito em padronização dos projetos, temos hoje um monólito que reescrevemos para Typescript e alguns micro serviços em Serverless em outros repositórios que padronizamos tanto a versão do Node.js, quanto a reescrita para Typescript, como também melhoramos o processo de release desses projetos, amarrando as permissões da cloud e a criação de todas as dependências durante a release, além de habilitarmos as funcionalidades do OTEL, X-Ray e lambda insights.
Ainda temos muitas coisas a melhorar, temos alguns projetos que ainda se utilizam do mesmo fluxo da imagem abaixo, onde temos uma branch principal e o processo de deploy de uma nova funcionalidade começa a partir do merge de uma branch qualquer com a principal, mas já temos alguns projetos que esse gatilho só é feito por uma release do repositório do projeto.
Outro ponto que evoluímos muito foi ter colocado em quase todos os projetos o SonarQube em nosso processo de desenvolvimento, cada pull request passa por uma análise de código e trás insights de melhorias para a mudança que vai ser feita, tanto de complexidade quanto de segurança.
Nossa principal entrega nesse quesito foi sem sombra de dúvidas ter resolvido a modelagem de dados no MongoDB. Não vou falar que acertamos 100% e que tudo já está resolvido, porque ainda existem cenários que vão exigir algum esforço nosso e estamos trabalhando em alguns testes de carga para garantir e pensar em estratégias caso a caso.
Mas o que posso comemorar é que nessa remodelagem tivemos que revisitar todas as nossas queries ao banco, criamos uma biblioteca para centralizar os modelos do mongoose e centralizamos algumas funções reutilizáveis em diversos locais. Desenhamos nosso novo modelo, seguindo a estratégia da empresa, com foco nos talentos, que nos permite finalmente escalar o projeto.
Tivemos acertos e ajustes finos nas filas SQS que usamos, adicionando delay no processamento e reprocessamos apenas parte do buffer de mensagem que deu erro, só para se ter ideia, o ajuste feito gerou uma economia de mais de 70% em lambdas (em média de $400 dólares para pouco mais de $90 dólares de um mês para outro, ainda pode haver variações, pois é um período curto para análise).
No frontend muita coisa mudou, adotamos o Next.js, como novo framework React, antes utilizávamos o próprio CRA, e a Vercel como plataforma de build e release. E melhor, estamos com os dois projetos rodando juntos em produção, usamos o sistema de rotas para direcionar do Next para o CRA e manter as páginas que ainda não passamos para o Next funcionando. Isso possibilita termos micro frontends por rotas em Next, o que ainda não é muita coisa, mas já abrimos mais possibilidades.
Essa mudança trouxe muitos benefícios, por ser um projeto novo, aproveitamos e começamos a ter um olhar mais próximo do Atomic Design, refazendo do zero muitos componentes complexos que tínhamos, tirando o Redux e adotando mais o Context do próprio React, começamos a aplicar mais testes com React Testing Library e Jest e a gerar entregas melhores e mais rápidas.
Produto
2º Pilar -> Entrega do Produto. É o aplicativo, o site, o plugin, o gadget. É o externo. É o que o usuário está usando, a experiência que o usuário está tendo, os recursos disponíveis, o que o usuário é capaz de fazer e a rapidez com que pode realizar uma ação, a percepção de velocidade, segurança e confiabilidade. É o que o lado do negócio vê sendo entregue pela equipe de tecnologia, o que torna a empresa lucrativa. — Thiago Ghisi
No quesito produto, entregamos muita coisa, muita coisa mesmo, além das entregas que vou citar mais pra frente, fizemos algumas pesquisas de usabilidade com usuários, que surtiram efeito diretamente na experiência da plataforma, diminuindo cliques, aumentando a área de trabalho e outras dinâmicas dentro do produto.
Vale citar também que algumas ações de plataforma citadas anteriormente influenciaram diretamente na percepção de performance, velocidade e confiabilidade da plataforma, algo que antes era insustentável e muito ruim, está se tornando cada vez mais utilizado e bom, meu palpite para as próximas pesquisas de NPS é muito mais otimista.
Entregamos o módulo de campanhas de e-mail logo quando entrei e de lá pra cá muita coisa mudou pra melhor, aumentamos nossa reputação nos disparos, melhoramos a arquitetura de filas, montagem e coleta das variáveis do template da campanha, investimos em melhorias no frontend e vários pequenos ajustes que fazem hoje nossa plataforma entregar em média 120 campanhas de e-mails para mais de 900 mil e-mails por mês.
Estamos bem longe do volume de grandes scale ups, mas o recado aqui é que estamos prontos para enviar muito mais campanhas.
Não faz muito sentido termos um módulo para disparar campanhas de e-mails sem segmentar sua base de talentos e automatizar esses disparos, e melhoramos muita coisa nesse sentido.
Nossa base beira aos 3 milhões de talentos com milhares de segmentações dinâmicas e automações ativas, a segmentação era um processo em backoffice agendado e gerava um custo de processamento gigantesco para ser executado, pois fazia validações talento a talento, hoje cada talento novo entra num fluxo e é validado dentro de segmentações com um custo de processamento muito menor, o que gerou num processo near real time, muito mais rápido e com um custo muito menor.
Compramos a HR Bot, adicionamos a nossa cesta de produtos e agora temos um olhar muito mais horizontal na jornada do talento, pois o HR Bot resolve muitas das dores do RH tirando dúvidas e respondendo perguntas com IA para os colaboradores. Estamos trabalhando para trazer o HR Bot e integrá-lo dentro do Spark.
Entregamos nosso módulo de chatbot dentro do Spark! Nele diferente do HR Bot onde temos um chatbot com identificação de intenções, muito usado para faq, dúvidas e atendimento, aqui é possível o cliente criar um chatbot com fluxo pré-definido, isso nos ajuda a atender diversos outros casos de uso dentro do RH, como por exemplo, admissão, pesquisa de desligamento ou até recrutamento.
E então após algumas pesquisas e entrevistas evoluímos a usabilidade e incluímos muito mais ações e nós dentro do chatbot, também ajudamos nosso usuário na criação de um chatbot novo com um template pré definido, como na imagem abaixo, fora as dezenas de melhorias que entregamos tanto no administrativo como no próprio chatbot.
Tem muito mais entregas, fluxo de cadastro novo, pipeline novo saindo e outras novidades que estão na nossa esteira de desenvolvimento.
Vale citar também algumas ações de educação que foram feitas pelo time de marketing e customer success da Matchbox que ajudaram muito na adoção do produto pelos clientes como a Certificação do Spark.
Processo
3º Pilar -> Processo e Cultura. É o COMO. — Thiago Ghisi
Quando falamos em processo, lembro que trouxe muitos pontos de melhoria logo nos primeiros dias e quis mudar tudo, toda forma como era entregue nossa esteira de desenvolvimento.
A realidade foi dura, demorei para conseguir convencê-los, e ainda tenho muito trabalho pela frente, acho que não foi a demora o problema, mas talvez o modo que trouxe e fui conquistando mais quando questionava o como o trabalho era feito e os fazia pensar se aquele jeito era o melhor, e com o passar do tempo fomos conseguindo mudar muitas coisas.
Nós fizemos muitas entregas durante o último ano, esse é só um recorte dos últimos 90 dias e já mostra uma taxa de entrega em média de 8 PR’s por dia útil. Se eu tivesse o recorte do ano todo, talvez essas barras mais altas com intervalos grandes sem entregas estariam muito mais presentes nesse recorte, podem ter certeza que essas entregas estavam relacionadas com alguma data de entrega ou apresentação que deveríamos fazer, pois nossa entrega era apenas semanal e casada com a apresentação aos stakeholders, e não diária e independente, hoje ainda temos alguns compromissos, mas estamos menos suscetíveis a erros do que quando temos todas as entregas sendo feitas ao mesmo tempo em um só dia.
Outro ponto que ficou bem mais claro para todos do time, e que faz parte da entrega contínua, é colocar código em produção. Calma, você não leu errado, colocamos código em produção sem passar pelo processo de homologação, temos nosso ambiente de homologação/desenvolvimento que usamos como testes e fazemos nossa homologação de funcionalidade, mas por exemplo, alguma página nova, módulo novo, conseguimos homologar com uma página escondida em produção ou em uma empresa de testes nossa nesse ambiente. Isso nos ajuda a garantir que a homologação seja a real, e estamos trabalhando para colocar o feature flag do Optimizely para nos ajudar ainda mais nesse processo quando precisamos fazer alterações maiores em algo pré-existente, migrações e outras tretas.
Melhoramos muito nossa operação, no início tínhamos uma sobrecarga gigante de trabalho em cima de determinadas pessoas e ainda temos em um nível um pouco menor, mas por conta do nosso tamanho até então e da quantidade de funcionalidades que temos e principalmente da maturidade do produto, nós não saímos do lugar quando algo não funcionava ou caía, alguém e sempre eram quase as mesmas pessoas tinham que parar o que estavam fazendo e investigar o problema que acontecia com nosso cliente.
Coloquei várias estratégias em jogo, chegando mais reforços nos dividimos em times e dividimos o escopo de atuação, acendi o burn cash com os nossos fornecedores, principalmente na AWS e MongoDB, para principalmente ganhar tempo com as investigações e com o que precisava ser feito, conseguimos mais de $100 mil dólares em créditos para alívio do financeiro, e deixei o próprio time falar o que precisava ser feito, quais ainda eram nossos débitos técnicos, o que precisávamos fazer para melhorar as filas e o tempo de processamento e quais os gargalos, após várias discussões tínhamos um plano de ação e tivemos alguns resultados após rodadas de novas implementações.
Para colocar código em produção todos os dias e manter a operação em níveis baixos, você como líder deve aumentar a qualidade das entregas, e aqui vão algumas práticas que começamos a aplicar em nosso dia a dia que nos ajudou a subir a barra, mas ainda temos um longo caminho pela frente.
Algumas cerimônias de refinamento técnico devem acontecer com um intervalo razoável de antecedência, principalmente se precisamos construir uma infraestrutura ou arquitetura nova, falar não para o time de produto é saudável, ainda mais com estórias contadas durante o planejamento da semana com data de entrega marcada.
Incluir testes unitários e automatizados na esteira de desenvolvimento é essencial, mas não é fácil colocar em prática dentro de um time que não aplicava essa etapa. Fizemos algumas rodadas que chamamos de dojo, para praticarmos o desenvolvimento de testes reais e o porque testar casos de uso apesar dos 100% de cobertura de testes.
A revisão de código é vital para entregas melhores e o amadurecimento de um time com auto gestão, aqui tentei replicar tudo que escrevi nesse artigo quando ainda estava na RD Station.
Pessoas
4º Pilar -> Pessoas e Liderança. É o segundo COMO e provavelmente o mais importante. — Thiago Ghisi
Sim pessoas é o mais importante! Meu time é meu maior patrimônio, sem ele eu como líder de engenharia não escreveria os outros 3p’s acima. Vocês arrasaram!
Eu tive que conhecer minha tropa, a diversidade aqui na Matchbox é real oficial, tenho 15 liderados entre devs, security e devops, quatro são mulheres, três são pretos, um é gay, não somos tão diversos como gostaria, mas estou aberto a receber mais perfis diversos. Hoje temos 4 juniors no time também e estamos criando nosso programa de estágio para recebermos cada vez mais iniciantes.
Foram três All Hands de Produto, CS e Engenharia, mais de vinte HH’s (muito pouco, mais estamos em processo de melhoria contínua), mais de 500 conversas individuais entre liderados, pares e com o “presida” (apelido interno que dou aos CEOs onde passo, desculpa aí boss).
Muitas conversas difíceis, feedbacks, puxões de orelha, alinhamentos de expectativa e o que você pode imaginar que fiz para ajudar e apoiar cada pessoa nesse time.
Muitas promoções, evoluções de carreira, oportunidades que apareceram, e outras estão próximas de acontecer, que conseguimos concretizar. Aqui na Matchbox reavaliamos todos nossos colaboradores de 6 em 6 meses.
Todas essas coisas só foram possíveis com nossas conversas sobre carreira e construção do Tour of Duty individual de cada um, deixando claro que cada um é responsável por sua própria carreira.
Nesse período todo também fui ajudado e muito, fiz mentorias com o Lazarini, falei com gerentes de engenharia para construir meu Tour of Duty e outros tantos que troquei algumas dúvidas por mensagem e reuniões no Linkedin, Whatsapp e Google Meet.
Estou escalando nossa liderança de engenharia, fizemos um curso sobre o ciclo do Matchboxer, estamos aplicando mentoria interna com a ajuda dos demais líderes da Matchbox e já estamos colhendo alguns frutos.
Tivemos dezenas de palestras que o próprio time compartilhou o conhecimento no nosso Hora do SaBEER quinzenalmente as quintas e premiamos por voto popular a melhor dos últimos seis meses.
Participamos de eventos, online e presencial, como palestrantes, divulgamos e compartilhamos nosso conhecimento e vem mais coisa boa por aí!
Conclusão
Ufa, acho que escrevi muito, passou rápido esse um ano! Aprendemos muito juntos Matchbox | Produto, CS e Engenharia e ainda temos muito a conquistar e melhorar, vamos pra cima 🚀!
Em breve espero contar sobre mais um ano a frente da engenharia da Matchbox, os resultados de negócio e o quanto evoluímos, tem sido desafiador, mas de um ano pra cá crescemos mais de 93% comparando 2021 com 2020.
2022 está só começando, até porque o carnaval foi em abril (risos) e temos muita coisa pela frente!
Não podia terminar esse texto e deixar de dar uma força pro RH da firma que me incentivou a escrever essa experiência e compartilhar o link com nossas vagas!
