Arquitetando o Produto: Organizando os Times (c/ Team Topologies)
No artigo anterior, escrevi como utilizar técnicas de DDD para separar um produto digital, dividindo-o em partes que podem ser desenvolvidas de forma independente e integrada. Neste artigo, eu vou falar sobre como podemos aplicar esse conceito associando algumas técnicas de organização de times. O objetivo é demonstrar como uma boa arquitetura do produto pode acelerar o processo de desenvolvimento e a entrega sem perder a consistência do resultado.
O sucesso da entrega de software em qualquer organização não é apenas uma função das habilidades individuais ou das tecnologias utilizadas; a arquitetura do produto, a estrutura organizacional e as interações entre as equipes desempenham um papel crucial.
Portanto, precisamos considerar que os sistemas não consistem apenas em tecnologia, mas também em pessoas, equipes e suas interações entre si. Nesse sentido, estamos geralmente lidando com sistemas sociotécnicos, onde o design organizacional e a estrutura da equipe têm impacto na arquitetura técnica. E ao falar sobre design organizacional e seu impacto, temos que trazer a importância da Lei de Conway.
Lei de Conway
A Lei de Conway afirma que o design organizacional e sua estrutura de comunicação têm um enorme impacto no design do sistema. E quando estamos projetando o sistema, também precisamos focar na estrutura da equipe, nas dependências de comunicação e coordenação, e no fluxo geral de trabalho. E definitivamente em grandes produtos, precisamos otimizar para um fluxo rápido e paralelizável, identificando gargalos em nosso design organizacional e eliminando-os.
Portanto, para otimizar o fluxo de desenvolvimento, precisamos evitar equipes de silos por especialidades técnicas com transferências de responsabilidades. Em vez disso, precisamos buscar equipes autônomas e multifuncionais que estão projetando, desenvolvendo, testando, implantando e operando o sistema o a parte dele, pelo qual são responsáveis. Precisamos evitar (no sentido de minimizar, diferente de eliminar) transferências de responsabilidades, para que o trabalho não seja passado para outra equipe durante a implementação de alguma funcionalidade ou entrega de uma mudança.
Não são raras as vezes que vi times organizados por camadas (UI, Backend, Dados) precisando que uma unica funcionalidade percorresse as esteiras desses times, em uma passagem de bastão absolutamente improdutiva. As próprias equipes precisam ser proprietárias do sistema ou subsistema pelo qual são responsáveis. Portanto, o ideal é que na maioria das vezes elas tenham uma responsabilidade de ponta a ponta para alcançar um fluxo rápido. Esse modelo de organização reduz de maneira significativa a carga cognitiva da equipe. Então, se a carga cognitiva da equipe for amplamente excedida, isso se torna um gargalo na entrega, levando, por exemplo, a atrasos e problemas de qualidade, mas também afetando a motivação da equipe.
Outro aspecto é que geralmente você ouve que temos que aumentar nossa comunicação entre as equipes. Na verdade, não é o que você realmente deveria buscar para alcançar. Portanto, enquanto a comunicação dentro da equipe é altamente desejada, temos que restringir uma comunicação de alta largura de banda entre as equipes para possibilitar um fluxo rápido.
Diante desse cenário, não será raro percebermos uma pressão para colocarmos mais pessoas trabalhando juntas para aumentar a produtividade. Afinal de contas, com o mercado tecnológico cada vez mais aquecido e competitivo o Time to Market tem sido uma grande preocupação das empresas.
Opa, falamos em colocar mais pessoas para entregar mais rápido e logo que isso acontece aparecerá aquele técnico mais sênior para puxar a velha frase: “nove grávidas não podem dar à luz um bebê em um mês”.
A fábula das nove grávidas
Antes de mais nada, preciso avisar que o que vou escrever aqui nesse parágrafo talvez você ainda não tenha lido antes e é uma opinião impopular. Já acreditei muito, mas atualmente quando alguém vem com a fábula das “nove grávidas não podem dar à luz um bebê em um mês”, eu penso imediatamente: “Que falácia!”.
Embora seja uma ilustração útil de que nem todas as tarefas podem ser aceleradas simplesmente adicionando mais pessoas, no entanto, é verdade que essa ideia pode ser mal interpretada ou mal aplicada de maneiras que realmente impedem a inovação ou a eficiência em projetos de software. Aqui estão algumas maneiras pelas quais isso pode acontecer:
1. Complacência e Falta de Inovação
Se a equipe ou a liderança assumirem que nada pode acelerar uma implementação, eles podem não procurar métodos mais eficientes ou inovadores para fazer o trabalho. Novas ferramentas, métodos ou estruturas organizacionais, por exemplo, às vezes podem acelerar certos aspectos do desenvolvimento.
2. Desconsideração de Tarefas Paralelizáveis
Embora algumas tarefas não possam ser divididas, muitas podem. Ignorar a possibilidade de paralelização pode levar a atrasos desnecessários. Por exemplo, diferentes componentes de um sistema de software podem muitas vezes ser desenvolvidos em paralelo.
3. Desculpa para Falta de Planejamento ou Má Gestão
A ideia de que “algumas coisas simplesmente levam tempo” pode ser usada para justificar a falta de planejamento ou a gestão inadequada de uma iniciativa. Isso pode incluir falhas em considerar dependências de tarefa, não alocar pessoas adequadamente ou não definir um cronograma realista.
4. Ignorar a Escalabilidade Horizontal
Em alguns casos, especialmente em desenvolvimento moderno de software e operações de TI, a adição de mais pessoas de maneira inteligente (por exemplo, em partes diferentes do negócio que não dependam de conhecimento exclusivo) pode de fato acelerar a construção de um produto, uma prática muitas vezes referida como “escalabilidade horizontal”.
5. Fomentar uma Cultura de “Não se Pode Fazer”
Se a fábula é interpretada muito rigidamente, ela pode cultivar uma mentalidade de que os desafios são intransponíveis, o que pode levar a uma cultura organizacional onde as pessoas são menos propensas a se esforçar para encontrar soluções criativas para problemas complexos.
Em resumo, enquanto a fábula destaca um princípio válido de que nem todas as atividades são facilmente divisíveis para aceleração, ela não deve ser usada como uma desculpa para evitar a busca de eficiência e inovação que podem de fato acelerar a construção de um produto.
Bom, até aqui vimos que é preciso tomar cuidado com a organização dos times, principalmente para que a organização deles seja de ponta a ponta e não por camadas tecnológicas. Também é crucial que possamos adicionar mais pessoas para poder escalar as entregas, mas é preciso cuidado na alocação de mais pessoas nos lugares corretos. E é justamente aqui que entra a abordagem de Team Topologies descrita por Matthew Skelton e Manuel Pais em 2019 em seu livro.
Team Topologies
Matthew Skelton e Manuel Pais publicaram seu livro ‘Topologias de Equipe’ uma abordagem que defende um design organizacional que otimiza para um fluxo rápido de entregas.
O modelo apresentado em Team Topologies define quatro tipos de equipes e três modos de interação entre elas. O objetivo do modelo é incentivar interações saudáveis que permitam às equipes focadas em capacidades de negócio entregar software de valor de forma contínua.
O tipo principal de equipe é a equipe stream-aligned (alinhada ao fluxo), que é responsável pelo software de uma única capacidade de negócio.
Para entender como separar as capacidades do negócio leia o artigo anterior dessa série.
Essa equipe é completa e autônoma, abrangendo todas as etapas do ciclo de vida do software, responsável por front-end, back-end, banco de dados, análise de negócios, UX, testes, implantação e monitoramento. Elas visam produzir um fluxo constante de entregas de funcionalidades e incorporar feedbacks de lançamentos anteriores. São equipes multifuncionais compostas por uma mistura de generalistas e alguns especialistas. A construção de um grande produto terá muitas equipes desse tipo.
Para se concentrarem nas necessidades de negócio, faz-se necessária a redução da carga cognitiva, que podem existir em questões mais técnicas, comuns e repetitivas na construção de software. Uma forma de fazer isso é construir sobre uma plataforma que cuide dessas preocupações secundárias. Nesse sentido surge o outro tipo, o platform team (time de plataforma). Esses times são responsáveis por plataformas que geralmente abstraem infraestrutura, redes e capacidades transversais, e fornecem ferramentas e serviços internos para o uso dessa plataforma de produto. Isso permite, por exemplo, que a equipe alinhada ao fluxo consuma facilmente. Os times de plataforma possibilitam a autonomia das equipes alinhadas ao fluxo e reduzem sua carga cognitiva. Organizações menores podem trabalhar com uma única equipe de plataforma, que produz uma camada fina sobre um conjunto de produtos externos. Plataformas maiores, porém, requerem mais pessoas e podem ter mais times cuidando de diferentes partes da plataforma. Já escrevi sobre esse tipo de trabalho aqui nesse link.
O enabling team (equipe de habilitação) ajuda principalmente, as equipes alinhadas ao fluxo a adquirir capacidades que estão faltando. Elas fazem sugestões sobre ferramentas, práticas, frameworks, ou configuração básica para adoções de novidades. Seu objetivo também é aumentar a autonomia das equipes alinhadas ao fluxo e reduzir sua carga cognitiva.
O quarto tipo de equipe é complicated-subsystem (subsistema complicado). Essa é uma equipe opcional que apoia as equipes alinhadas ao fluxo em subsistemas particularmente complicados que requerem conhecimento especializado. Pode ser uma otimização de OCR, um Player de música, um modelo de Deep Learning, etc. Normalmente atuam em tecnologias que fogem do padrão adotado por equipes alinhadas ao fluxo. O objetivo dessa equipe também é reduzir a carga cognitiva das equipes alinhadas ao fluxo que trabalham em sistemas que usam o subsistema complicado pelo qual essa equipe é responsável.
Portanto, enquanto a equipe alinhada ao fluxo está focada na produção de um fluxo constante de entregas futuras e feedback constante de lançamentos anteriores, ela não pode fazer isso sem a ajuda das outras equipes. As outras equipes estão lá para ajudar a aumentar a autonomia e reduzir a carga cognitiva das equipes alinhadas ao fluxo. Mesmo que por vezes exista uma certa dependência é preciso entender que na maior parte do tempo essas equipes apoiam e aceleram a construção de um produto.
Maior interação e interdependência
Para organizar as equipes nesses tipos, não é suficiente apenas montar elas de modo geral. Como essas equipes interagem entre si e quando mudar e evoluir a interação da equipe é muito relevante para uma alta eficiência.
Então, por exemplo, existe um modo de interação que aborda a colaboração. Com o Collaboration mode (modo de colaboração), as equipes trabalham muito próximas umas das outras, visando o mesmo objetivo, mas preferencialmente apenas por um período limitado. A colaboração é muito adequada para descobertas, inovações rápidas ou conflitos de prioridade. Por exemplo, ao explorar novas tecnologias e/ou introduzir alguma correção urgente não planejada. Nesse cenário é fundamental que ambas as equipes adotem o conceito de Inner-Source.
O Inner-Source é uma abordagem de desenvolvimento de software que aplica os princípios do desenvolvimento de software de código aberto (open-source) dentro dos limites de uma organização. Em um projeto de Inner-Source, o código é geralmente acessível a todos dentro da organização, permitindo que qualquer funcionário contribua com melhorias ou adições ao código, independentemente da equipe ou departamento em que trabalhem. O objetivo é promover a colaboração interdepartamental, melhorar a qualidade do código e acelerar o ciclo de desenvolvimento.
X-as-a-Service (tudo como serviço) é o segundo modo de interação que se adapta muito bem quando uma equipe precisa usar uma biblioteca de código, um componente, uma API ou plataforma que pode ser fornecida eficazmente por outra equipe como um serviço. Esse modo funciona melhor onde é necessária uma entrega previsível.
Por fim, temos o terceiro modo de interação, o Facilitating (modo de facilitação). Este modo de interação entra em jogo quando uma equipe se beneficiaria da ajuda ativa de outra equipe. Este modo de interação é muito típico para equipes de habilitação.
Então, a combinação dos tipos de equipes bem definidos e os modos de interação bem definidos promovem, em geral, uma grande eficiência organizacional.
Wardley Maps, DDD e Team Topologies
Já escrevi neste artigo porque acredito que Wardley Maps pode ajudar na comunicação da estratégia do produto, depois neste artigo porque o DDD é uma ferramenta importante para auxiliar a separar o produto em partes de acordo com a estratégia e agora, nos tópicos acima, porque Team Topologies é um bom modelo para organizar os times.
Vamos agora juntar as peças. Vamos juntar as três perspectivas do mapeamento da estratégia, do design orientado ao domínio e das topologias de equipe. Conforme já mencionei nos artigos anteriores, quem observou muito bem essa relação foi Susanne Kaiser e quando vi suas explicações foi algo que fez muito sentido para mim, algo que respondia muitas dúvidas que tive ao longo da minha carreira.
Como mencionado anteriormente, precisamos considerar a Lei de Conway e as estruturas de comunicação e evitar equipes de silos funcionais com transferências de responsabilidades, o que impedirá o andamento do fluxo. Mesmo que já tenhamos identificamos nossos contextos limitados, trazendo a perspectiva do design orientado ao domínio, esses contextos se baseiam muito bem como limites de propriedade bem definidos, mas pouco adiantará se a organização de times não privilegiar essa divisão. É bem verdade que a maioria das empresas que conheço tem feito um grande esforço para estruturar suas equipes e, portanto, o exemplo da imagem abaixo pode não ser a realidade de muitas equipes.
A imagem acima é um exemplo de um sistema fictício para Gerenciamento Financeiro Pessoal. Uma ferramenta que ajuda os indivíduos a gerenciar suas finanças pessoais, desde o rastreamento de receitas e despesas até o planejamento de investimentos e aposentadoria. O modelo aplicado na imagem privilegia a passagem de responsabilidade entre os times e quando o sistema não funciona fica um empurra-empurra de um time para o outro. Não que essa situação de passagem de responsabilidade não ocorra em outros modelos estruturais, entretanto fica evidente que nesse cenário toda e qualquer implementação está propensa a isso.
Uma vez que temos esses contextos delimitados do DDD, que indicam boas divisões para fragmentar o sistema em partes menores e funcionar como limites de equipe, podemos exercitar a criação de equipes para otimizar a carga cognitiva, estabelecendo limites claros de responsabilidade, limitando o número, tamanho e também a complexidade do sistema de software com o qual uma equipe tem que trabalhar.
Para limites claros de responsabilidade, precisamos atribuir contexto delimitado a equipe e não compartilhar contextos delimitados entre as equipes, o que então difundiria a propriedade das equipes. No entanto, dependendo do tamanho do contexto, uma equipe pode possuir mais de um contexto delimitado, mas ao possuir vários contextos, temos de considerar a carga cognitiva da equipe para que não seja excessiva.
O próximo passo é identificar os serviços necessários para suportar um fluxo confiável de construção de produto. Isso nos faz focar nos componentes relacionados à infraestrutura e plataforma. Para poder focar em um fluxo contínuo de entregas, as equipes alinhadas ao fluxo estão então contando com uma equipe de plataforma que fornece uma plataforma facilmente consumível como um serviço. Precisamos considerar a dependência e a largura de banda de comunicação entre as equipes e temos de abordar as questões: existem dependências estreitamente acopladas ou bloqueadoras ou uma grande quantidade de comunicação contínua entre as equipes? Se esse for o caso, então precisamos eliminar essas dependências bloqueadoras e melhorar a integração entre as equipes (como Inner-Source citado anteriormente).
A imagem abaixo é um breve exercício de como imagino que seria uma separação de um Gerenciador Financeiro (note que fiz isso sem um especialista no domínio) aplicando Team Topologies. Também como simples exercício estruturei alguns times para simular uma construção de produtos envolvendo várias equipes.
Como falei anteriormente, percebo que muita empresa tem realizado grandes esforços na reestruturação de seus times. Não existe bala de prata que resolva todos os cenários, então a consideração da organização da imagem acima é baseada em estudos e relatos / experiências de algo que acredito. Toda mudança gera desconforto e talvez a melhor forma de introduzi-la é desenhando-a em um mapa estratégico e comunicando os ganhos desejados.
Nesse exemplo temos um time Complicated-Subsystem trabalhando em algo incerto (Genesis), com conhecimentos bem específicos e diferente da maioria. O impacto de valor esperado de acordo com a estratégia é muito grande para os resultados dessa parte do produto. Seguindo, temos dois times de Stream-Aligned trabalhando no Core Domain do produto, ou seja, na parte que desperta grande interesse dos clientes e que se bem-feita pode ser o diferencial de mercado. Na sequência podemos citar o time Platform que assume entregas e serviços e componentes que apoiam a construção do produto, geralmente sendo algo de infraestrutura ou transversais que são Commodities. Normalmente eles vão juntar várias coisas prontas e entregar com alguns facilitadores. E por fim, o time de Enabling sendo o a quinta equipe desse exemplo, facilitando a adoção e construção da base do produto.
Agora imagine que no próximo ano entre na estratégia a capacidade de ter uma conta digital nesse produto, como e onde você organizaria o negócio e os times?
É evidente que podemos identificar alguns pontos de mudança em potencial ao fazer a evolução do produto, ao hospedá-lo na nuvem ou até mesmo em uma mudança do ciclo de vida do produto. Então, sempre que necessário é possível mapear nosso design organizacional seguindo as práticas descritas nessa série de artigos e ver como as mudanças ajudariam na execução da estratégia de construção do produto.
Conclusão
Tentei trazer nesse artigo um grande enfoque para “Team Topologies” já que ele tem uma proposta de otimizar a entrega de software através da reestruturação das equipes e das relações entre elas. As organizações que aplicam essas ideias podem esperar melhorias significativas na agilidade, eficiência e qualidade da entrega de software. A estrutura não apenas ajuda a definir a forma como as equipes devem ser organizadas, mas também fornece insights sobre como as interações e relações entre diferentes tipos de equipes podem ser gerenciadas para maximizar a entrega de valor.
A revolução na entrega de software não virá apenas com novas tecnologias, mas também com uma nova forma de pensar sobre como as equipes são estruturadas e interagem.
Além de “Team Topologies” oferecer um modelo para que sua empresa possa experimentar, também sugere várias estratégias para melhorar o fluxo de trabalho entre as equipes, incluindo:
1. Minimização de Interdependências
Reduzir as dependências entre equipes para que elas possam trabalhar de forma mais autônoma e responsiva. Sempre haverá dependências, como com os demais times (platform e complicated-subsystem) mas procure minimizar.
2. Estrutura de Domínio
Dividir o sistema de software em domínios que podem ser atribuídos a equipes específicas, promovendo a autonomia e responsabilidade clara. Além do mais é um grande facilitador para Microsserviços caso faça sentido.
3. API como Contrato
Usar APIs claras e bem definidas para interações entre equipes, permitindo que mudanças sejam feitas sem causar perturbações em todo o sistema.
4. Pensado pra ser flexível
O legal de Team Topologies é que as equipes são flexíveis e podem ser adaptadas conforme as necessidades da organização.
Como complemento, parece muito promissora a combinação de Wardley Map, DDD e Team Topologies, já que na minha perspectiva, fornece um conjunto de ferramentas visual muito poderoso para projetar, construir e evoluir sistemas adaptativos e estruturas de equipe que são otimizadas para um fluxo rápido de mudanças, com foco em melhorar o desempenho do sistema como um todo e não em partes separadas.
Notem que tentei não fomentar no tema a adoção de Microsserviços, entretanto se o leitor é um arquiteto experiente já deve ter percebido que é um modelo bem aderente pra dar mais autonomia aos times. Seja com Microsserviços, Macrosserviços ou como queiram, não esqueçam que esses modelos escalam a produtividade da organização e não do time, conforme Phil Calçado bem explica no tweet abaixo.
E aí, já tinha visto a associação de Team Topologies, com DDD e com Wardley Maps para melhorar o fluxo de desenvolvimento de um produto? Gostou desse modelo? Deixe a sua opinião 😃
Estou compartilhando algumas ideias nos seguintes artigos:
Arquitetando o Produto: Guiado pela Estratégia;
Arquitetando o Produto: Separando em Partes;
Arquitetando o Produto: Juntando as Peças;
Espero que tenham gostado e até lá!!! 👍
