Neste artigo você entenderá a forma que as empresas mais valiosas do mundo estão organizando e gerenciando suas equipes promovendo uma cultura “super” ágil, a fim de manter a máxima agilidade possível na solução de problemas, mesmo depois de atingir larga escala e tornar-se gigante no mundo dos negócios. A luta contínua das empresas em manter uma cultura ágil exige muito esforço, principalmente quando se necessita escalar estas práticas para novas equipes da organização.
Manter a cultura de startup, depois de ser agressivamente alavancado é um dos maiores desafios no mundo dos negócios exponenciais. O Nubank é uma das maiores startups da América Latina que 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 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 recomendo dar uma lida no meu artigo aqui no DEV que menciono sobre , 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.
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 é umas dessas empresas que 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.
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 é definido/priorizado 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.
Fontes onde pesquisei esse conteúdo:
Top comments (0)