Como funcionam os Squads no Nubank
Edit: Eu não trabalho mais na empresa. Por isso, pedidos para benchmarks e perguntas mais específicas devem ser encaminhados para marketing@nubank.com.br.
Obrigada. =)
— — —
O Nubank é a maior startup da América Latina e teve um crescimento impressionante desde a sua fundação em 2012, chegando a ter 5 milhões de clientes em 2018. Para garantir uma escalabilidade saudável e sustentável desse crescimento, houve um planejamento muito bom da arquitetura do backend, associado a uma forte cultura de pessoas e processos.
Há diversas metodologias de desenvolvimento ágil de software pelo mundo (eu não conheço a Crystal, por exemplo), que se preocupam em como priorizar e entregar as tarefas ou especificar qual deve ser o tempo da iteração, quais cerimônias para deixar a comunicação clara ou os papéis existem entre o cliente e o desenvolvimento (product owner, scrum master, team, etc).
Em 2012 Henrik Kniberg & Anders Ivarsson, na época eram agile coaches na Spotify, publicaram o artigo Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds e em 2014 dois vídeos (Parte 1 e Parte 2) foram divulgados explicando como a empresa estava organizando, estruturalmente, o time. Se você ainda não viu, vou explicar de forma sucinta: basicamente, ela dividiu a equipe em pequenos grupos multifuncionais, que são responsáveis por uma única parte do sistema. Esses pequenos grupos foram chamados de squads.
Por exemplo, se tivermos um squad responsável pela entidade 'Cliente' de um sistema, a equipe fica com todo o ciclo de desenvolvimento desta parte. Por conta disso, cada grupo é composto de pelo menos uma pessoa que consiga desempenhar o papel necessário para desenvolver essa parte do produto. No exemplo anterior, o squad de 'Cliente' deve fazer a parte frontend e backend do sistema, além de garantir a qualidade e fazer o deploy para produção, incluindo o monitoramento e tratamento de erros. Se houver um app mobile, a equipe deverá lembrar dessa parte também. Dessa forma, esse squad tem pessoas de diferentes chapters, ou funções — pessoas da engenharia de backend, frontend e mobile. Se a empresa trabalhar com uma equipe de qualidade separada do desenvolvimento, o squad deve ter uma pessoa desse time também.
O grupo também tem autonomia para decidir o que e como as alterações serão feitas, qual metodologia de gerenciamento irá utilizar (scrum, kanban, etc) e o que mais precisar para desempenhar bem o seu papel. No exemplo acima, o squad pode decidir não fazer a parte mobile, se não houver necessidade naquele momento.
Não irei detalhar todos os aspectos, mas deixo aqui esta figura que está no artigo de Henrik Kniberg & Anders Ivarsson e mostra a estrutura das pessoas em um modelo de squads. É um material bem completo e detalhado que vale a leitura. Os elementos principais dessa organização são os squads, os chapters, as tribes e as guilds.
A primeira vez que ouvi falar sobre esse sistema de estruturação foi nos vídeos do Spotify que comentei no inicio do artigo. Depois disso, soube de vários cases de empresas que estavam implantando e comentando sobre as dificuldades que passaram e ganhos que tiveram.
O Nubank, onde eu trabalho 💜, usa este modelo de organização de times de forma bem madura. O modelo de microserviços usado no backend desde o início da empresa e a cultura de desenvolvimento, com muita autonomia e confiança, ajudou a fazer com que fosse bem fácil de usar a esta forma de organização. Apesar de a empresa ter se adaptado bem, ainda temos algumas situações a serem corrigidas, que vou comentar ao longo do artigo. Resumindo: esse método é super bom, mas pode ser difícil para muitas empresas, então não é mais uma bala de prata e nós não devemos tratá-lo como tal.
Vou tentar descrever aqui a minha experiência sobre squads no Nubank, como estruturamos os times, o que tem de bom e de ruim e como resolvemos as complicações que o dia a dia nos traz sob o ponto de vista da engenharia, que é o chapter em que estou alocada e participo das atividades.
Estrutura dos times no Nubank
Temos vários chapters: Engineer, Business Analyst (BA), Design, Data Science, Communicators e Brands Managers, Xpeer (atendimento ao público), Product Manager, etc. Alguns squads cresceram tanto que precisaram ser agrupados em Tribes, como é o caso de Acquisition e Nuconta, por exemplo.
Cada squad tem pessoas dos chapters de que necessita. Em CSD (Customer Support Design), temos Engineers, BAs, Xpeers e Data scientists (DS). Nenhuma pessoa de brand manager ou designer. Da mesma forma, em Credit Strategy, a equipe responsável por melhorar os modelos de aprovação de crédito, tem pessoas de DS, engenharia e nenhum brand manager. Já em Acquisition, a tribe que cuida de tudo relacionado a aquisição de novos clientes, tem pessoas de quase todos os chapters: engenharia, BA, Brand Manager, DS, Designer, Xpeer, PM, etc.
Os squads também podem "pegar emprestado" alguma figura de outro caso surja uma demanda específica ou, caso a necessidade fique mais frequente, estuda-se a possibilidade de colocar uma pessoa dedicada. Por exemplo, é comum os designers trabalharem em tarefas que envolvam mais de um grupo.
Também é comum a criação de Guilds para tratar de assuntos horizontais entre os squads. Desta forma, no Nubank, temos a guilda de onboarding, hiring, UI, react-native, e muitas outras para cuidar de assuntos que não são de um squad específico, mas sim de interesse de todos. As guilds servem pra apoiar novas tecnologias ou resolver problemas comuns a todos os squads. Então se alguém está com dificuldades com StyledComponents ou começou a estudar Flutter e quer saber quem mais tem interesse, podem contar com a guilda específica ou criar uma nova.
Como definimos/priorizamos as tarefas
As demandas são definidas e priorizadas de acordo com os OKRs do squad, que são determinados de acordo com os OKRs da empresa, e com os ganhos/gastos previstos por modelos que as pessoas que trabalham como BA analisam. Se uma determinada tarefa tem potencial de fazer com que o squad atinja algum ou alguns OKR(s), então ela é detalhada, discutida com todos os chapters que serão envolvidos, antes de ser feita.
Em geral, o prazo não é o componente mais crucial de um OKR, - dado que não passamos por cima da qualidade para cumprir um prazo. No entanto, como um dos valores da empresa é “We think and act like owners, not renters” (“nós pensamos e agimos como donos, não como inquilinos"), a grande maioria das pessoas quer shipar - colocar coisas em produção. A idéia de entrega contínua é forte e existem ferramentas internas feitas para garantir que tudo que seja produzido, vá para experimentação do público - que as vezes são os próprios Nubankers 🙃- o mais rápido possível, com a maior qualidade e de forma mais eficiente. Quando algo está muito repetitivo e tomando muito tempo do time, automatizamos. Expressões como "Feedback rápido" e "vamos aprender e não ter medo de errar" são comumente ouvidas nos corredores.
Nem tudo que brilha é ouro
Como eu disse antes, squads não são a resposta para a vida, o universo e tudo mais. As vezes, pela natureza dessa estrutura, descobrirmos que dois grupos estão trabalhando em algo que poderia ser reutilizável. Como a comunicação tende a ser mais eficiente neste modelo, no entanto, é comum as equipes descobrirem rápido e passarem a trabalhar em conjunto. Além de divulgarem para outros squads para que quem quiser usar e/ou contribuir possa se juntar ao grupo. Já aconteceu também de surgir um problema e não ficar claro quem é responsável por aquela parte, ou o squad que implementou aquela parte nos primórdios do sistema não existir mais.
No Nubank, as coisas acontecem realmente rápido. Novos squads surgem, outros acabam, alguns se dividem em dois ¯\_(ツ)_/¯. Nesse caso, mais uma vez, graças à comunicação rápida e aos valores da empresa, todo mundo se junta e resolve o problema sem apontar dedos ou culpar um grupo em específico. Inclusive, acontece com frequência de um squad oferecer ajuda a outro quando um problema acontece 💜.
Tecnologia + pessoas = 💜
No Nubank, usamos tudo que a metodologia nos oferece, da maneira mais eficiente que conseguimos. As vezes surgem alguns contratempos, mas com a estrutura de squads e pessoas com os valores da empresa incorporados fazem tudo dar certo.
Tentei explicar como organizamos o time em squads, chapters, tribes e guilds, os desafios e tudo o mais, mas posso ter deixado de comentar algo interessante, então se ainda ficar alguma dúvida, podem perguntar nos comentários. 😃
Obrigada. =)
