Novo desenvolvedor na Olist
O que posso dizer até agora
Faz algum tempo que comecei a trabalhar na Olist e desde as primeiras semanas venho me surpreendendo positivamente. Surpresas não são incomuns quando você começa a trabalhar em um lugar novo. Porém depois de passar por diversas empresas diferentes nos últimos anos, não seria qualquer entusiasmo de emprego novo que me motivaria a parar para escrever.
Meu histórico profissional remete a uma carreira um tanto quanto comum como desenvolvedor de software. Estagiário, programador junior, pleno e sênior (só cheguei até aqui ainda :P). Mudanças que ocorreram trabalhando em consultorias tradicionais, outras mais descoladas, instituto de pesquisas ou empresas de produtos. Dez funcionários, cem ou milhares ao redor do mundo. Com certeza em cada uma delas o aprendizado foi enorme e as supresas também, mas nenhuma me surpreendeu como a Olist.
Para quem ainda não conhece, a Olist é uma empresa que, mais do que auxiliar vendedores a chegar aos maiores marketplaces do Brasil, é a maior comunidade de lojistas exclusivos do país. Além de toda complexidade de negócio que a Olist resolve, há diversos desafios técnicos que precisam ser encarados por aqui. Para saber mais sobre os fundamentos técnicos da Olist já existe um ótimo artigo:
Desenvolvedor desenvolve
Pode parecer redundante, mas não é difícil encontrar programadores que estão infelizes em seus empregos por não atuarem com o que são apaixonados por fazer: programar. Ou então que são encorajados a assumirem novas responsabilidades para evoluirem dentro da companhia. Pessoalmente eu acredito que sob um falso mérito de versatilidade, o mercado vem atribuindo tantas funções a um desenvolvedor de software que não raro mais de 80% da rotina de um programador envolve fazer tarefas alheias àquelas relacionadas ao desenvolvimento de software propriamente dito.
Aqui na Olist eu venho me surpreendendo com a quantidade de tempo em que eu posso de fato ser um programador. E não me entendam mal os desavisados. Ser um programador está longe de passar o dia digitando código em uma tela preta. Podemos dizer que algumas tarefas que compõe um dia de desenvolvedor por aqui vão desde codificar novas funcionalidades de fato em “tela preta”, até revisar criticamente o código produzido pelo time, participar de discussões técnicas, ser ativo e relevante em decisões arquiteturais, fazer constantemente refatorações, implementar testes cada vez melhores, mais robustos e de valor. Ou seja, tenho visto que por aqui um programador pode (e deve) entregar valor ao time fazendo o que mais gosta de fazer.
O chefe também programa!
O nosso CTO também é um desenvolvedor ativo. Seja em projetos internos ou de código aberto para a comunidade, o osantana está sendo o chefe mais desenvolvedor que eu já tive. E não sabia quanta diferença isso poderia fazer!
Invariavelmente no mercado, por mais disruptiva ou horizontal que a hierarquia de uma companhia possa ser, o papel da pessoa que gerencia ou coordena equipes de desenvolvimento é ocupado por um Gestor (sim, com G maiúsculo) ou por um programador completamente defasado e inativo.
Ter um chefe que “é gente como a gente” tráz diversas vantagens. Uma delas é que temos ao nosso lado uma pessoa que compreende profundamente as diversas tarefas que mencionei no tópico anterior. Esse fator faz com que a comunicação seja muito mais fácil, isso quando a gente precisa comunicar. Se estamos passando por um período crítico seja em função de um bug afetando produção, por uma refatoração complexa ou mesmo porque precisamos focar em compreender uma nova tecnologia, nosso chefe sabe que estamos passando por esse momento e o que menos precisamos é alguém gerando impedimentos e distrações burocráticas. Além disso, o osantana é um cara extremamente experiente e que diariamente está disposto a nos ensinar em cada mensagem no chat ;)
Equipe apaixonada pelo que faz
Sobre a disposição em colaborar genuinamente não é uma característica que se limita ao CTO. Isso é comum a todas as equipes da Olist, inclusive a de tecnologia. O problema (ou mérito) de um é compartilhado por todos. Essa colaboração genuína é algo que realmente vem me surpreendendo na área de desenvolvimento.
Uma parte de mim espera que eu esteja contaminado pelas minhas próprias más experiências, mas encontrar programador com o ego maior do que a vontade de contribuir com o time é algo bastante comum. Em pouco tempo de casa eu já pude presenciar atitudes de ajuda genuína e não por promoção própria. De dedicação por paixão em fazer algo bom e novo, e não para bajular uma ou outra pessoa.
Aqui na Olist não existe nem dono de código nem dono de bug. O código é produzido pelo time. Se um bug surge é de responsabilidade de todo o time. Isso não implica simplismente que todos irão parar para fazer a mesma coisa, mas sim que o time irá se organizar para melhor solucionar o problema. Se um erro foi cometido, ele foi cometido pelo time. Se há uma falha no código, a falha é do time. Se alguém precisou escrever um código de má qualidade, outros precisaram rever o código e aprová-lo. O processo que seguimos por aqui faz com que todos de fato sejam responsáveis pelo que é produzido, seja bom ou seja ruim.
Trabalho remoto que funciona
Na Olist toda a equipe de desenvolvimento trabalha remotamente. A empresa possui seu escriório em Curitiba com os times de outras áreas por lá, mas exclusivamente os desenvolvedores trabalham remoto. Existem diversas explicações para isso que deverão render um novo artigo em breve. Porém o que é relevante destacar é que se trata de uma equipe remota que funciona. Produz software excelente, gera inovação constante, estabelece uma cultura de desenvolvimento que é passada de pessoa para pessoa e o mais importante: gera valor real para o negócio.
Uma equipe de produtos que faz a diferença
Quem supostamente trabalha com algum método ágil de desenvolvimento por aí vai entender o que eu vou dizer agora. Existe uma má compreensão generalizada sobre o manifesto ágil que, dentre diversos malefícios, trouxe um que afeta diretamente o trabalho do desenvolvedor: estórias (ou tarefas) extremamente mal especificadas. Eu presumo que esse costume tenha sido derivado da afirmação de que software em funcionamento é mais valorizado do que documentação abrangente ou de que a melhor forma de comunicação seja face a face. Sem querer me prolongar nesse tópico e independente de onde isso tenha surgido, a má prática de se especificar mal ou pouco uma tarefa é bastante comum.
Quando li a primeira especificação de uma tarefa escrita aqui na Olist eu fiquei um pouco espantado. Estava tudo ali. O que era pra se fazer em um nível de detalhe suficiente, o propósito, o impacto que aquilo geraria para o negócio, os pontos do sistema que precisariam ser alterados ou que seriam afetados e qual era a definição de pronto da tarefa (o que sempre gera debate quando não se define). Posteriormente quando pude participar de uma sprint desde o início pude perceber que os desenvolvedores têm sim papel importante na definição dessas estórias, ajudando em aspectos técnicos ou mesmo dando feedbacks sobre o que não está tão claro. Porém a resposabilidade de liderar a criação, definição, priorização e organização do nosso backlog é exemplarmente feita pela equipe de produtos.
Se desejar saber mais sobre a criação e evolução da equipe de produtos da Olist, o Luiz Davi Leitão Martins falou mais sobre isso no artigo abaixo.
Pra encerrar
Eu não sei dizer como será o futuro, mas posso dizer que até o momento as coisas vão muito bem, obrigado. Tão bem que o ambiente no qual eu estou inserido hoje me fez sair de um hiato de mais de 2 anos sem escrever nada. A interrupção pode ter acontecido por diversos motivos, mas o fator que me fez sentir confortável e encorajado para escrever novamente, com certeza é composto por como as coisas acontecem por aqui.
Se ficou um gostinho de fazer parte do time, seja você uma pessoa desenvolvedora ou não, confira a nossa página de oportunidades. Uma dica: nós estamos sempre procurando ótimos talentos ;)
