Cultura de Engenharia do Spotify
Um dos grandes fatores de sucesso aqui no Spotify é a nossa cultura ágil de engenharia. Cultura tende a ser invisível; nós não a notamos porque está sempre ali, um pouco como o ar que respiramos. Porém, se todos entendem a cultura, é mais provável que nós consigamos mantê-la e até mesmo reforçá-la conforme crescemos. Esta, então, é a proposta deste vídeo.
Quando nosso primeiro player de música foi lançado em 2008, nós éramos basicamente uma empresa Scrum. Scrum é uma metodologia de desenvolvimento ágil bem estabelecida e nos deu uma boa cultura baseada em times. Entretanto, alguns anos depois, nós havíamos crescido para um punhado de times e percebemos que algumas das práticas padrão do Scrum estavam, na verdade, nos atrapalhando.
Decidimos tornar tudo isso opcional. Regras são um ponto de partida, mas devem ser quebradas quando necessário. Nós decidimos que Agilidade importa mais que Scrum e que Princípios Ágeis importam mais que quaisquer práticas específicas. Por isso, nós renomeamos a função Scrum Master para Treinador Ágil, porque nós queríamos Líderes-Servos mais do que Mestres de Processos. Nós também começamos a utilizar o termo Equipe Autônoma ao invés de Time Scrum, e a nossa principal força motriz se tornou Autonomia.
O que é uma Equipe Autônoma?
Uma equipe é um pequeno time auto-organizado, multifuncional, usualmente com menos de 8 pessoas. Eles se sentam juntos e possuem responsabilidades de ponta a ponta para as coisas que desenvolvem: design, entrega, manutenção, operação – a coisa toda. Cada equipe possui uma missão de longo prazo, como fazer do Spotify o melhor lugar para se descobrir música, ou cuidar de questões internas, como infraestrutura de testes A/B.
Autonomia basicamente significa que a equipe decide o que fazer, como fazer e como trabalhar juntos enquanto realizam suas atividades. Existem, é claro, alguns limites para isso, como a missão da equipe, a estratégia global da área em que a equipe está trabalhando e os objetivos de curto prazo que são renegociados a cada bimestre.
Nosso escritório é otimizado para colaboração. Uma área típica de uma equipe é assim: os membros da equipe trabalham próximos, com mesas ajustáveis e fácil acesso aos monitores uns dos outros. Eles se reúnem no lounge para coisas como sessões de planejamento e retrospectivas, e há uma pequena sala mais aconchegante ao fundo para reuniões menores ou momentos de silêncio. Quase todas as nossas paredes são quadros brancos.
Por que a Autonomia é tão importante?
Bem, porque autonomia é motivante, e pessoas motivadas produzem melhor. Além disso, a autonomia nos torna rápidos, pois permite que decisões sejam tomadas localmente na equipe, em vez de depender de vários gerentes e comitês. Isso ajuda a minimizar delegações e espera, de forma que podemos crescer sem ficar atolados com dependências e coordenação.
Embora cada equipe tenha sua própria missão, todas precisam estar alinhadas com a estratégia do produto, com as prioridades da empresa e com as outras equipes. Basicamente, ser um bom cidadão no ecossistema Spotify. A missão geral do Spotify é mais importante do que qualquer equipe individual, então o princípio chave é: “Seja autônomo, mas não subotimize”.
É como uma banda de jazz: embora cada músico seja autônomo e toque seu próprio instrumento, eles escutam uns aos outros e se focam na música como um todo. É assim que grandes músicas são criadas. Nosso objetivo é ter equipes pouco acopladas, mas fortemente alinhadas. Não estamos exatamente lá ainda, mas estamos sempre experimentando novas maneiras de chegar mais perto.
De fato, isso se aplica à maior parte deste vídeo: essa descrição de cultura é, na prática, uma mistura de como somos hoje e de como queremos nos tornar no futuro.
Alinhamento e Autonomia
Alinhamento e autonomia podem parecer como extremos opostos de uma mesma escala, no sentido de que “mais autonomia leva a menos alinhamento”. Porém, nós consideramos que são mais como duas dimensões diferentes. Aqui temos quatro cenários:
Baixo alinhamento, baixa autonomia: cultura de microgestão, sem propósito de alto nível, apenas “fique quieto e obedeça”.
Alto alinhamento, baixa autonomia: os líderes são bons em comunicar que problema deve ser resolvido, mas também estão dizendo às pessoas como resolvê-lo.
Alto alinhamento e alta autonomia: significa que os líderes focam em que problema deve ser resolvido, mas deixam as equipes decidirem como resolvê-lo.
Baixo alinhamento e alta autonomia: as equipes fazem o que querem e basicamente correm cada uma em uma direção, líderes ficam perdidos e nosso produto se torna um Frankenstein.
Nós estamos tentando bastante ficar no quadrante de alto alinhamento e alta autonomia, com autonomia alinhada, e continuamos experimentando diferentes formas de fazer isso. Alinhamento habilita autonomia. Quanto mais alinhamento tivermos, mais autonomia podemos dar às equipes. Isso significa que o trabalho dos líderes é comunicar qual problema deve ser resolvido e o das equipes é colaborar umas com as outras para encontrar a melhor solução.
Padrões Flexíveis
Uma consequência da autonomia é que temos bem pouca padronização. Quando perguntam “qual editor de código vocês utilizam?” ou “como vocês fazem o planejamento?”, a resposta é geralmente “depende de qual equipe”. Algumas utilizam sprints Scrum, outras Kanban. Algumas estimam estórias e medem velocidade, outras não. Tudo é critério de cada equipe.
Ao invés de padrões formalizados, temos uma cultura forte de polinização cruzada: quando um número suficiente de equipes utiliza uma prática ou ferramenta específica, como Git, ela se torna o caminho de menor resistência, e outras equipes tendem a adotar a mesma ferramenta. As equipes começam a suportar essa ferramenta e ajudam umas às outras, até que ela se torna um padrão de fato. Essa abordagem informal nos dá um equilíbrio saudável entre consistência e flexibilidade.
Nossa arquitetura é baseada em mais de uma centena de sistemas codificados e implementados independentemente. Existe bastante interação, mas cada sistema foca em uma necessidade específica, como gerenciamento de playlists, buscas ou monitoramento. Nós tentamos mantê-los pequenos e desacoplados, com interfaces e protocolos claros.
Tecnicamente, cada sistema é propriedade de uma equipe, e na prática, a maior parte das equipes possui vários sistemas. Mas temos um modelo de “código livre interno”, e nossa cultura é mais sobre compartilhar do que possuir. Vamos supor que a Equipe 1 precise que algo seja feito no sistema B, que é de responsabilidade da Equipe 2. Tipicamente, a Equipe 1 pediria para a Equipe 2 fazer a implementação, entretanto, se a Equipe 2 não tem tempo ou tem outras prioridades, a Equipe 1 não precisa necessariamente esperar – nós odiamos esperar! Eles podem modificar o código eles mesmos e depois pedir que a Equipe 2 revise as alterações.
Qualquer um pode editar qualquer código, mas temos uma cultura de revisão de código por pares. Isso melhora a nossa qualidade e, mais importante, distribui o conhecimento. Ao longo do tempo, nós evoluímos guias de design, padrões de código e outras coisas para reduzir a fricção de engenharia, mas somente quando necessário. Então, numa escala de autoritário até liberal, nós definitivamente estamos mais para o lado liberal.
Pessoas e Cultura de Respeito
Nada disso funcionaria se não fossem pelas pessoas. Temos uma cultura muito forte de respeito mútuo. Com frequência, escuto comentários como: “Meus colegas são demais!” As pessoas geralmente creditam uns aos outros por ótimos trabalhos e raramente tomam crédito para si próprias. Considerando quantos talentos temos aqui, temos surpreendentemente poucos egos.
Uma realização comum de novos contratados é que a autonomia pode ser um pouco assustadora no início. Você e seus colegas de equipe precisam encontrar suas próprias soluções; ninguém vai dizer a vocês o que fazer. Mas, se pedir ajuda, você vai receber bastante e rapidamente. Há um respeito genuíno pelo fato de que estamos todos juntos nesse barco e precisamos nos ajudar mutuamente.
Eu traduzi esse material e transformei texto em áudio com a ajuda de ferramentas da inteligência artificial, se você quiser saber mais sobre esse assunto fascinante, entre em contato conosco. Gastei algumas horas com esse trabalho, um dia inteiro para te ser bem sincero, então se você quiser usar no seu treinamento, pode usar sem problemas, só não esquece de citar que eu colaborei com você. E se isso foi útil para você, se inscreve no canal do YouTube (@ClaudioCamargo), assim você ajuda a fortalecer o nosso trabalho.
Deixe um comentário