Team Topologies ou Topologia dos Times é um livro (por sinal, muito bom de ler) escrito por Matthew Skelton e Manuel Pais, consultores de TI. Ele foca na problemática de como construir times de alta confiança (e é bem interessante que os autores usam este termo ao invés de performance).
Para isso, eles levantam uma teoria de construção de times baseado em problemas de times de DevOps, na teoria cibernética, no framework Cynefin e no pensamento sistêmico (além de também falarem bastante sobre domain driven design, mais voltados para a teoria).
Apesar de seu foco em TI, qualquer profissional envolvido com a formação de equipes vai gostar bastante da leitura, pois os capítulos mostram estudos de caso que ajudam a elucidar os temas que eles debatem em cada trecho do livro. Por essa razão, este artigo traz um resumo dos principais tópicos abordados na publicação.
É possível separar o conteúdo do livro em 4 grandes temas que influenciam na formação de equipes mais eficientes:
- Carga cognitiva
- Lei de Conway
- Topologia dos times
- Modos de comunicação
Vejamos um pouco mais sobre cada um deles a seguir:
Carga cognitiva
“A carga cognitiva também se aplica a equipes que realizam menos codificação e mais execução de tarefas, como uma equipe de operações e infraestrutura tradicional. Elas também podem sofrer de carga cognitiva excessiva em termos de domínios de responsabilidade, número de aplicativos que precisam operar e ferramentas que precisam gerenciar.”
Os diferentes tipos de trabalho que o time precisa abranger, o tamanho e complexidade do domínio de negócios e o número de pessoas externas envolvidas são fatores que influenciam a carga cognitiva com a qual o time precisa lidar. Ou seja, ela está relacionada com a quantidade de informação que a memória de trabalho pode armazenar ao mesmo tempo. Um time nunca deveria lidar com uma carga cognitiva que vai além do seu limite.
A ideia de entender a carga cognitiva e a relação dela com a construção de times é importante, principalmente, devido às perdas de não considerá-la nesse processo. Quando a carga cognitiva não é considerada, as equipes se espalham, tentando cobrir uma quantidade excessiva de responsabilidades e domínios.
Os autores se apoiam nas teorias de carga cognitiva de John Sweller, que estudam o total de esforço mental que é usado em um trabalho que envolve a memória. Com uma alta carga cognitiva, as equipes carecem de tempo e espaço para buscar a maestria de seu negócio, e lutam com os custos de mudar e unir contextos. De acordo com isso, a carga cognitiva pode ser classificada de 3 maneiras:
- Intrinsic load – lida com a complexidade de uma nova informação;
- Extraneous load – informação distrativa ou desnecessária;
- Germane cognitive load – processa e integra as informações existentes e as novas.
Considerando as três classificações acima, o ideal é que os times tenham tempo para focar na germane cognitive load. Isso porque, dessa forma, eles poderão pensar o seu domínio de maneira mais complexa (nesse contexto, domínio é tudo relativo ao software que seja do interesse dos desenvolvedores e dos usuários).
Ainda segundo os autores, para construir times de produto de software é preciso restringir 3 aspectos:
O tamanho do time e tempo de vida da equipe
Times ideais são pequenos e devem existir por períodos de aproximadamente 12 a 24 meses, dependendo da maturidade dos profissionais. Os números de Dunbar nos ajudam a demonstrar que times pequenos necessitam de menos relações de comunicação interna e, consequentemente, geram menos carga cognitiva;
Os relacionamento entre os times
Nem todos os times devem se comunicar. Isso porque o excesso de comunicação é um problema, pois torna as relações menos explícitas, toma tempo e aumenta a carga cognitiva do time. As cadeias de comunicação precisam ser estrategicamente mapeadas;
A quantidade e complexidade dos domínios
Para reduzir a carga cognitiva do time, não devemos dar responsabilidade sobre muitos domínios. Em caso de domínios simples, podem haver mais de um, mas em caso daqueles mais complexos, o ideal é que o time não se sobrecarregue.
Lei de Conway
Segundo Mel Conway, organizações que desenvolvem sistemas estão restritas a produzir designs que são cópias das suas estruturas de comunicação. Já Allan MacCormic e seus colegas em um estudo da Harvard Business Review, salientam ainda que os produtos são espelhos da organização que os produz.
Para evitar isso, precisamos entender o que é necessário antes de organizar as equipes, caso contrário, os caminhos de comunicação e incentivos na organização acabarão ditando o processo. Como diz Michael Nygard: “As atribuições da equipe são o primeiro rascunho da arquitetura”. Não devemos acomodar o trabalho na estrutura, mas desenhar a estrutura para realizar o trabalho da forma mais eficiente.
Outra importante questão levantada é que reorganizações em prol da redução do número de funcionários ou da conveniência de gerenciamento (estrutura pensada a partir de hierarquia de comando) impactam negativamente a capacidade das organizações de construir, operar e manter sistemas de software de forma eficaz.
As reorganizações de estruturas de time que ignoram a Lei de Conway, a carga cognitiva da equipe e a dinâmica entre os times, correm o risco de agir como uma cirurgia cardíaca aberta realizada por uma criança: são altamente destrutivas. Isso porque pessoas de fora da equipe podem interferir nas relações e espaços do time mesmo sem fazer parte dele, sem entender o seu contexto.
Topologia dos times
O terceiro tema abordado no livro são exemplos de topologias de times. O livro não se apresenta como um catálogo exaustivo sobre o assunto, e sim como um guia de referência dos principais padrões (patterns).
É importante salientar que as capacidades precisam ser do time, e não do indivíduo, para não gerar gargalos que comprometam a autonomia das equipes. No livro, os autores explicam cada um dos tipos de times a partir do seu objetivo, discorrendo sobre como sua constituição ajuda na redução dos problemas com carga cognitiva e comunicação. Eles descrevem 4 padrões de times:
- Stream-aligned teams: principal tipo de time, e provavelmente o mais frequente. Representa o fluxo contínuo de uma unidade de negócio, ou seja, uma cadeia de valor, um domínio de negócio, uma persona/público alvo, uma funcionalidade, um serviço, um conjunto de funcionalidades de um produto, um mercado, etc;
- Enabling teams: ajudam os stream-align teams na sua evolução, com especialistas em assuntos diversos, além de serem de natureza colaborativa;
- Complicated subsystem teams: são times que constroem e mantêm uma parte do sistema que depende de conhecimento altamente especializado e difícil de ser distribuído;
- Platform teams: times que provêm serviços internos para o stream-align team, ajudando na redução de carga cognitiva.
Esse modelo de topologia dos times não é estático e deve levar em conta a maturidade e momento da empresa. Sendo assim, os padrões podem ser alterados e recompostos conforme as necessidades da empresa e capacidade das equipes. Na imagem, um exemplo de uma representação de como os times podem se integrar, a partir da sugestão dos autores.
Modos de comunicação
Como comentado antes, nem toda comunicação é positiva, pois aumenta a carga cognitiva dos times. Por isso é necessário mapear e compreender como topologias tão diferentes podem interagir na estrutura. De acordo com o livro, há três tipos diferentes de modos de comunicação:
Colaboração
Nesse modelo, os times A e time B trabalham juntos, exigindo adaptabilidade e alinhamento;
X-as-a-Service
Aqui, o time A provê alguma coisa para o time B, com o mínimo de colaboração. Alguns dos casos mais comuns são os times que desenvolvem bibliotecas de código, de componentes ou APIs, por exemplo, que depois serão utilizadas por outras equipes;
Facilitadores
Nesse modo de comunicação, o time A ajuda ou pede ajuda para outro time, eliminando impedimentos, principalmente quando é necessário um trabalho ativo para a evolução do trabalho ou para a execução de melhorias.
Com base nestes três panoramas, é possível montar todo um esquema de colaboração entre os times dentro e fora de suas estruturas, buscando facilitar o trabalho.
O que devemos absorver de tudo isso
Para finalizar, os autores trazem uma frase de John Roberts, que comenta que criar unidades de trabalho pequenas e empoderadas aumenta muito a velocidade de execução e a adaptação a novas informações.
A entrega de software nas empresas tem sido um tormento. As novas tecnologias dizem que vão ajustar o problema, mas raramente o fazem. Isso acontece porque a maioria das empresas não tem uma estrutura que seja pensada a partir das necessidades do software.
A obsessão pela entrega tende a deixar o fator humano de lado, assim como as dinâmicas dos times inerentes ao desenvolvimento de software, como carga cognitiva das pessoas e a comunicação entre elas.
Os autores do livro perceberam que a maioria das organizações ignoram as vantagens da Lei de Conway, ainda que a conheçam. A ideia do livro é ajudar a endereçar esses problemas de forma que, na hora de se estruturar um time de Produto, esses benefícios sejam considerados de forma a tornar o time mais eficaz.
Ou seja, é importante construir um caminho bem definido de interações entre os times de Produto, de forma que a arquitetura clara e sustentável transforme problemas em uma entrega contínua de valor.
Mais conteúdos para você:
