Você já teve aquele medo de que algo errado pode estar acontecendo e você pode nem estar sabendo?! Aquele medo de que a qualquer momento sua plataforma pode cair?!
De que seu time pode não estar andando na direção correta?! A sensação de que tudo está um caos, e você não tem controle de nada?!
Nesses quatro anos de Gupy, vivi esses e muitos outros cenários diferentes, e sei que ainda viverei vários outros. Mas acredito que posso ajudar muitos líderes de tecnologia compartilhando um pouco dessa minha experiência - e um pouco da solução para esse caos.
Organizar times, processos e garantir entregas com qualidade é um desafio em qualquer cenário. Mas em ambientes de alto crescimento, nos quais existe uma pressão por entregar cada vez mais, evoluir rápido e aprender mais rápido ainda é cada vez maior.
A Gupy se enquadra super bem nele. Só para você ter uma ideia:
Só em 2018, crescemos 5 vezes e terminamos o 3º trimestre com 15 pessoas no time de produto e engenharia.Em meio a todo esse crescimento, surgem perguntas - e desafios - para a liderança: Como escalar a cultura? Como organizar processos? Como entregar mais mantendo o time saudável e produtivo?
Além disso, outros questionamentos mais focados no crescimento de times técnicos seriam: Como suportar um crescimento de 10 vezes no número de usuários em um espaço de 6 meses? Como quintuplicar o time de engenharia sem perder qualidade?
Mais gente nem sempre significa mais entrega, então como organizar os processos e arquitetura para garantir um crescimento da velocidade de entregas na mesma proporção, ou pelo menos uma proporção parecida, com a do time?
Para compartilhar a minha experiência como CTO nesse ambiente, resolvi dividir este texto em 3 tópicos base:
Continue lendo para entender um pouco mais dessa história caótica, cheia de erros e acertos.Acredito fortemente que o fator responsável pelo sucesso da Gupy, até o momento, foi a cultura.
Temos um time incrível e muito engajado, e sem isso seria impossível para nós founders resolvermos todos os problemas, pensar em todas as inovações e ter todas as ideias que levaram à evolução que tivemos até agora.
Nosso papel principal dentro disso foi criar o ambiente propício para que o time encabeçasse esse crescimento, com um gigante senso de “donos do negócio”.
Em conversas com outros empreendedores de diferentes mercados, fica claro que as startups que conseguem passar dos estágios iniciais do negócio são justamente aquelas que possuem uma cultura muito forte e escalável, junto a um time engajado.
Lembre-se: você muda e encontra o melhor caminho para o modelo de negócio, escolha de tecnologia e produto. Mas o que faz essas empresas se diferenciarem - e se destacarem - são times fora da cultura, e só se atinge isso com foco total nas pessoas e na cultura.
Processos são importantes, mas eles não podem passar por cima da cultura. O primeiro item do manifesto ágil é: "Indivíduos e interações mais que processos e ferramentas", e isso tem que ser levado muito a sério. Mas é sempre bom lembrar que ter foco nos indivíduos não significa deixar de lado processos e ferramentas.
No nosso time de engenharia e produto, desenhamos as restrições para os times e esses definem as regras do dia a dia, que, depois de cada ciclo de duas semanas, são discutidas, possibilitando uma reação rápida diante de cenários não previstos.
Essa flexibilidade para adaptação a situações, sem precisar lidar com burocracias de processos muito engessados, é fundamental para um time de engenharia em uma startup de alto crescimento.
Nesse time temos pessoas com diferentes vivências, tocando partes diferentes do produto com diferentes níveis de complexidade, então não faz sentido, para realidades tão diferentes, um processo top down ser imposto por uma pessoa que nem sempre pode estar 100% presente no dia a dia dos times.
Na Gupy, agilidade é uma forma de pensar, é o que realmente guia nossas ações - não somente processos formais.
Falar sobre a cultura da Gupy poderia render, tranquilamente, um livro inteiro de conteúdo, mas vou tentar resumir de maneira prática como reforçamos isso no dia a dia.
Lembrando que ela não pode ser só uma lista de frases legais - tem que engajar e estar muito presente no dia de cada um dos colaboradores da empresa.
Algumas formas simples e boas de reforçar a sua cultura:
Um exemplo que usamos é um sistema de recompensa colaborativo: o Gupy Coins, com esse objetivo de reforçar nossos valores. Ele nada mais é do que o Merit Money, ou seja, você reconhecer uma outra pessoa sempre que achar justo.
Pode ser reconhecendo uma ajuda, uma entrega legal, um conhecimento que foi compartilhado e tudo mais que você achar válido. E, claro, sempre que você reconhece uma pessoa, deve indicar em qual valor da cultura essa pessoa brilhou ao executar aquela ação.
Mas, sem dúvidas, a maior oportunidade para reforçar ela - que é também o maior desafio - é garantir que os valores sejam reais, que as pessoas vejam na rotina como esses princípios são aplicados nas tomadas de decisão e na forma como a empresa é direcionada.
Aqui, temos algumas premissas para guiar essas mesmas tomadas de decisão:
A cultura evolui com o tempo, ela se adapta a realidade e às pessoas que vão entrando, por isso a construção e manutenção de uma cultura começa no recrutamento.
Tive experiências ruins com pessoas sem fit cultural, e o impacto negativo é terrível. Perdi pessoas que não gostaria de ter perdido, abaixou a produtividade do time e o clima que sempre foi incrível e um dos principais pontos fortes da Gupy, ficou ruim.
Reverter esse cenário levou meses e esse tempo para uma startup em alto crescimento é valioso. Hoje, sou muito exigente no check cultural e, em todas as 4 etapas do nosso processo seletivo, a cultura é checada.
Já reprovei candidatos tecnicamente excepcionais por desconfiar de um ponto de nossa cultura. Hoje prefiro não arriscar, pois tecnicamente é fácil evoluir uma pessoa, mas mudar alguns valores é bem mais complexo.
Aqui na Gupy, a cultura é checada em todas as etapas do processo seletivo. Nossos valores são muito claros e estão por toda a parte, inclusive grafitados em nossas paredes :)
Montamos roteiros de entrevista focando em checar os nossos valores, mas claro que não perguntamos diretamente se o candidato tem senso de urgência por exemplo.
Apresentamos cenários, perguntamos como essa pessoa se comportaria e pedimos exemplos de situações que o candidato já viveu e que reforcem esse valor. Além de que, todos os candidatos de engenharia são entrevistados por mim e pela CEO.
Testamos diversas formas nesses 4 anos.
Por muito tempo, nós enviávamos um desafio técnico e pedíamos um prazo pra entrega, mas tínhamos uma baixa conversão já que muitos não entregavam, desistiam do processo ou pior - a própria pessoa não foi quem fez o desafio. Fora que muitas vezes, era difícil saber exatamente o que olhar na hora da avaliação .
Tentamos usar plataforma de teste online, o que era legal, mas também tinha baixo engajamento e não conseguíamos medir tudo o que queríamos.
O modelo que melhor se enquadrou para a nossa realidade e para o que queremos avaliar no candidato foi o desafio técnico em pareamento com alguma pessoa desenvolvedora da Gupy.
Aplicamos um desafio que provoque o candidato tecnicamente: a pessoa que pareia faz perguntas, analisa e pede refactorings. Com isso, conseguimos ter uma sensibilidade mais próxima da realidade de como:
Hoje, se ela gabarita nosso teste, realiza os refactorings que a provocamos fazer e vemos uma boa desenvoltura na escrita dos testes, conseguimos ter segurança de que essa pessoa vai se sair bem no nosso dia a dia.
Além disso tudo, eu também faço uma entrevista direta, para validação de cultura de engenharia, e tento extrair do candidato o que ele pensa sobre tecnologia, como aborda determinados problemas e verifico se o foco vai estar na solução de problemas, e não usar tecnologias do hype só por usar.
Leia também: O guia para encontrar e contratar desenvolvedores
O processo de checagem e aprendizado não termina quando o candidato começa na Gupy.
Temos um processo de onboarding que tem como objetivo expor o candidato às nossas tecnologias, através de um projeto que não seja crítico, mas que gere bastante valor ao nosso negócio, foque a pessoa a conhecer nossa tecnologia e arquitetura, reforce a nossa cultura e avalie se essa pessoa atende as nossas expectativas.
Quando ele termina, temos uma cerimônia muito legal de "formatura", na qual o novo ou a nova Gupier apresenta seu projeto, quais foram os desafios, próximos passos e faz os agradecimentos desse processo. (Fizemos um artigo especial falando um pouco do onboarding Gupy, corre para ler!)
Mais importante do que falar de stack, linguagens e infra, acho que o que faz diferença é a cultura de engenharia, os indicadores de sucesso que são atacados no dia a dia.
Aqui, nós trabalhamos muito para evoluir a cada dia nossa cultura de engenharia, aplicando as práticas de cultura de DevOps e perseguindo indicadores que realmente façam sentido e guiem o time para uma evolução técnica que não seja baseada em modismo e preciosismo técnico, mas em melhorias que gerem valor ao negócio.
Hoje, acompanhamos e trabalhamos para melhorar 7 indicadores principais em engenharia, onde enxergamos que para conseguirmos melhorá-los, muitas reestruturações precisam ser feitas tanto tecnológicas, quanto em processos.
Os indicadores são:
É o tempo que a plataforma fica disponível para os usuários.
Nesse ano, estamos com 99,99% e conseguir isso não foi fácil, dado que temos um grande crescimento e mudanças rápidas de realidade semanalmente.
Medindo o Uptime e trabalhando para melhorá-lo, consequentemente melhoramos nosso tempo de resposta a incidentes. Para conseguir otimizar esse indicador, precisamos aprimorar muitas outra coisas como infraestrutura, automação, deploy, testes e monitoramento. Portanto, perseguí-lo te obriga a arrumar a casa.
Lead time para nós é o tempo decorrido entre o momento em que uma pessoa inicia a realização de uma tarefa e o momento em que essa tarefa vai para produção com sucesso.
Para otimizar o Lead time, você precisa granularizar bem as tarefas, padronizando o tamanho e deixar redondo o processo de code review, testes de aceitação e os testes automatizados.
Assim, começa a ficar mais fácil você entender a capacidade de vazão do seu time. Para isso, o processo de deploy precisa estar bem definido e o próprio deploy, ser confiável também.
Tempo médio que os nossos serviços respondem. Esse é outro indicador que nos obriga a ter uma boa qualidade no desenvolvimento, otimização de queries, infra em dia etc.
Além disso, o monitoramento desse indicador nos ajuda a prever determinados tipos de problema. Geralmente é o primeiro indicador a se alterar quando temos algum problema.
É basicamente o tempo máximo de 99% das requests mais rápidas nos nossos serviços. Usamos ele para não deixar que a média nos engane, de modo que o número de requisições rápidas, com menos de 15ms nos nossos serviços, são muito maiores e levam sempre nossa latência média para baixo.
Temos o P99 para garantir que nossos usuários tenham uma experiência boa e que endpoints lentos, mesmo que chamados com menor frequência, vão impactar algum indicador.
Começamos a acompanhar esse indicador mais recentemente e hoje, fazemos uma média de 20 deploys por dia. Mas deploy já foi um grande problema. Um ano atrás nós fazíamos 2 ou 3 deploys por semana e hoje, realizamos 20 por dia.
São os bugs que nossos usuários pegam e abrem um ticket. Bugs que são pegos nos processos internos de qualidade atrapalham o indicador Lead time e, se ele piora, sempre estudamos a causa.
É muito importante monitorar e agir em cima de bugs escapados: evitá-los te força a refletir muito sobre seus processos, sua arquitetura, sobre os gaps de seu time entre outras coisas.
Alguns erros nem sempre são relacionados a um bug de feature, às vezes é infra, timeout de alguns serviços ou situações que seu backend não esperava.
Monitoramos e agimos em cima desses bugs, pois isso te força a melhorar processos de deploy. Muitos de nossos erros 502 no começo da Gupy eram por não usar técnicas como graceful shutdown ou blue-green para fazer o deploy.
Já pegamos problemas no auto scaling, já vimos a necessidade de ajustar métricas de auto scaling, entre diversas outras evoluções que tivemos que fazer para evitar erros 5XX.
Essa métrica é polêmica! Comecei a acompanhá-la quando tive problemas de previsibilidade de entrega no nosso time e realmente não sei se ela se aplica a qualquer contexto, mas no contexto em que eu estava na época, ajudou bastante.
Prometer 30 pontos em uma sprint e entregar 20 é obviamente ruim, mas e entregar 40 quando prometeu 30? E entregar 50 quando prometeu 30? Para mim, é tão ruim quanto. Na minha visão, é um indicador de que o time está estimando mal e não de que está produzindo muito mais.
Para tentar resolver isso, colocamos como meta ter, em um trimestre, uma dispersão máxima de 10% para menos e 20% para mais nas sprints.
Muitos disseram, e eu concordo em certo nível, de que uma meta dessa pode fazer com que o time seja sempre pessimista e entregue menos do que poderia para garantir que fique dentro da dispersão desejada.
Mas não foi isso que aconteceu no nosso time: ele passou a fazer mais reuniões de Grooming para calibrar as estimativas, outros passaram a usar uma régua base de complexidade, porém cada um adotou uma estratégia.
Tivemos sucesso com essa métrica porque confiamos na nossa equipe, na nossa cultura e fiz um trabalho junto com os líderes técnicos para garantir que isso não fosse um incentivo perverso.
Acho que vai muito da forma como você aborda o tema e certamente, em um ambiente de pouca confiança, isso não funcionaria. Por isso, sempre digo que essa métrica muito provavelmente só se aplica em contextos específicos em um ambiente de confiança.
Espero que compartilhar um pouco do que aprendi possa ajudar líderes que estão vivendo ou viverão situações parecidas. É sempre preciso refletir muito, analisar o cenário e o contexto para conseguir tomar as melhores decisões.
A minha experiência nesse cenário é bem específica e certamente, o que eu fiz pode não funcionar em determinados ambientes, mas também me baseei em alguns autores que estudaram profundamente empresas de diferentes tamanhos e realidade.
Com certeza um repertório vasto de conhecimento sobre engenharia de software, DevOps, Agile, Lean, entre outras, vão te ajudar a superar os desafios específicos de seu contexto.
Para fechar o texto, deixo como sugestão a leitura do livro Accelerate, da Nicole Forsgren, Jez Humble e Gene Kim, que basicamente mostra uma análise sobre o que os times de engenharia fizeram para garantir o sucesso de empresas de várias realidades diferentes.
Gostou do artigo de Robson? Então, confira o talk dele e nosso cientista de Dados, Carlos Baia, sobre como funciona a inteligência artificial da Gupy!