BT

Disseminando conhecimento e inovação em desenvolvimento de software corporativo.

Contribuir

Tópicos

Escolha a região

Início Artigos MOOtopia - Adaptando o modelo Spotify no MOO

MOOtopia - Adaptando o modelo Spotify no MOO

Pontos Principais

  • O objetivo não é ser ágil - é ser sensível às mudanças para apoiar os objetivos organizacionais;
  • Não se pode emular a cultura de alguém copiando o design organizacional;
  • O modelo Spotify pode ser um bom ponto de partida, mas é necessário adaptá-lo para atender às necessidades;
  • O modelo Spotify pressupõe que existe uma arquitetura moderna baseada em microservices para que existam equipes autônomas. Se não existir isso, talvez não funcione;
  • Antecipe a adaptação e planeje uma abordagem emergente para mudança.

Entrei na MOO em abril de 2018, quando estava acontecendo o processo de adaptação na estrutura organizacional das áreas de tecnologia e produtos com base no modelo Spotify. No ano passado, começamos a evoluir esse design inicial para algo que nos atendesse.

A MOO é uma empresa de impressão e design, lançada em 2006. A Moo é apaixonada por design e pela diferença que pode fazer para o mundo. Ajudamos a disponibilizar um excelente design para todos, em qualquer lugar, com foco em ajudar os clientes a criar, compartilhar ou promover sua identidade profissional. A tecnologia sustenta tudo o que fazemos. E isso é vital para apoiar efetivamente as aspirações de negócios.

Por que a MOO decidiu implementar o modelo Spotify?

Em 2015, a MOO tinha planos de começar a crescer e se expandir, inclusive a equipe de tecnologia. Com uma equipe de 50 pessoas na área de tecnologia e produtos, precisávamos encontrar uma maneira de nos estruturarmos melhor, para garantir que poderíamos nos adaptar às necessidades em constante mudança da empresa. Já estávamos usando práticas enxutas e ágeis e queríamos trabalhar dessa maneira para que pudéssemos continuar flexíveis e mudar rapidamente.

A equipe e empresa descreveram os seguintes problemas quando perguntados:

  • "Não estamos bem";
  • "Lançamentos de versões são realmente dolorosos";
  • "Adicionar novos produtos físicos é difícil";
  • "Trabalhar entre equipes é difícil";
  • "Realmente não estamos sendo ágeis";
  • "A migração de monolito para microservices nem sempre está recebendo a devida atenção";
  • "Estamos preocupados com infraestrutura, rede e segurança".

A abordagem do modelo Spotify foi introduzida na época por nosso CTO, que tinha em primeira mão a experiência do modelo, e conhecia coaches agile que trabalharam no Spotify. Na época, era considerado o "novo normal" e a abordagem aspiracional visava e parecia se alinhar bem com nossa cultura, valores e princípios. Queríamos equipes de produtos multidisciplinares capazes de:

  • serem razoavelmente autônomas;
  • façam entregas frequentemente e com segurança;
  • pesquisem E "aprendam com a vida";
  • apropriem-se de seus produtos em produção;
  • continuem inspecionando e melhorando a forma de trabalhar;
  • construam produtos que possam escalar rapidamente;
  • construam serviços e ferramentas que nos permitam passar a ideia para o MVP em dias/semanas ao invés de meses.

Então, parecia uma boa jogada!

O objetivo e os resultados que visamos

O objetivo era garantir que as equipes de tecnologia e produtos pudessem trabalhar com a empresa, em geral para atender aos objetivos estratégicos da MOO, introduzindo novos recursos e serviços para lançar novos produtos. A tecnologia sustenta tudo o que fazemos na MOO, desde a experiência do comércio eletrônico até a impressão e o atendimento de pedidos. Ser capaz de adaptar rapidamente a nossa tecnologia para atender às necessidades do negócio é vital para o sucesso da MOO. Agilidade não era o objetivo.

Como implementamos o modelo Spotify

Começamos nos organizando nos modelos Tribes, Squads, Chapters e Guilds, conforme descrito pelo Spotify, para inspirar nosso desenho organizacional e formas de trabalhar dentro das áreas de tecnologia e produtos.

