Lições aprendidas no meu último emprego
Alguns dias atrás encerrei um ciclo profissional muito importante na minha carreira. Foram 2 anos e meio no C6 Bank, período no qual lançamos o banco, diversos produtos e, principalmente para mim, a Conta Global, um produto inovador e divisor de águas dentro da empresa. Fui desenvolvedor sênior e depois tech lead nessa squad, estando nela durante toda minha estada na empresa.
A Conta Global é uma conta corrente em moedas estrangeiras (no momento da escrita, está disponível em Dólar e Euro), que os clientes do C6 podem usar para converter em tempo real de/para reais. O Cliente conta ainda com um cartão de débito internacional para usar em viagens ou compras em sites internacionais.
No momento que começamos esse projeto, não havia nada semelhante no mercado, e precisamos descobrir como tornar esse produto possível. Diria que esse foi o maior desafio da minha carreira, realizado fazendo parte de um time incrível.
Os últimos dias na empresa foram de muita reflexão, e pude recapitular muitas das lições aprendidas. No meu último dia, fiz uma apresentação para a minha -agora- antiga squad chamada “O que aprendi em 30 meses no C6 Bank”. Esse texto recapitula e amplia essa apresentação.
Dividi a apresentação em 3 partes, EU, NÓS e ELES. Vou procurar seguir a mesma estrutura nesse texto.
EU
No período que passei no C6, me tornei melhor no meu ofício: Engenheiro de software.
Sou desenvolvedor há 21 anos, mas já escrevia código desde a adolescência. Posso, entretanto, afirmar que esses últimos 2 anos de ensinaram mais sobre a ciência arte de escrever código do que as duas últimas décadas. Essas foram as principais lições:
TDD faz diferença
Eu já vinha “flertando” com Test Driven Development há alguns anos, mas, devo confessar, eu acabava me perdendo. A falta de cultura de automação de testes e visão moderna sobre qualidade que, infelizmente, ainda impera no nosso mercado, acabavam me limitando. Até então, pra valer, eu só conseguira aplicar TDD em projetos pessoais e acadêmicos.
O C6 foi terreno fértil para desenvolver efetivamente essa habilidade, pois encontrei uma organização com alta maturidade quanto a automação. Meus colegas estavam abordo e embora muitos não praticassem efetivamente TDD, todos estavam comprometidos a alcançar e manter os altos níveis de cobertura de testes, mesmo que fosse escrevendo os testes depois de implementar o código de produção.
Escrever código guiado por testes em uma code base compartilhada com o squad, com demandas reais e prazos reais me levou a outro nível. Posso dizer, sem dúvida, que a prática do TDD melhorou meu código, ao me tornar capaz de produzir código testável e, por consequência, fácil de ser aprimorado e refatorado.
Você ainda não pratica TDD mas gostaria de começar? Dê uma olhada nesse texto que escrevi meses atrás:
Delegue para seu ”eu futuro, aquele otário”
O percursor da ciência da computação, Donald Knuth, escreveu a célebre frase:
“Premature optimization is the root of all evil”
Em tradução livre “otimização prematura é a raiz de todo o mal”.
Muitos dos desafios encontrados por mim e por meus colegas era criar coisas completamente novas. No projeto da Conta Global, isso foi particularmente notável, pois nunca antes um produto semelhante havia sido lançado. Estávamos, junto aos experts de domínio, entendendo como o produto funcionaria à medida que íamos fazendo as entregas do nosso primeiro MVP.
Lembro que uma das primeiras decisões (erradas) que tomei em uma das nossas primeiras sprints foi tratar como lista dois valores que eram utilizados no cálculo de uma cotação de dólar: o spread do banco e os impostos cobrados.
O meu racional podia ser louvável: Como temos incerteza quanto ao que precisará ser cobrado, vamos dar suporte a uma lista.
Acontece que ambas listas nunca tiveram mais que um elemento, e a carga cognitiva de trabalhar com uma lista em um campo onde um simples valor numérico seria suficiente nos atrapalhou por mais de um ano, até o dia em que revisitei o código e alterei para um item simples.
Aprendi a não sofrer por antecipação. Desenvolver código junto com Product Discovery é uma das coisas mais interessantes que já fiz na minha carreira, mas a lição aprendida foi nunca tentar adivinhar o futuro. O mais simples é, sempre, o mais eficaz.
Uma vez aprendida essa lição, adotei o bordão que usei tantas outras vezes: “Deixemos alguns problemas para nossos eus futuros, aqueles otários”.
Carro tem que ter radiador
Nesse ciclo no C6 acabei sendo promovido além do nível sênior. Cada organização tem um nome diferente para designar o engenheiro de software que foi além do que o mercado chama de sênior. Alguns chamam de especialistas, outros de tech leads, staff engineer, principal, entre outras denominações.
Uma das tarefas da pessoa desenvolvedora nessa posição é apoiar as pessoas de produto no processo de Discovery e escrita das histórias.
Uma preconcepção, ingênua, que as (ótimas) pessoas de produto com quem trabalhei nesse período utilizavam para identificar as histórias que iriam compor o nosso produto em construção era que a somatória de todas as features do ponto de vista do usuário equivale ao produto completo.
Essa prática reza que uma vez mapeada a jornada do ponto de vista do usuário, só falta desenvolvê-las e, magicamente, você terá seu produto.
Me incomodava um pouco essa ideia. Acredito que conseguimos ir longe dessa maneira, mas sempre pode faltar algo. Em uma conversa com o PM da nossa squad, entendemos isso através de uma metáfora:
O Carro precisa ter radiador.
Se formos criar um carro do ponto de vista da jornada de usuário (o motorista), em nenhum momento esse carro teria o radiador, ou qualquer outro componente interno do motor. Não consigo ver um cenário onde escreveríamos “Como motorista gostaria de manter o motor em uma temperatura ótima para melhor performance”.
A partir do momento que fomos além do ponto de vista do usuário, e mergulhamos mais a fundo nas histórias propriamente técnicas, conseguimos identificar o radiador do nosso projeto, mensurar o esforço do seu desenvolvimento e mapeá-lo.
O que eu reparei é que o radiador sempre acaba sendo construído, mas infelizmente muitas vezes o mesmo não aparece no board dos times, ficando sendo uma tarefa que foi feita em algum momento, por uma pessoa específica (normalmente o líder técnico) e que outras pessoas da squad pouco conhecimento tem.
No nosso caso, o PM em questão passou a conhecer profundamente nosso “motor”, e conseguiu metrificar o desenvolvimento das peças ocultas embaixo do capô. O ganho disso foi maior ownership do produto por todas as partes, maior compartilhamento de conhecimento e documentação clara do processo que levamos nesse desenvolvimento.
Não acredite em documentação fria
Essa foi uma lição de desapego.
Sou um grande adepto de documentação, um daqueles caras que passa feliz o dia todo escrevendo e detalhando decisões técnicas.
E um ambiente de intensa mudança e crescimento, entretanto, manter documentação atualizada pode virar um pesadelo.
No final, aprendi que devemos documentar as decisões imutáveis do projeto, os alicerces que o fundamentam, mas, principalmente, se apoiar em documentação viva.
Por documentação viva me refiro a documentação que gera código ou documentação gerada a partir do código. Se sua documentação e seu código caminham juntos, sempre essa sempre estará atualizada.
Tive ótimas experiências com API First, gerando boiler plate code a partir do Open API, por exemplo. Também vi muito valor em usar os testes como documentação, estruturando e descrevendo os cenários de testes de maneira que apoiem no entendimento das funcionalidades.
Livros essenciais
Sempre gostei muito de ler e estudar. Nesse período não foi diferente. Li de tudo, artigos na médium e em blogs, escutei palestras, podcasts, assisti vídeos e li muitos livros.
No que concerne ser um desenvolvedor de backend naquele cenário, identifiquei alguns livros essenciais, que não podem faltar para se ter um entendimento profundo da arquitetura daquela organização. Acredito que no estado atual da tecnologia, as mesmas obras sejam aplicáveis na esmagadora maioria das empresas. Essas obras são:
- Domain Driven Design, Tackling complexity in the heart of software, de Eric Evans
- Microservices Patterns, de Chris Richardson
- Implementing Domain Driven Design, de Vaughn Vernon
- Código Limpo e Arquitetura Limpa, de Robert C Martin.
Essa lista não tem pretensão de ser exaustiva, mas foram algumas das obras que li nesse período e me deram entendimento completo da arquitetura e code base que eu trabalhei naqueles mais de 2 anos.
NÓS
O conceito de squad multi-disciplinar é uma das coisas mais interessantes que eu enxergo na forma moderna como as empresas orientadas por tecnologia se organizam hoje em dia.
O C6 Bank segue esse modelo à risca. Uma das coisas que mais me orgulho nesse período foi ter feito parte, e participado da construção, da squad mais incrível que tive a oportunidade de fazer parte até hoje.
Como líder técnico da squad, acabei tendo contato com diversos pontos da formação de equipes que eu ainda não tinha tido oportunidade de vivenciar na minha carreira. Algumas dessas lições sobre “nós”, a squad, foram:
A Squad não pode carregar peso operacional
Era uma vez uma equipe de desenvolvimento que seu trabalho era… Desenvolver.
Essa equipe escrevia código, que era homologado por outra equipe, de testes, colocado em produção por uma terceira equipe e, a partir daí, esse código era responsabilidade de uma quarta equipe, a equipe de sustentação.
Ufa, felizmente essa história acabou. Squads modernos cuidam de todas as etapas do ciclo de vida de um produto. A máxima é: “You built it, you run it”.
Ninguém conhece melhor um produto do que quem o criou.
Isso não quer dizer que a squad tenha que ser a única responsável por sua operação. Um time de operações centralizado, que atue na linha de frente e que tenha sido treinado diretamente pelo squad pode fazer toda a diferença. Essa equipe precisa “bater bola” com a squad constantemente, e estar em dia com a evolução do produto. No nosso caso, esse time também fazia a interface com o time de atendimento.
Problemas de criticidade maiores ou incidentes prioritários são tratados diretamente pela squad, mas esforço operacional não deve fazer parte do dia-a-dia. O esforço maior do time deve ser justamente automatizar e eliminar débitos técnicos que geram incidentes, além de criar constantes melhorias em observabilidade.
Uma squad livre para atuar é um produto com baixo volume de indisponibilidade. Já uma squad presa em constantes processos repetitivos e manuais é pouco produtiva e rapidamente pode perder a capacidade de inovar.
Conhecer os pontos fortes dos colegas faz diferença de verdade
Uma coisa muito bacana que o C6 Bank nos ofereceu é a avaliação no CliftonStrengths.
Essa plataforma provê um teste de habilidades que mapeia os pontos fortes de cada um. Eu achei super interessante, pois em um primeiro momento é uma ferramenta interessantíssima de auto-conhecimento e aprimoramento pessoal.
O verdadeiro valor, entretanto, vem quando aprende também quais são os pontos fortes dos nossos colegas de equipe. Isso ajuda na divisão de tarefas e na empatia com os colegas (aliás, empatia é um dos atributos).
Diversidade vale a pena
A squad que fiz parte nesse período era diversa. Tínhamos aproximadamente 50% de mulheres. Tínhamos pessoas pretas e pardas na mesma proporção de brancas. Tínhamos pessoas LGBTQIA+ e também pessoas de todas as regiões do Brasil.
Essa squad era considerada modelo e uma das mais eficientes dentro da organização, e acredito que uma das principais razões era a diversidade. Tínhamos todos os pontos de vista possíveis para discutir os desafios que encontrávamos e no fim do dia isso fazia muita diferença.
Dentro de toda essa diversidade, entretanto, havia uma coisa em comum: Respeito. O C6 Bank é uma empresa com valores culturais muito presentes e positivos. Isso garantia que a diversidade fosse complementada por uma unicidade de valores, o que possibilitava um clima harmonioso e produtivo.
O Foco da squad é o produto
Alguns meses atrás me deparei com esse interessantíssimo texto na medium:
Identifiquei no texto muitas das práticas que nossa squad vinha fazendo. Um detalhe interessante na estrutura organizacional do C6 Bank é que produto e tecnologia são a mesma vertical, e o CTO é co-diretor com o CPO, ou seja, as pessoas de produto e tech respondam para a mesma estrutura.
A lei de Conway reza que a estrutura de comunicação de uma organização estará refletida na sua arquitetura de sistemas. Ao colocar produto e tech lado a lado, a organização faz com que as duas disciplinas sejam exercidas na mesma medida. Nenhuma decisão técnica é tomada desassociada dos objetivos e métricas do produto, e toda decisão do produto procura se encaixar dentro dos preceitos de tecnologia.
Todo tempo passado junto é valioso
Seja fazendo pair programming, seja numa mob, seja na daily… Por ser um time remoto, onde as pessoas nunca estarão ocupando a mesma sala, as ocasiões para olhar juntos o mesmo problema são, indiscutivelmente, importantes para criar a identidade de grupo.
Criamos uma “cerimônia” inédita: A daily de incidentes. Durante 30 minutos, no horário do lanche da tarde, cada um trazia seu chá ou café e o time todo analisava e atuava nos incidentes encaminhados na fila da squad.
Eu acredito que essa reunião era um aspecto muito importante para team building, pois transformamos uma situação que anteriormente era estressante, como analisar a fila de incidente, em uma reunião descontraída.
ELES
A disciplina do Domain Driven Design (DDD) estabelece a figura do expert de domínio: o stakeholder que possui o conhecimento fundamental do negócio que o produto que está sendo desenvolvido irá atender.
O projeto da Conta Global foi praticamente um caso de estudo de DDD. Fizemos toda a lição de casa: Estabelecemos a linguagem ubíqua, definimos os contextos delimitados e subdomínios. Sobretudo, envolvemos “eles”, os domain experts na construção dos produtos. E isso trouxe para mim algumas lições valiosas.
Nem todos os experts de domínio estavam prontos para construir um produto com base nas melhores práticas de engenharia de software. Abaixo compartilho alguns dos cenários que encontramos e as lições que aprendi.
Podem haver casos de paixão por ferramentas
Da mesma forma que a esmagadora maioria de nós, pessoas desenvolvedoras, em algum momento da carreira teve uma linguagem de programação predileta, uma IDE predileta, um SO predileto, os experts de domínio também podem desenvolver amores pelas ferramentas que permitem que realizem seu trabalho.
Todo mundo gosta de ser produtivo e de fazer o que precisa ser feito de forma eficiente.
O problema que ocorre é que algumas vezes perdemos de vista seu real entendimento do problema que estamos resolvendo e o confundimos pelo jeito que determinada suíte de mercado resolve aquele problema. Isso acaba impactando quando tentamos retirar responsabilidades de ferramentas e integrar essas funcionalidades dentro de uma camada de micro-serviços, por exemplo.
Aprendi a não lutar contra a paixão pelas ferramentas, mas usar um processo de engenharia reversa para entender o que é feito, e com a ajuda do expert de domínio extrair o que realmente pertence ao espaço do problema que estamos resolvendo de uma solução específica.
Algumas regras existem para ser desafiadas
Citei anteriormente os valores da cultura do C6 Bank. Existem dois valores com os quais me identifiquei bastante:
· Desafiar o Status Quo
· Exercer a arte e discordar
Ter uma cultura empresarial que incentiva as pessoas a irem além do “arroz com feijão” é importante, mas para realmente trazer inovação é preciso engajar os experts de domínio para que seja uma construção conjunta.
Algumas otimizações que são claras para os times de design, produto e engenharia podem não ser óbvias para eles. Algumas vezes nos vimos em situações em que ouvíamos “todo o mercado faz assim, por que querem fazer diferente?”.
A lição importante que aprendi nesse período foi de não enxergar a figura do expert de domínio como o “dono da verdade” ou “o grande especificador”. São profissionais, como todos, em constante aprendizado. Algumas vezes pode ser necessário tirar essas pessoas da zona de conforto em prol de entender a fundo a raiz do problema que estamos resolvendo.
Tive a sorte de trabalhar com grandes profissionais nesse período, pessoas corajosas que não tinham medo de colocar seu conhecimento a prova e expandi-lo. Para isso, uma coisa que eu aprendi a fazer era sempre trazer cenários “corner cases” e sugestões de, dado meu conhecimento limitado, porém crescente, do negócio, poderiam saná-los.
Essa dinâmica de “corner cases” me trouxe um entendimento muito maior e nos tornou hábeis a colocar na mesa coisas novas.
Amplie seu networking além das pessoas de tecnologia
Muitas pessoas de tech são introvertidas, e eu não sou diferente.
Essa experiência no C6 Bank me mostrou muito a importância de sair de dentro da concha e expandir nosso círculo de contatos com pessoas de todas as áreas. Para efetivamente conseguir realizar as entregas com a qualidade esperada, precisei cultivar uma rede de relacionamento com toda a operação.
Aprendi que isso também é uma forma de diversidade, e os colegas de outras áreas foram responsáveis por grande parte do desenvolvimento pessoal que tive nesse período.
Tive também excelentes gestores para me apoiar. Um dos feedbacks mais valiosos que eu recebi foi no contexto de conseguir fazer a comunicação entre pessoas técnicas e orientadas a negócio da forma mais natural e suave possível. Atuar nisso me trouxe muito crescimento, e consegui passar a observar essa habilidade em outras pessoas de tecnologia que para mim são grandes exemplos.
Essa passagem pelo C6 me propiciou aprendizados muito importantes e estará sempre gravada em minha memória.