Este texto foi originalmente publicado em inglês, em 7 de dezembro , no blog de engenharia do Nubank.
O Nubank sempre foi uma empresa “mobile-first” – e nossos produtos sempre foram construídos pensando em manter uma relação próxima com nossos clientes.
Nós começamos em 2013 como uma empresa de Cartão de Crédito, lançamos nosso programa de benefícios próprio – o Nubank Rewards -, e, mais recentemente, a NuConta. Todos eles possuem duas coisas em comum: foram criados para ajudar nosso clientes a retomarem o controle de suas vidas financeiras e, claro, precisam funcionar perfeitamente em smartphones.
Também trabalhamos para melhorar a produtividade e a qualidade de vida dos desenvolvedores. Um dos pontos importantes foi criar um time chamado Mobile Platform, focado inicialmente em melhorar as pipelines e as ferramentas compartilhadas. Esse time começou a focar no processo de entrega do código e lançamento do aplicativo nas lojas.
Com o squad de Mobile Platform responsável pelos lançamentos do app, foi mais fácil criar um cronograma com os releases saindo de forma independente dos ciclos de desenvolvimento de cada squad de produto.
Outro benefício de melhorar nossas ferramentas e se juntar aos times de produto é a agilidade. Com mais contexto, os desenvolvedores podem tomar decisões melhores e com resultados mais previsíveis.
No novo modelo, as decisões sobre priorização ficam em cada squad e são menos centralizadas. Às vezes, ainda há a necessidade de reunir diferentes squads – como em grandes mudanças de layout. Ainda assim, essas situações são mais simples de resolver porque cada time cuida de suas próprias prioridades e sabe o peso das suas decisões nos objetivos gerais da empresa.
Vale mencionar que ainda estamos nos adaptando ao novo sistema – e ele também tem seus desafios. Ainda assim, já é possível ver melhorias em vários times.
Dito isso, não é nenhuma surpresa que o time de desenvolvedores mobile está sempre envolvido nas decisões dos nossos produtos – e que, conforme o portfólio do Nubank cresceu, o time mobile cresceu junto.Abaixo, compartilho alguns dos aprendizados desse processo.
Como os times trabalham no Nubank
O Nubank se inspirou no modelo do Spotify, com times autônomos chamados Squads focados em objetivos específicos. Os squads possuem pessoas com diferentes habilidades que sentam juntas e têm total responsabilidade sobre o que estão criando: design, código, lançamento, manutenção, operações, etc.Cada squad possui uma missão de médio e longo prazo e define seus objetivos (OKR’s) a cada trimestre.Enquanto a maior parte da empresa sempre trabalhou em squads, até 2017 os engenheiros mobile eram um “activity oriented team“- ou um time de serviços. Nós nos dividíamos para atender às demandas de todo o Nubank, pois não havia engenheiros o bastante para atender cada squad. Nosso Head de Produto era responsável por priorizar as demandas dos squads e manter uma lista das funcionalidades a serem desenvolvidas. Os engenheiros mobile então trabalhavam nos squads no topo da lista até os lançamentos em questão. Essa forma de trabalho tinha uma vantagem: os engenheiros mobile trabalhavam muito próximos uns dos outros – o que significa que era fácil dividir informações e puxar discussões sobre como resolver problemas. Além disso, ter um único time especializado em desenvolvimento mobile facilitava o processo de manter a consistência do código em todos os produtos. Por outro lado, conforme a empresa e os squads cresciam, se tornou cada vez mais difícil continuar trabalhando como um time de serviços.
Desafios de ter engenheiros mobile como um time de serviço
- Alocação: as decisões envolvendo quem iria trabalhar no que começaram a ficar cada vez mais complexas. Também se tornou difícil conciliar as necessidades das plataformas (lançamentos de iPhone, novas versões de Android, crashes a serem corrigidos, etc), as decisões de produto (esse será um lançamento específico para uma plataforma? Precisamos lançar isso simultaneamente nas duas plataformas) e outras variáveis. O número de desenvolvedores alocados por projeto dependia da resposta para essas e muitas outras perguntas – como disponibilidade de pessoas (férias, feriados) ou necessidades de trabalho em ferramentas de produtividade ou automação de pipelines de entrega.
- Responsabilidade pelo código: quem desenvolvesse alguma funcionalidade/biblioteca era responsável por aquele código mesmo depois de migrar para um projeto em um novo squad. Isso gerava duas questões: estavámos especializando ainda mais nossos desenvolvedores e concentrando conhecimento de bibliotecas compartilhadas em algumas poucas pessoas. Além disso, os desenvolvedores precisavam olhar de novo para projetos há muito concluídos – o que exigia muitas mudanças de contexto.
- Senso de pertencimento: há unidade dentro de um squad. Seus membros compartilham uma visão de futuro para o produto. Essa união motiva as pessoas e torna mais fácil focar em um objetivo. Desenvolvedores mobile, por outro lado, iam e vinham e não participavam das discussões e debates a longo prazo. Com isso, era mais difícil para eles se conectar com os objetivos e saber como seu trabalho afetou o desempenho geral do squad.
- Necessidades da plataforma: atividades que não pertencem a nenhum squad específico, mas que são próprias das plataformas Android e iOS, eram mais difíceis de priorizar. Além disso, focar nelas significava, obrigatoriamente, tirar o foco de desenvolvimento de produto. Alguns exemplos dessas atividades incluem: upgrades de plugin, lançamentos para as lojas de apps, updates de SDK, etc. Sem tempo para aprimorar essas ferramentas, a produtividade dos desenvolvedores (e a sua qualidade de vida) era afetada.
- Retrabalho: desenvolvedores se juntavam a squads em estágios diferentes do ciclo de desenvolvimento de produto. Isso forçava revisitar temas já “decididos”. Por exemplo, quando o desenvolvedor mobile chegava, era preciso muitas vezes refatorar APIs, revisar ou até mesmo refazer animações muito pesadas que não funcionariam bem nos aparelhos dos clientes. Esses empecilhos geralmente refletiam nas datas de lançamento.
Nossa abordagem do problema
Sabíamos que o único jeito de mudar a situação era ter desenvolvedores mobile como parte dos squads, trabalhando em produtos e não em projetos. Essa nova estrutura de time requer um número maior de desenvolvedores – o que significava que precisávamos contratar a um ritmo muito mais rápido. E foi justamente isso que nós fizemos. Conforme os novos desenvolvedores eram contratados, eles se juntavam aos squads seguindo a lista de prioridades. Também trabalhamos para melhorar a produtividade e a qualidade de vida dos desenvolvedores. Um dos pontos importantes foi criar um time chamado Mobile Platform, focado inicialmente em melhorar as pipelines e as ferramentas compartilhadas. Esse time começou a focar no processo de entrega do código e lançamento do aplicativo nas lojas.
Com o squad de Mobile Platform responsável pelos lançamentos do app, foi mais fácil criar um cronograma com os releases saindo de forma independente dos ciclos de desenvolvimento de cada squad de produto.
Outro benefício de melhorar nossas ferramentas e se juntar aos times de produto é a agilidade. Com mais contexto, os desenvolvedores podem tomar decisões melhores e com resultados mais previsíveis.
No novo modelo, as decisões sobre priorização ficam em cada squad e são menos centralizadas. Às vezes, ainda há a necessidade de reunir diferentes squads – como em grandes mudanças de layout. Ainda assim, essas situações são mais simples de resolver porque cada time cuida de suas próprias prioridades e sabe o peso das suas decisões nos objetivos gerais da empresa.
Vale mencionar que ainda estamos nos adaptando ao novo sistema – e ele também tem seus desafios. Ainda assim, já é possível ver melhorias em vários times.
