Construção de times com Team Topologies
Ao longo dos anos, percebemos a dificuldade para desenvolvermos softwares de maneira efetiva e performática, e temos observado o quanto a questão “time” é importante nessa equação. Às vezes, não nos damos conta de que nem sempre precisamos da melhor linguagem, tecnologia ou algum conceito avançado e maluco para termos melhores resultados, mas sim de que o necessário é ter em mente a melhor estrutura organizacional para que tudo flua de uma maneira simples.
Por isso, a ideia de Topologia de times têm nos guiado em nossa evolução atual na Pipefy, demonstrando como devemos nos preparar para alcançar o melhor custo benefício de nosso time a médio/longo prazo. Ao estudar a Topologia de times em comparação a outros modelos de organização e trabalho, e através de estudos que são referência em nossa área, percebemos semelhanças significativas quando revisamos todos os fundamentos do desenvolvimento de software. Isso nos ajudou a obter insights importantes em cada etapa do processo.
Observamos que o Team Topologies é uma maneira diferente de pensar em como uma empresa deve se organizar. Isso porque ela não é uma metodologia voltada exclusivamente aos desenvolvedores, mas que tem maior abrangência pelo fato de auxiliar tanto os gestores quanto os devs, ao concentrar várias técnicas de uma maneira satisfatória. Focando no tão sonhado status quo ou “fast flow”, essa abordagem visa a uma melhor arquitetura de organização para obter o máximo de entregas com qualidade, desempenho e maturidade de uma companhia, o que beneficia todo o fluxo de trabalho, mitigando fatores como estresse e burnouts.
Gosto de pensar que o Team Topologies não é apenas uma metodologia ágil: Matthew Skelton foi além ao reunir várias técnicas e modelos de forma organizada, focando no que há de melhor em XP, DevOps, SRE, entre outros, e entregando conteúdo técnico bruto e de qualidade em cada etapa. Tudo isso pode ser adaptado ao nosso modelo de trabalho, visando a um modelo organizado, baseado em sua estrutura de comunicação e interação de seu time.
1. A dificuldade do Organograma
2. Lei de Conway
3. Lei de Conway Reversa
4. Tamanho do time
5. Carga Cognitiva
6. Topologias Fundamentais
- A dificuldade do Organograma
Uma grande parte das empresas espalhadas pelo mundo são divididas em hierarquias, representadas visualmente por meio de um Organograma Hierárquico Complexo, maçante e linear que demonstra todos os times, departamentos e unidades. Esse modelo de trabalho e comunicação de “cima para baixo” pressupõe que tal divisão de controle possa criar um ambiente que possibilite uma grande concentração de inovações, ao mesmo tempo em que entregamos tudo rapidamente, como se operássemos na linha de produção de uma indústria.
Mas sabemos que se construirmos um software nesse modelo engessado hierarquicamente, criaremos problemas de contribuição, comunicação e, principalmente, de engajamento. Isso certamente cria expectativas irreais devido a uma comunicação lateralizada ou vinda do topo da cadeia. O resultado disso é que os desenvolvedores podem apenas querer saber onde eles estão na hierarquia, transformando o próprio fluxo de trabalho em gargalo no decorrer do dia-a-dia.
Mesmo nas empresas mais organizadas, esse gráfico está frequentemente desatualizado, de difícil leitura e completamente dessincronizado com o mundo real. Se o que precisamos é manter os times motivados, esse modelo dificulta as chances reais de uma equipe realizar o seu melhor trabalho.
Como Pflaeging sugere, a chave do sucesso para o conhecimento do trabalho organizacional é a interação entre a estrutura informal e a estrutura de criação de valor.
O Team Topologies concentra-se principalmente em configurar estruturas organizacionais dinâmicas, com modelos de interação muito bem definidos, que ajudam e, principalmente, facilitam a adoção rápida de novas condições pelo time. Isso é feito de forma a empoderar os times. Assim, quando vistos como os blocos de construção, os engenheiros, devs e POs que fazem parte dessas equipes podem se mover para atuar em conjunto, uma vez que são um grupo de pessoas abordando o mesmo contexto.
Com o objetivo de sair da rigidez e dificuldade de manutenção do sistema de organograma para então aplicar os conceitos de TT aqui na Pipefy, estudamos e debatemos modelos de organização que priorizavam a comunicação. Para isso, precisamos entender a Lei de Conway.
- Lei de Conway
Quando pensamos em uma empresa e consideramos o seu crescimento com sucesso, sua organização passa a ser um tema incontornável, bem como a sua estrutura de time, estrutura de seu software e, principalmente, sua comunicação.
Criada em 1968, a Lei de Conway nos dá a oportunidade de colocar tais temas no foco principal de nossa análise. Posteriormente, percebemos que ignorá-la pode ser a diferença do impacto que seu software pode produzir ou não.
Conway defende que, ao desenhar seus sistemas, as companhias estão fadadas a produzir cópias de suas estruturas de comunicação. Isso pode ser bom ou ruim, pois, se sua empresa tem um grande problema de comunicação, provavelmente isso vai refletir em seu produto.
De maneira simples, se sua comunicação com a área de negócio não é clara, não adiantará trabalhar com as melhores tecnologias e engenheiros, pois a chance de terem um produto de sucesso será pequena. Por outro lado, se uma organização é arranjada em silos funcionais como QA, DBA, Frontend, Backend, etc, é improvável que se produza um produto bem arquitetado de ponta a ponta.
Se a arquitetura de um sistema e a arquitetura de uma organização estão em desacordo ou fora de sintonia, provavelmente, a arquitetura da organização ganha.
Ruth Malan
- Lei de Conway Reversa
Na abordagem de Conway, tendemos a copiar de maneira inevitável nosso modelo de organização para nosso código. Quando invertemos esse conceito, replicamos nosso modelo de software para a organização, ou seja, devemos reconfigurar a maneira como os times se comunicam antes de o software estar finalizado.
Se o estado de uma organização deveria envolver seus times e estruturas de organização para alcançar a arquitetura desejada, então a ideia é que esta arquitetura suporte a habilidade dos times de realizarem seu trabalho, do design até o desenvolvimento, sem necessitar de uma difícil comunicação entre os times.
Em outras palavras, quando aplicamos a reversa da Lei de Conway, podemos desenhar nossos times para dar “match” com a necessidade da arquitetura de software pelo fato de termos separado os desenvolvedores com funções distintas.
Por segurança, com as mudanças que o fast-flow vai impactar, devemos ter em mente que o escopo do time e sua arquitetura devem estar alinhados. Por isso, após termos o rascunho dos atributos para a equipe, devemos aplicar boas práticas de arquitetura de código como:
- Baixo acoplamento — componentes não devem ter fortes dependências com outros componentes;
- Alta coesão — componentes devem ter suas responsabilidades e limites claros, indicando uma forte relação em seus elementos internos;
- Princípios de arquitetura como SOLID (Single Responsiblity, Open-Closed, Liskov Substitution, Interface Segregation e Dependency Inversion ), KISS(keep it simple, stupid) e DRY(Don’t repeat yourself).
Essas práticas facilitam a otimização e incrementam a maneira como exploramos nossa arquitetura para facilitar mudanças rápidas com um custo relativamente baixo.
- Tamanho do time
Assim que temos uma boa ideia sobre o tamanho de nosso time, devemos levar em consideração o relacionamento das pessoas dentro dele. Isso porque o Team Topologies prega fortemente que se quebrem quaisquer barreiras de comunicação. Afinal, não adianta contarmos com os melhores engenheiros do mundo se temos uma comunicação falha.
O limite do time vai além de um número: devemos pensar que um time tem que promover a confiança interna e um bom entrosamento, como em um time de futebol. A pesquisa feita por Dunbar demonstra que, em um time pequeno, conseguimos fomentar a confiança, resultando em maior produtividade. É claro que existem exceções em que grandes times conseguem manter um alto grau de confiança, mas são casos raros. Se pensarmos em nosso time como nossa família, é natural não termos contato com todos, e Dunbar conseguiu encontrar alguns padrões de confiança em sua pesquisa.
Mesmo depois de encontrar os números certos e as pessoas certas, ainda precisamos mudar o mindset do time para a comunicação fluir de forma a obtermos os benefícios de um time compacto com o conhecimento certo. Para tanto, os membros devem entender que devemos colocar as necessidades do time acima das suas próprias, cumprindo acordos de trabalhos básicos como manter as discussões e investigações mapeadas, manter o foco do time em seus objetivos (sejam eles metas ou iniciativas), pontualidade, etc.
- Carga Cognitiva
De nada adianta termos o time em um tamanho adequado, mas com responsabilidades demais. Por isso, para um time se manter focado e entregar com o melhor desempenho possível, devemos saber medir sua carga cognitiva e identificar seus gargalos antes que seja tarde. Para entendermos melhor o que é carga cognitiva, devemos entender como aprendemos, sabendo que nossa memória é dividida em Memória de Trabalho e Memória de Longo Prazo. Estudos como o de John Sweller(Cognitive Load Theory -1988) mostram que conseguimos manter entre 7 e 9 processos em nossa memória de trabalho, e, cientes de que uma pessoa tem tal limite de processamento de informação ao mesmo tempo, devemos nos planejar para evitar uma sobrecarga de informação.
Mas, afinal, o que é a carga cognitiva?
A quantidade total de esforço mental sendo usada na memória de trabalho.
John Sweller
Independente do quão sincero é seu time, a carga cognitiva é difícil de metrificar. Apesar disso, o gerenciamento inadequado da carga cognitiva pode trazer grandes dificuldades para um produto, assim como o mau gerenciamento da qualidade da comunicação.
Essa carga é dividida em três momentos, Intrinsic, Extraneous e Germane. No contexto de desenvolvimento de software, podemos defini-las como:
Intrínseca — a complexidade de fazer algo novo. Por exemplo: quando temos um Épico ou tarefa muito grande para fazer, qual será a quantidade de recursos cognitivos para transferir esse conhecimento para a memória de longo prazo.
Estranha (Irrelevante) — esse tipo de carga cria distrações e evita que a nossa memória de trabalho funcione corretamente. Exemplos dela são: trabalhar em um ambiente barulhento, falta de familiaridade com a ferramenta de desenvolvimento ou um código mal escrito. Tudo isso bloqueia seu aprendizado e torna o acesso à memória de longo prazo difícil. Logo, devemos diminuir essa carga ao máximo.
Germane (Relevante) — essa é a carga que implica um processo mais profundo, que é também conhecido como flow, nível cognitivo em que conseguimos processar assuntos complexos, acessamos nossa memória de longo prazo com facilidade e interagimos melhor com nosso raciocínio. Portanto, é a carga que devemos buscar e cujo uso devemos maximizar.
Quando a carga não é considerada no dia-a-dia, percebe-se que o time começa a perder tempo e foco pelo simples motivo de ter uma excessiva quantidade de responsabilidades e domínios. A imagem abaixo demonstra que as features e tarefas competem com outros pontos cruciais que sugam nossa capacidade cognitiva e para os quais às vezes não damos atenção.
Precisamos ser cautelosos e saber gerenciar muito bem nossa comunicação e nosso time para buscar o melhor da teoria da Carga Cognitiva. Para isso, devemos gerenciar a carga Intrínseca. Por exemplo, quebrando um Épico em Histórias e posteriormente em tasks, reduzindo a carga irrelevante, trabalhando em um ambiente quieto, reduzindo o número de frameworks e mantendo um código saudável, e, por último, maximizar o uso de nossa Carga Relevante com apropriada repetição em contextos diferentes.
- Topologias Fundamentais
Quando definimos o tamanho, os domínios e as pessoas de um time, conseguimos descobrir qual a topologia desse time. Dessa forma, cada serviço ou aplicação criada deve ser de propriedade total de uma equipe com capacidade cognitiva para construir e operá-lo. Isso levanta dúvidas como: temos o time certo para o momento? Falta capacidade em algumas áreas que aparentam não ter donos? Sendo assim, devemos pensar em como cada time se encaixa dentro da organização. Para simplificar esse processo, conseguimos reduzir o número de variação de times para quatro times fundamentais por meio do Team Topologies.
Stream-Aligned Teams — Este time tem como principal fundamento o fluxo contínuo de trabalho fortemente alinhado ao domínio do negócio ou capacidade organizacional. É o time responsável pela entrega de valor, que deve ter muito claros os seus propósitos, objetivos e responsabilidades, que podem variar desde um simples produto, serviço, ou uma persona, até um conjunto de features ou uma jornada de usuário.
Enabling-Team — Este é um time de alta performance, que é composto por especialistas de grande nível técnico ou de domínio de negócio, que realizam a ponte para a capacitação dos Stream-Aligned teams, pois estes estarão focados em entregas de valor. Como esse time tem um forte senso colaborativo, consegue espalhar conhecimento e aumentar a autonomia do stream-aligned sem tornarem-se heróis.
Complicated-Subsystem Teams — Este time é responsável por construir e manter uma parte do sistema com forte dependência de um conhecimento específico A maioria desse time é de especialistas em uma área de atuação, entendendo muito bem como realizar mudanças nos módulos e submódulos do sistema.
Platform-Teams — O propósito desse time é permitir que o time de stream-aligned entregue seu trabalho com completa autonomia. Esse time fornece serviços para reduzir a carga cognitiva que é necessária ao stream-aligned para construir esses serviços.
Melhoria contínua
Com nossos times definidos, ajustados e classificados, conseguimos dar suporte a um crescimento rápido e sustentável, com entregas de diferentes times em diferentes momentos. Assim, criamos um ambiente com baixo acoplamento e boa comunicação, guiando nossas decisões para alcançar o fast flow e dando para toda a organização uma missão realista.
Como aplicar tecnologia impulsionada pelo valor de negócio? Aqui na Pipefy olhamos para essa pergunta com carinho e estamos nos organizando de maneira que as respostas favoreçam mudanças simples com alto impacto. Por esse motivo, estamos sempre revisando e refatorando nosso fluxo, aplicando topologias de times focando em People First, e utilizando várias abordagens para que nossa reoganização de time esteja bem alinhada com nossas metas, clientes e valor de negócio.
Referências:
Construção de times com Team Topologies
Escrito por: Eduardo Hattori
