Complete abaixo para pedir sua NuConta e seu cartão de crédito

Precisamos seu nome completo. Precisamos seu nome completo.
Precisamos do seu CPF Precisamos de um CPF válido
Precisamos do seu e-mail. Aqui precisamos de um email válido.
Ops. Está diferente do campo acima.
Para prosseguir, você deve concordar com as políticas de privacidade.

Início O Nubank Expandindo o time de des...

Expandindo o time de desenvolvimento Mobile do Nubank

Os desafios de crescer para dar mais autonomia a outros times de produto.

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.

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

  1. 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.
  2.  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.
  3. 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.
  4. 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.
  5.  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.

(Os efeitos colaterais de se trabalhar como um time de serviços estão bem documentos. Uma boa fonte é o livro “Agile IT Organization Design”, de Sriram Narayan).

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.

O time de desenvolvimento mobile do Nubank

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.

Desafios do novo modelo

(Trabalhar em times de produto traz alguns desafios, mas é importante ressaltar que ainda estamos em um processo de adaptação de fluxo de trabalho).

Trabalhamos com revisão de códigos via Pull Requests – e eles se tornaram mais difíceis de alinhar dado que uma PR pode não representar toda a discussão por trás das mudanças e das escolhas feitas pelos desenvolvedores. Isso é especialmente verdade quando o revisor está em outro squad e não tem todo o contexto daquela PR específica. As revisões podem levantar questões já consideradas e levar a discussões pouco produtivas – mas tentamos levar esse ponto como uma forma de melhorar as nossas PRs, comunicação e processo de revisão.

Outra questão é a sub-utilização dos desenvolvedores mobile – um tópico também abordado por Sriram Narayan em seu livro “Agile IT Organization Design”. Em resumo, a conclusão é a de que é preciso abrir mão desse ponto para conseguir responder com rapidez à demandas imprevistas.

(Deixo aqui um trecho, em inglês, do autor: “Will specialists dedicated to product teams be underutilized? Probably yes. This is where the rubber meets the road in terms of trading off cost-efficiency for the sake of responsiveness. Beyond a certain threshold of utilization, responsiveness decreases as utilization increases. This is a well-known effect from queuing theory. Without some slack, we can’t have responsiveness. A fully utilized highway is a parking lot.” (p.60)

Vale notar aí que a “sub-utilização” dos desenvolvedores em cada squad é o que permite que eles tenham reuniões para compartilhar arquitetura de código entre produtos, falar sobre a nossa fila de produção e discutir desenvolvimento de funcionalidades e contratações que ajudem a minimizar as dificuldades descritas acima.

Esse tempo é importante para que todos tenham uma visão global do que está acontecendo na empresa e também um senso de unidade. No fim do dia, nosso trabalho é um só.

Nossa atual estrutura deu aos times autonomia para agir conforme suas prioridades – e os desenvolvedores conseguiram sentir que pertencem a algo maior e contribuem muito mais em seus novos squads. Ter um calendário de lançamentos facilita  o planejamento das funcionalidades e faz com que nossos clientes recebam um app de maior qualidade no fim.

Se os desafios dos nossos times soam como algo que você gostaria de tentar enfrentar, saiba que nós estamos sempre contratando.

A sua empresa está passando por uma fase de crescimento acelerado? Quais os desafios enfrentados? E como você e sua empresa estão lidando com isso?

Digite seu nome

Quero receber a newsletter
  • Henrique Gritti
    31 de agosto de 2019, 19h24
    Bom dia, Eu minha esposa temos conta na nubank, mas hj nos deparamos com problema no app que seria muito se melhorado.O app só permite abrir uma única conta por celular enquanto os demais bancos vc entra no app e utiliza os dados e a as senhas de cada um e pode entrar tanto na minha como a de outra pessoa.E como só um de nós cuidamos do controle de gasto de casa seria legal poder abrir as duas conta no mesmo app assim como nos outros bancos. É uma ideia para melhorar... Obrigado
    • Fala Nubank
      01 de outubro de 2019, 18h41
      Obrigado pela sugestão, Henrique! Vamos levar para o nosso time de produtos! :)