O modelo da próxima geração em operações digitais
Olá!
Todo profissional que atua na era digital que eu conheço sofre dos mesmos problemas em praticamente todos os lugares: a necessidade de se lidar com um sistema monolítico, silos/feudos de responsabilidades entre as equipes, reuniões intermináveis e improdutivas, falta de um fluxo de trabalho fluído, ruído na comunicação, equipes generalistas demais, conhecimento acumulado em figuras conhecidas como “heróis”, falta de foco na condução dos produtos, enfim, isso só para listar o que eu lembrei de cabeça escrevendo esse parágrafo.
E qual foi a minha surpresa ao descobrir que durante toda a minha carreira, eu tava olhando no lugar errado para tentar resolver esses problemas? Que tem uma forma até que relativamente simples de reimaginar o fluxo de equipes que de certa forma é até intuitivo para os profissionais de tecnologia?
Apesar de simples, o modelo que irei propor junta conceitos de antropologia, engenharia, teoria da eficiência dos fluxos e mais alguns outros. Se você me acompanha, já sabe o quanto eu apoio a ideia da multidisciplinaridade em tecnologia, certo?
O intuito desse texto é fornecer algumas dessas respostas e — dando tudo certo e eu conseguindo te convencer — quem sabe você não manda esse texto para algum C-Level e as mudanças necessárias são efetuadas onde você trabalha?
Para fins de brevidade, a ideia é resumir as principais ideias do livro Team Topologies (2019), que infelizmente ainda não tem versão em português, portanto, cabe a nós da comunidade técnica espalhar a palavra sobre boas ideias sobre a nossa indústria, certo? :)
Pense em topologia como “estudo sobre os espaços e suas características”. Dessa forma, a ideia geral do livro (espero) que faça mais sentido.
Vamos começar colocando a pedra angular no entendimento desse modelo, que passa por tópicos como a Lei de Conway, o conceito de Carga Cognitiva e o número de Robin Dunbar.
Vamos começar pela Lei de Conway. Essa lei, popularizada por Mel Conway em 1967 em seu artigo “How Do Committees Invent? da Harvard Business Review, diz que:
Qualquer empresa que projeta um sistema, inevitavelmente, produz um projeto cuja a estrutura é uma cópia da estrutura de comunicação da organização.
Isso não é somente uma observação empírica, isso foi comprovado por estudos científicos, inclusive!
Aqui é só pensar um pouco, se você tem um departamento de back-end, um de front-end, um de negócio e um de dados, seu sistema ficaria mais ou menos assim:
A equipe de front fará a UI, a equipe de negócios irá definir as regras, a equipe de dados cuida do banco e por fim, o back-end meio que junta tudo.
Logo, façamos o seguinte exercício mental: o que acontece quando você tem uma única equipe de tecnologia que interage com todo o restante da empresa?
Spoiler: Monolitos. O que acontece quando você trabalha com equipes autônomas separadas por domínio de negócio? Pela Lei de Conway, o modelo de squads só tem como output possível microserviços ou monolitos distribuídos, a depender do nível de maturidade de práticas de engenharia dos times, é importante dizer.
Quando uma equipe é obrigada a lidar com um domínio de atuação muito grande, temos como efeitos colaterais os seguintes problemas: gargalos de performance, cultura do herói (aqui temos o Princípio de Pareto em ação, com 20% das pessoas desenvolvedoras fazendo 80% do trabalho), além de burnout e falta de qualidade no trabalho gerado.
Devido a todos esses problemas, é necessário pensar os times em termos de carga cognitiva, ou seja, o quanto o cérebro de uma equipe consegue lidar em termos de conhecimento sistêmico sem entrar em colapso.
Portanto, a recomendação do livro é pensar a equipe “from the ground up”, ou seja, repensando tudo que envolve o trabalho envolvido, como interações com outras equipes (excesso de comunicação também aumenta carga cognitiva), processos e o propósito de existência daquela equipe em si, para que todo o conhecimento necessário para se realizar a missão daquela equipe — literalmente — caiba na cabeça das pessoas envolvidas!
Você já se perguntou quantas pessoas você consegue ser próximo a ponto de confiar e conhecer perfeitamente o trabalho das pessoas desse grupo?
Felizmente, o antropólogo Robin Dunbar estudou sobre isso e propôs o seguinte:
O número de Dunbar define o limite cognitivo teórico do número de pessoas com as quais um indivíduo pode manter relações sociais estáveis, ou seja, uma relação onde o indivíduo conhece cada membro do grupo e sabe identificar em que relação cada indivíduo se encontra com os outros indivíduos do grupo.
O número se encontra entre 100 e 230 pessoas, sendo por volta de 150 pessoas o consenso em agrupamentos humanos tidos como “grandes e funcionais”, leia-se aldeias, grupos de trabalho e organizações militares.
Sabe a quantidade de pessoas que pela mesma teoria é possível manter uma relação de confiança mais próxima? Dica: é o mesmo número do “Two Pizza Teams” da Amazon. Ou seja, no máximo teórico 15 pessoas em uma equipe, idealmente, menos, por volta de 4~6. Pela minha experiência de gestão, acima de 8 se torna inviável.
A matemática por trás disso se resume a seguinte fórmula para calcular a quantidade de elos de comunicação que um grupo possui: n.(n-1)/2. No qual n é igual a quantidade de pessoas no grupo. Para quem ficou curioso, isso escala!
#sqn.
Em uma escala menor:
Portanto, a lição que fica aqui: restringir a comunicação é SIM uma boa ideia para a eficiência do todo, por mais que pareça contra-intuitivo, para isso, o Team Topologies cita esse artigo aqui, que diz (em tradução livre minha):
“Tecnologia e a organização devem ser reorganizadas de forma que as pessoas sejam isoladas de forma intermitente do trabalho de outras equipes para que o melhor desempenho coletivo ocorra na resolução de problemas complexos.”
Com isso, temos o conceito de Team-Sized Architecture, que diz que o tamanho do time que deve delimitar a arquitetura dos sistemas e não ao contrário, como é a forma tradicional de se pensar no assunto.
Com os conceitos necessários explicados, agora vamos a pergunta de 1 milhão de reais: como evitar a carga negativa da Lei de Conway?
Aqui eu introduzo a Inverse Conway Manuever, que propõe o seguinte: Construa times que reflitam a arquitetura corporativa desejada que os sistemas gerados por esses times multidisciplinares só tem como output possível a arquitetura sistêmica desejada.
Eu enxergo isso quase como uma inversão de dependência (D do Solid), aplicado a estrutura de times.
Além do Team-Sized Architecture, vale mencionar outro conceito importante:
Team API: Cada equipe possui uma API que é exposta como se fosse um produto em si, ou seja, é necessário ter alta disponibilidade, versionamento de rotas com tratamento adequado de breaking changes, práticas de SRE/DevOps e afins. A ideia é simplesmente forçar fronteiras entre os times — e consequentemente, entre sistemas — através de boas práticas de gestão e engenharia.
Lembrando que as fronteiras sistêmicas devem respeitar a carga cognitiva dos times, sempre! Se está grande demais, cito as recomendações para auxiliar nisso no final do texto.
E para que serve tudo isso? Bom, aqui eu vou usar o argumento da eficiência de fluxo do Lean, no qual diz que o importante é otimizar o fluxo de valor como um todo, ao invés de otimizações locais para que a melhora na vazão ocorra de fato.
Para não perder o costume, vou citar a escola old school de computação:
“The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.” (Art of The Computer Programming, de Donald Knuth)
Knuth falava sobre programas escritos em C. Acredito que mesma ideia se aplica a squads e organizações.
Os obstáculos para a eficiência do todo está resumida nessa imagem:
E como organizar a topologia desses times? Simples, a resposta é 7 (4 formatos de times + 3 formas de interação entre eles).
Vou usar como exemplo o domínio de negócio de uma instituição financeira nos exemplos de topologias para ficar um pouco menos abstrato.
Stream-Aligned: Traduzindo ao pé-da-letra é algo como “alinhado ao fluxo de água”, ou seja, como um riacho. São times que tem como missão a entrega contínua de valor relacionada a um determinado domínio de negócio. Ex: Squad de Crédito, Squad de Conta Corrente, Squad de Cartão de Crédito.
Enabling: Times facilitadores que tem uma missão de “destravar” valor para outros times através de auxílio com conhecimento especializado, podendo ter ou não data de validade para o término daquele time. Ex: Squad de DevOps, Squad de Cloud, caso as demais equipes não tenham esse conhecimento.
Complicated Sub-System: Time hiper-especializado, com integrantes que possuem um conhecimento difícil de encontrar e que não vale a pena distribuir esse conhecimento em times stream-aligned. Ex: Uma squad que cuida de um appliance (um hardware dedicado) caseiro de criptografia que é usado na processadora de cartões/pagamentos.
Platform: Time que é responsável por construir o conjunto de sistemas que serão usados pelos times de stream para entregar valor (ou construção de produtos). Ex: Squad de Plataforma de Pagamentos, Squad de Open Banking, Squad de Conta Corrente.
Sobre esse último, vale mencionar o conceito de TVP (Thinnest Viable Platform), ou seja, a menor plataforma viável. Nesse caso, não existe uma recomendação sobre o tamanho da mesma, mas a ideia principal é: quais são os sistemas que podem ser usados como uma espécie de “multiplicador de força” dos demais sistemas para a entrega de valor?
Uma ideia simples sugerida pelo livro é pensar em uma simples Wiki documentando o conjunto de APIs desenvolvidas internamente que podem ser utilizadas na entrega de valor. Isso pode ser considerada uma TVP. Somente com isso já é possível começar a plataforma sem perder tempo efetuando um Big Design Up Front.
Em se tratando dos formatos de interação entre times, temos:
Collaboration: Um time atua mexendo no quintal do vizinho e vice-versa. Geralmente, tem como efeitos positivos inovação e aprendizado. Como ponto negativo: aumenta a carga cognitiva das pessoas desenvolvedoras e as responsabilidades e fronteiras entre os times ficam borradas. Não é recomendado uma cardinalidade maior que 1 para 1, devido ao esforço de coordenação e alta carga cognitiva envolvidos. Exemplos de uso: Um time de entrega de valor trabalhando com um time de um sistema complexo/plataforma para forçar a evolução de outros sistemas junto com o desenvolvimento de um novo produto. Time de sistema complexo com time de plataforma para disponibilizar a funcionalidade do sistema complexo dentro da plataforma.
X-as-a-Service: Um time atua como fornecedor de uma funcionalidade disponibilizada através de API para outros times. Temos algumas vantagens aqui: clareza de responsabilidade e fronteiras, que acarreta em uma carga cognitiva menor. O risco é caso a API não esteja madura, pode impactar na velocidade de outros times, ou seja, perda de eficiência de fluxo. Aqui é esperado que a API funciona na cardinalidade 1 para N, portanto, é pré-requisito se preocupar com volumetria, alta disponibilidade e performance. Exemplos de uso: Times de fluxo ou sistemas complexos usando serviços do time de plataforma.
Facilitação: Um time mais experiente auxilia outro, removendo impedimentos e compartilhando experiência. O ganho é desbloquear o fluxo dos times de fluxo e detecção de pontos a melhorar em componentes e na plataforma. O ponto de atenção é que requer senioridade considerável da parte do time facilitador, quase perfil consultivo ao invés de perfil executor / mantenedor, senão o time mais experiente acaba fazendo o trabalho do menos experiente. Além disso, os times podem estranhar a interação e requer atuação da gestão para neutralizar eventuais dores de cotovelo. A recomendação é que o time facilitador tenha poucos times sob sua tutela a cada dado momento para não se sobrecarregar. Exemplos: um time facilitador atuando com quaisquer outros. Ou times de plataforma ou sistemas complexos ajudando times de fluxo a operar e entender seus sistemas.
Por fim, para evoluir os times, é necessário aplicar o que os autores do livro chamam de Organizational Sensing, que basicamente diz: tudo bem cada time evoluir no seu tempo, dado o seu contexto e propósito. Ou seja, não é algo prescritivo e sim subjetivo, é necessário sentir quando é a hora de mexer. As técnicas recomendadas são: pensamento sistêmico (pensar no todo, sempre), ciclos de feedback (aqui agilidade resolve) e cultura de experimentação e aprendizado (segurança psicológica).
Ou seja, continue com Agilidade + Cultura Saudável que tá tudo bem.
Como auxílio, vale mencionar alguns gatilhos sugeridos de mudança na topologia, ao menos para reduzir um pouco a importância do feeling nesse processo:
Alta Carga Cognitiva: como sintomas temos sistemas sem documentação, times esperando outros times e presença de heróis. Se tudo isso está acontecendo, a recomendação é diminuir o tamanho da responsabilidade de alguns times.
Diminuição da Cadência de Entrega: como sintomas temos percepção de aumento no tempo necessário para release, as métricas de vazão do time pioraram nos últimos meses dado tudo mais constante, reclamação de burocratização no processo de mudanças e aumento de impedimentos devido a espera por outros times. A recomendação aqui é se investir em qualidade (testes e redução de dívida técnica) e aumento da autonomia dos times.
Alta dependência entre negócio e plataforma: como sintomas temos um time stream-aligned confuso dado a quantidade de sub-sistemas na plataforma e o reuso de sistemas está se tornando mais complexo ao longo do tempo. A solução aqui é a mais clichê possível: camadas de abstração. Ou seja, crie “platform-wrappers” que agrupa serviços mais especialistas em abstrações mais generalistas.
E o que é necessário para tudo isso funcionar?
Comece com baby steps. Experimente mudar um time para um dos tipos primeiro, após isso, tente encontrar o fluxo de entrega do valor para o negócio e explicite a TVP com o que a equipe já tem de sistemas desenvolvidos. Depois, encontre gaps de hard/soft skills dos times, gerenciamento de serviços e documentação de sistemas, atuando em cima disso para reduzir o impacto negativo no fluxo como um todo. Por fim, “espalhe a palavra” desse novo modelo de trabalho de forma humanizada, explique os porquês e não desça o novo modelo a goela abaixo.
Lembre-se é um modelo humanizado e eficiente de gestão de times, chega de comando e controle.
E boa sorte!
Você gostou do conteúdo e gostaria de fazer mentoria comigo? Clique aqui e descubra como.