Nos organizamos em quatro tribes distintas, que possuíam um conjunto integrado de produtos e serviços. Cada tribe tem entre duas a quatro equipes multidisciplinares (optamos por não mudar o nome de nossas equipes para squad!), que eram estáveis e organizadas em torno da propriedade de produtos e serviços integrados, incluindo um coach Agile, gerente de produtos e designer experimente. Os líderes do chapter fornecem gerenciamento alinhado a cada disciplina com várias associações criadas em torno de tópicos com os quais as equipes e os indivíduos se identificam.

Por último, mas não menos importante, introduzimos o coaching ágil como um papel e um plano de carreira. O chapter de coaching ágil está lá para apoiar e permitir que a MOO sustente equipes saudáveis e felizes e que continuem a fornecer excelentes e valiosos resultados. Agora temos um próspero chapter em casa, com coaches ágeis internos e permanentes. O melhor sobre o chapter é que agora estamos começando a ampliar mais do que nunca a equipe de tecnologia e produto e consideramos a agilidade corporativa em toda a empresa.

Time certo

Queríamos que cada equipe fosse multidisciplinar e que tivessem habilidades necessárias para serem autônomas e funcionar de forma independente. Além de introduzir o conceito de equipes estáveis, isso significou introduzir novos papéis de carreiras, bem como reforçar algumas de nossas funções existentes.

  • Apresentando o dono do produto técnico como um papel e plano de carreira. Algumas de nossas equipes oferecem principalmente serviços muito técnicos internamente e sentimos que precisávamos de alguém com experiência técnica para gerenciar os produtos locais;
  • Equipando os engenheiros e fazendo com que a automação de testes seja algo concreto em nossas equipes;
  • Engenharia Operacional - estabelecendo uma equipe de plataforma. Não é exatamente o DevOps ou o SRE, mas uma variante muito mais moderna de um Admin do Sistema para cuidar de todas as nossas infraestruturas e um primeiro passo para remover o muro entre engenheiros e o ambiente de produção;
  • Equipe de pesquisa e design de experiência do usuário.

De Squads para Quads

Uma de nossas próprias idéias sobre o modelo Spotify foi a introdução do conceito de quads que é composta pelo gerente de produto, coach agile, líder em tecnologia e o designer experiente. Cada tribe (e equipe) teria uma quad que concordasse de forma colaborativa com o que é possível para uma equipe ou tribe, e o melhor curso de ação baseado no conhecimento atual de cada disciplina.

O papel da Quad foi idealizado para garantir uma tensão saudável em cada equipe para garantir que cada perspectiva e disciplina fossem iguais. Não adianta fazer algo tecnicamente incrível se não houver valor para o cliente, ou o contrário, constantemente hackeando e construindo débito técnico para perseguir a receita!

A ideia era que as responsabilidades fossem discutidas e alinhadas com base no contexto atual, com cada papel trazendo uma perspectiva única. Também pode alterar ou adicionar funções específicas, dependendo do contexto. Cada disciplina tem certos "fatores de atração" que atraem certos tipos de trabalho e responsabilidades, criando uma abordagem alternativa para um RACI tradicional.

Como evoluímos o modelo Spotify na MOO ao longo do tempo

A primeira iteração foi implementada há dois anos. Agora estamos no estágio de atualização, e aprendemos o que funciona bem e o que não funciona.

Definitivamente existem alguns aspectos que são ótimos. Estamos bem organizados em torno de produtos, em vez de projetos e equipes temporárias. Temos mais propriedade nos serviços ponta a ponta e estabilidade em equipes que não mudam com tanta frequência.

A tecnologia e produto cresceram significativamente em 2016 e 2017, e foram organizados como equipes de produtos e as tribes nos ajudaram com domínio de ponta a ponta. À medida que novas pessoas se juntavam, existia um sentimento de pertencimento, o que ajuda as pessoas a se acomodarem melhor.

Havia elementos que não funcionavam tão bem. O modelo Spotify é deles e funciona bem para eles. Não é uma receita mágica para qualquer um seguir.

