“Toda escolha é um tradeoff”. Essa foi a frase que mais chamou atenção no Keynote (apresentação quinzenal que temos aqui no Pagar.me) onde decidimos por tirar parte da autonomia dos nossos squads. Sim, você leu certo, tiramos parte da autonomia que tínhamos para gerenciar as tarefas em cada squad.
Um medo muito grande de qualquer empresa que já foi uma startup é o de adicionar cada vez mais camadas de burocracia a cada fase de expansão, seja com a entrada de novos funcionários, com a receita crescendo absurdamente ou com cada vez mais produtos tendo que ser mantidos. E não é diferente aqui no Pagar.me.
A empresa foi criada por jovens e sempre teve uma cultura que dava bastante autonomia no dia a dia: um novo produto pode surgir da ideia de alguém que entrou mês passado na empresa, um processo pode ser tocado independentemente do cargo da pessoa se ela estiver afim e também mostrar que vale a pena.
No começo de 2017 vimos o quanto estávamos crescendo e o quanto ainda pretendíamos continuar contratando. Com isso surgiu a necessidade de dividir a equipe de desenvolvimento em squads*, *o modelo foi refinado algumas vezes, até que chegamos a um escopo. Os squads possuíam autonomia para fazer o projeto acontecer da forma considerada mais adequada, com autonomia para gerenciar tarefas e ferramentas.
E aí começaram as divergências.
Com a autonomia para gerenciar tarefas cada squad acabou optando por um processo diferente, alguns usaram Scrum, outros Kanban. Também foram feitas adaptações em cima de processos já existentes, retirando reuniões diárias ou fazendo-as remotamente, por exemplo.
O planejamento do produto também não era algo comum a todos, já que podiam surgir demandas pontuais e muitos imprevistos.
A ferramenta utilizada para gerenciar as demandas também não foi unânime, já que temos muitas opções à disposição: usar GitHub ou Trello? Ou ainda o JIRA? Quando usar o GitHub, gerenciar issues por labels, definir milestones ou um simples board do Projects resolve? Difícil responder.
Percebemos então que era preciso rever essas questões: achávamos que tendo autonomia poderíamos aumentar a produtividade em larga escala, e deixar cada um resolver o problema da forma mais adequada a cada situação. Porém não aconteceu assim, já que podia perder-se muito tempo testando metodologias. A troca de conhecimento e experiência entre as equipes também foi dificultada, pois a imersão no produto era grande.
Não ter um certo grau de padronização dificultou muito a possibilidade de conseguirmos analisar o quão perto dos objetivos de um trimestre o time está, por exemplo.
Tradeoff
Começamos então a notar que por termos optado pela autonomia perdemos muito durante o processo. Porém ainda assim ao pensar em padronizar qualquer coisa, um calafrio já subia na espinha e trocávamos de assunto: estávamos focando nos pontos negativos de uma escolha, ao invés de focarmos em tudo que poderia ser maximizado.
Chegamos no dia do Keynote, quando ouvi que “toda escolha é um tradeoff”. Percebi aí mais um aprendizado muito valioso para minha vida: ao tomar uma decisão devemos focar muito mais no lado bom do que no ruim. Depois de analisar os pontos positivos e negativos, pensarmos em como minimizar os negativos, sem deixar que eles nos assustem e nos impeçam de tomar uma decisão.
Processo de padronização
Ao levantarmos essa possibilidade nenhuma decisão chegou top-down, quando um “cargo” mais alto decide tudo e apenas informa os que estão abaixo.
Primeiro foi feita uma pesquisa aberta na qual todos os envolvidos poderiam opinar quanto ao assunto. O que cada um via de bom? O que achavam que podia acontecer no pior caso quando uma das decisões fosse tomada? Quais eram as ferramentas já utilizadas por cada time e o motivo disso?
Com a pesquisa feita e os resultados abertos, continuamos a discutir para chegarmos a uma decisão final, que foi a de padronizar metodologias e ferramentas para todos os squads. Nisso incluem-se definições de roadmap trimestral, nas quais os Product Owners (ou Business Leaders, como chamamos no Pagar.me) ajudariam bastante.
E o que ganhamos com isso?
- Visibilidade: a partir desse ponto fica mais fácil visualizarmos em que ponto cada um está, comunicar sobre novas features de forma mais organizada, identificar e melhorar os pontos críticos do desenvolvimento e conseguir avaliar melhor a performance do time.
- Troca de conhecimento: padronizar não significa deixar de aprender ou evoluir. Agora fica muito mais fácil o intercâmbio de pessoas entre squads, já que todos utilizam a mesma metodologia. Além disso, como todas as equipes agora estão testando o mesmo processo, cada uma delas pode identificar pontos a serem melhorados em cada caso.
- Ferramentas unificadas: decidimos por utilizar o GitHub Projects e trabalhar com labels e milestones para acompanhar o status de cada tarefa e de cada objetivo macro do time.
O futuro
Hoje em dia a equipe técnica do Pagar.me sabe que não se deve editar um código do core do sistema na máquina de produção. Já vimos todo o tipo de erro, confusão e problema que isso pode causar, e não vamos deixar que aconteça de novo. A cultura de pull requests, code review e testes unitários, já está muito bem instaurada no sangue de todos por lá, e é esse o nosso objetivo com a padronização de tarefas e processos.
Vamos tentar adaptar onde for necessário, retirar o que não for, trocar conhecimento e evoluir os modelos. Não vamos descansar até que isso não seja mais um monstro, que assombra o sonho dos jovens que vêm de um mundo de startup.
Nos vemos em breve!