A decisão de reescrever toda a plataforma da Olist foi extremamente arriscada. Quase tudo em uma startup gira em torno do risco e das formas como gerenciamos ele. Com desenvolvimento de software não poderia ser diferente.
Estamos contratando!
Gostaria de fazer parte da equipe de desenvolvimento Olist? Participe do nosso processo seletivo.
O desafio, nesses casos, é gerenciar esse risco para reduzi-lo onde é possível e para criar contingência para as situações onde o imponderável surge.
Para lidar com isso defini alguns elementos que precisariam ser definidos para nos guiar nessa empreitada arriscada:
- Equipe
- Processo
- Tecnologia
- Escopo do Projeto
O objetivo deste artigo é descrever a nossa abordagem para cada um desses tópicos. Está funcionando para nós mas não significa que funcionaria para todo mundo.
Equipe
Esse elemento é o mais importante de todos. Para fazer um projeto e uma empresa dar certo precisamos ter pessoas ótimas ao nosso lado. Para fazer parte da equipe de desenvolvimento da Olist cada participante precisa ter algumas características bem específicas.
Trabalho em Equipe
Na Olist a equipe sempre prevalece. Na nossa equipe sempre admiramos programadores brilhantes mas eles não “sobrevivem” se não conseguirem trabalhar bem em equipe.
O desenvolvedor que trabalha bem em equipe é aquele que divide as glórias do seu trabalho com os colegas e ajuda o outro quando necessário mesmo que isso lhe atrapalhe um pouco. É o desenvolvedor que aceita a decisão da equipe (sem resignação) mesmo não concordando totalmente com ela. Ele defende sua visão, com argumentos, até o limite de suas convicções.
É o programador que corre para ajudar a equipe a resolver qualquer problema. Mesmo aqueles que só aconteceram porque a equipe não deu ouvidos à ele. Ajuda a equipe sem ressalvas e sem jogar um “eu não avisei que isso ia dar errado?”.
Na Olist a equipe desenvolve, a equipe erra, a equipe corrige, a equipe decide, a equipe… A equipe.
Sem mimimi
Esse é um valor da empresa que levamos ao limite na equipe de desenvolvimento. A equipe toda é muito brincalhona (zoam tudo), politicamente incorreta, e rotineiramente “perdem o amigo mas não a piada”. A zoeira não tem limite. Isso não é imposto por ninguém mas esse comportamento “emergiu” com o crescimento do time.
Se o código está ruim isso será dito assim: “isso está bem ruim” (nunca vi um “isso está uma m*”, mas não acho impossível acontecer). E o autor do código tem que interpretar isso como: “cara, a gente sabe que você consegue fazer melhor do que isso”.
Experiência > Quantidade
No momento que escrevo esse artigo estamos com 11 desenvolvedores e algumas vagas abertas. É o número ideal para o projeto que estamos desenvolvendo. Preferimos poucos programadores com muita experiência e capacidade do que um exército de programadores medianos.
Trabalho Remoto
É difícil ter os melhores se restringimos a busca à cidade onde estamos (Curitiba). Abrir a oportunidade para qualquer pessoa no Brasil (ou no mundo?) trabalhar com a gente foi a estratégia perfeita.
O trabalho remoto não é “bala de prata”. É necessário um ótimo planejamento, boas ferramentas, bons processos e bons profissionais para fazer isso dar certo.
Eu já tinha experiência na implantação desse modelo de trabalho. Assim que convenci o restante da empresa que isso daria certo foi só colocar em prática para mostrar os benefícios.
Pretendo escrever artigos falando especificamente sobre trabalho remoto e equipes distribuídas. Aguardem.
Processo
Para desenvolver um sistema inteiro, do zero, com um deadline claro (1 de outubro) com uma equipe distribuída e com pouco tempo trabalhando junto (começamos a formar a equipe em janeiro) é necessário definir um processo de trabalho e segui-lo religiosamente.
Sou um entusiasta de métodos ágeis mas não gosto de adotá-los tal como nos livros. Eu prefiro ter a essência agilista em mente e pinçar certas práticas na minha caixa de ferramentas. A construção do processo também é algo que fazemos em equipe.
Conforme a equipe começa a trabalhar dedicamos um momento do nosso tempo para discutir o próprio processo. O processo que a gente tinha em janeiro é diferente do que temos agora.
Isso é meio óbvio: a equipe muda, o conhecimento da equipe muda, o escopo muda, a empresa muda, tudo muda… é meio burro ficar repetindo as mesmas práticas durante todo esse tempo.
Vou falar sobre as práticas que mantemos desde janeiro até agora. Isso pode mudar em breve.
To Sprint or not to Sprint
Indivíduos e interação entre eles mais que processos e ferramentas — Manifesto Ágil
Oficialmente não temos sprint. Mas nosso Kanban está configurado para operar com SCRUM, logo, ela trabalha com sprints. Isso parece meio esquisofrênico mas o prazo ali é só uma linha para avisar sobre nossa reunião de retrospectiva e planejamento.
Já tivemos sprints semanais, quinzenais, já trabalhamos sem sprint. Hoje estamos com 15 dias.
O fato é que não temos burndown chart; estimamos as histórias apenas como avaliação de entendimento delas e não para contar pontos; não fechamos o sprint com histórias, … enfim… o que fazemos lá mataria qualquer scrummaster do coração :)
Lendo isso parece que não temos processo nenhum mas não é verdade. Temos um processo nosso que não se importa com métricas inúteis cujo propósito é o de acalmar gerentes que nunca desenvolveram uma linha de código na vida.
Tem horas que esse processo se parece bastante com SCRUM. Tem horas que não.
Comunicação
Já disse que nossa equipe é distribuída e que valorizamos muito mais a equipe que o indivíduo. O nosso quadro Kanban é a ferramenta principal de comunicação da equipe. Ali está o projeto, o que precisa ser feito, quem está fazendo, etc.
A ferramenta que usamos é o JIRA. É difícil de configurar mas depois que configuramos ela “just works”.
Toda a documentação sobre o sistema, a equipe, a forma de trabalhar, as diretrizes básicas de desenvolvimento, contato da equipe, etc ficam na nossa Wiki. A ferramenta que usamos para Wiki é o Confluence. Porque integra bem com o JIRA.
Também usamos Slack para comunicar com o restante da empresa e com outros sistemas através de integrações. Eu, particularmente, não curto o Slack mas a equipe gosta.
Mas a nossa arma secreta para comunicação do time é o software para audioconferência: Mumble. Temos uma instância na AWS em São Paulo (menos latência) rodando um servidor Mumble onde toda a equipe e mais alguns convidados se conectam para as reuniões.
O Mumble é feioso mas ele faz algo que nenhum outro software de audioconferência consegue fazer: ele funciona.
Só temos audioconferência. A prática de 5 anos trabalhando remoto mostrou que videoconferência é uma idéia ruim. O vídeo distrai as pessoas da mensagem e as ferramentas são ainda piores que as de audioconferência.
Temos uma deficiência grave na integração quando queremos debater soluções técnicas com desenhos e diagramas. Não encontramos nenhuma ferramenta que funcione bem para isso. Enquanto não temos isso um desenvolvedor faz um esboço do projeto na Wiki e os outros integrantes da equipem colaboram.
Teste automatizado
Todo nosso código é desenvolvido com testes automatizados (não é TDD).
Os testes que desenvolvemos são bons mas sempre buscamos melhorar aplicando novas práticas e técnicas.
Revisão de Código
Toda empresa que desenvolve software deveria estimular essa prática (estimular != obrigar). A revisão de código traz grandes benefícios para a equipe:
- Collective Code Ownership — quando um desenvolvedor revisa o código de outro em uma parte desconhecida do sistema ele passa a conhecer esse código e pode lidar com ele quando o autor original não estiver disponível.
- Homogenização do conhecimento — em uma equipe sempre temos graus de conhecimento distintos entre cada integrante. A revisão de código distribui melhor esse conhecimento. Cada programador aperfeiçoa também a prática de ler código que anda muito negligenciada nos dias de hoje.
- Qualidade — mais olhos observando o mesmo código conseguem encontrar problemas mais facilmente.
Cerimônias
Temos algumas cerimônias (reuniões) onde juntamos todos os desenvolvedores no Mumble para organizar o trabalho. Os horários e quais cerimônias fazemos varia ao longo do tempo mas uma delas é constante: Daily Meeting.
Na Daily fazemos um exercício de organizar as frentes de trabalho, ajustar o Kanban, traçar estratégias de curto prazo, pedir ajuda e ajudar os colegas da equipe.
A reunião de Retrospectiva também é frequente. Na Retrospectiva discutimos e alteramos o próprio processo de trabalho.
Outras cerimônias que também temos são: planning (planejamento da semana/sprint) e time-boxed grooming (preparação de histórias para a planning).
Tecnologia
Não vou entrar em muitos detalhes nesse tópico porque pretendo escrever um artigo específico sobre ele.
As tecnologias que escolhemos para desenvolver a nova plataforma são bem “arroz com feijão”. Até temos algumas pitadas de coisas novas mas nada excepcional. A nossa pilha de software tem basicamente:
- Python — linguagem
- Django/Django REST Framework — framework para APIs
- asyncio/aiohttp/loafer — workers para processamento de mensagens
- Redash — BI
- AWS SNS — tópicos (PubSub)
- AWS SQS — filas de mensagem (PubSub)
- AWS Lambda/DynamoDB — auditoria
- Heroku — PaaS (deployment)
- Heroku PostgreSQL — banco de dados
- Github — code management & code review
- CircleCI — continuous integration
- New Relic — monitoramento/performance
- Sentry — monitoramento de erros
- Logentries — gerenciamento de logs
- Hosted Graphite — métricas
Ao escolher uma ferramenta:
- Preferimos hosted services à self-hosted services (ex. Heroku à AWS EC2)
- Preferimos ferramentas que a equipe já conhece àquelas que “estão na moda” (ex. Python à Node)
- Preferimos alternativas “arroz-com-feijão” àquelas que são “a última novidade” (ex. Web Application convencional à Single Page Application com Angular/React)
Escopo do Projeto
Esse elemento foi um dos mais complicados para gerenciar. O tempo não permitia desenvolver tudo o que era necessário para o negócio funcionar de modo eficiente. Então o que cortar?
O modelo de negócio Olist é extremamente integrado. Então cada um dos componentes que já existiam na versão antiga do sistema precisariam continuar existindo. Mas não daria tempo para implementar tudo tal como estava no sistema antigo. Foi necessário simplificar as ideias e conceitos do sistema à um ponto onde teríamos algo essencialmente simples. E fazer algo simples é bem complicado.
Erramos e acertamos várias vezes nesse processo. Priorizamos mal e priorizamos bem. Escrevemos histórias ruins e histórias boas. Fizemos tudo sozinhos e fizemos tudo com a ajuda da equipe de Produtos. Vestimos vários chapéus diferentes: fomos developers, product managers, scrummasters, project manager e até designers :)
Por conta desses problemas o escopo do projeto não foi 100% atendido até o momento da implantação. Algumas funcionalidades importantes ficaram de fora e foram necessários mais uns 40 dias extras para finalizar o projeto com o escopo completo.
Mas o mais importante é que aprendemos a lição e já temos planos para melhorar nesse aspecto.
Considerações Finais
Reescrever um software do zero, migrar os dados para esse software com o negócio em pleno funcionamento e fazer isso em uma startup é um desafio gigante e extremamente arriscado.
Se não tivéssemos o cuidado de encarar essa empreitada com uma boa equipe, um bom processo, boas tecnologias e um escopo enxuto as coisas certamente teriam dado errado.