Nos últimos seis meses, fizemos uma série de pequenos ajustes e implementamos melhorias - evolução, não revolução. Não queremos e nem precisamos do agile para essa transformação. No entanto, isso não significa que não há espaço para melhorias! Fizemos alterações e melhoramos:

  • Tribe e liderança de equipe
  • Para garantir maior tomada de decisão local, colocamos mais ênfase nos diretores de produto e engenharia como tomadores finais de decisão;
  • Quads - Em equipes menores, uma quad não é viável. Em uma equipe estereotipada de 7-9 pessoas, metade das pessoas estava na Quad, criando uma divisão e hierarquia artificial. Considerando todas as quatro perspectivas, ainda é muito importante para nós - não podemos chamar esse conceito de quad.
  • Função do gerente de engenharia
  • Evoluiu a descrição de seu cargo para garantir que fossem considerados parte da equipe, e não apenas focar na gestão individual de pessoas e usar sua experiência para apoiar e aconselhar a equipe.
  • Função do coach agile
  • Tornar mais claros os aspectos de coaching e entrega do papel e como são complementares para os gerentes de engenharia e gerentes de produto dentro de suas equipes e onde os coaches podem agregar valor.
  • Planos da Carreira
  • Evoluindo todas os postos de trabalho para garantir que elas tenham uma progressão clara na carreira e se alinhem com o modelo MOO Core Capabilities.

O modelo Spotify tem sido um ótimo ponto de partida para a MOO, mas agora precisamos adaptar nosso design organizacional às nossas próprias necessidades e cultura.

O que aprendemos com nossa jornada agile

Apesar da semelhança, a cultura organizacional da MOO não era uma réplica exata do Spotify, o que significava que em algumas das formas de trabalho usadas pelo Spotify não serviam para a Moo.

O conceito de quad, de que tanto nos orgulhamos, acabou se tornando um pouco hierárquico. Muitos membros da quad queriam responsabilidades difíceis, então entendemos o que fazer. O conceito de responsabilidade compartilhada era estranho. Isso significava muitas tomadas de decisões por comitê ou pedir permissão ou aprovações centralizadas para cada pequeno detalhe.

Outro aprendizado principal está relacionado aos capacitadores técnicos para tornar o modelo Spotify viável.

Há muitos treinamentos e estudos de caso sobre como transformar essa o modelo waterfall em agile. A maioria recomenda o uso de estruturas de dimensionamento ou projetos organizacionais semelhantes ao modelo Spotify, organizando equipes em torno de fluxos de valor de ponta a ponta. O modelo Spotify assume uma arquitetura moderna e desacoplada com microservices que os squads cuidam de ponta a ponta - como o Spotify faz! E isto é um instrumento fundamental.

Na realidade, muitas empresas têm software legado, monólitos e débito técnico que criam dependências significativas entre as equipes, o que torna esse tipo de projeto organizacional impossível na prática. Até que sejam afaste as dependências, é extremamente difícil para as equipes serem verdadeiramente autônomas. A Lei de Conway provou ser verdade e construímos sistemas que representavam nossa estrutura organizacional na época.

A MOO é uma empresa de 12 anos que cresceu rapidamente. Isso significa que o stack de tecnologia evoluiu rapidamente com a MOO. Não temos a arquitetura ideal (ainda!), e temos aplicações monolíticas para lidar. Isso dificulta a organização das tribes e squads que possuem serviços de ponta a ponta, pois ainda existem muitas dependências como desmembrar nosso monolito e construir novos serviços em paralelo - tudo isso enquanto continuamos a crescer como um negócio!

Próximos passos

A MOO está no processo de mudanças que podemos descrever como incremental. Temos uma grande equipe de coaches ágeis experientes e líderes em tecnologia que estão confortáveis para escolher os conceitos e métodos certos em suas caixas de ferramentas ágeis e enxutas para ajudar a evolução da MOO. Não vamos aderir religiosamente o modelo do Spotify. O que fazemos aqui na MOO não é um cortador de biscoitos e nos desafiamos e nos empolgamos com o processo de tentar encontrar as respostas que funcionam para nós. Embora continuemos a nos inspirar nas tendências do setor.

No momento, estamos avaliando nossa estratégia de tecnologia e observando como nossa arquitetura atual e nosso legado de software estão nos restringindo, e ao mesmo tempo avaliando diferentes maneiras de progredir. Isso ajudará as equipes e as dependências entre as tribes e reduzirá significativamente o esforço de várias equipes para lançar novos produtos.

Para cumprir nosso propósito, continuaremos a procurar e reter os melhores talentos, equilibrar o conjunto de habilidades e a senioridade da equipe e criar um ambiente que permita um trabalho distribuído.

O modelo Spotify não ajudará em nada disso!

Sobre a Autora

Claire Donald é engenheira e diretora da plataforma e coach agile na MOO. Tem mais de 20 anos de experiência na liderança tecnológica em setores públicos e privados.

Avalie esse artigo

Relevância
Estilo/Redação

Conteúdo educacional

BT