Team Topologies? O que é?
Seus projetos estão atrasados? Não está conseguindo cumprir com as metas? Seu time está esgotado, sobrecarregado e fazendo muitas horas extras? Você sempre tem assuntos pendentes com outras pessoas ou times? Você passa o dia apoiando outros times e não consegue focar nas suas atividades?
Caso seja este o cenário em que se encontra, é aqui o seu lugar, esse conteúdo vai te ajudar MUITO!
Team Topologies é um conceito modelado por Matthew Skelton e Manuel Pais, baseado na análise, acompanhamento e vivência de muitas organizações globais, visando identificar como conceber times altamente eficientes, autônomos e adaptáveis.
Neste artigo trago brevemente os principais detratores e as principais boas práticas que aprendi. Espero que gostem e aproveitem o conteúdo!
Os principais detratores 🔻
São apenas 4!
Dependência bloqueante e transferência de responsabilidade
Sabe quando você está desenvolvendo e fica pedindo pra outra equipe ou pessoa fazer uma parte do processo?
Em muitas companhias vemos os times de infra, segurança, devOps e devSecOps separados em silos, os quais tem que lidar diariamente com vários projetos e contextos diferentes, gerando dessa forma sobrecarga do time e dependências, as quais bloqueiam outros times da organização.
Alta carga cognitiva e múltiplos projetos
Já se deparou com o cenário de trabalhar em vários projetos ao mesmo tempo? Ou de mudar de projeto com frequência? Ou até mesmo a obrigação de usar certas ferramentas que mais atrapalham do que ajudam?
Se respondeu sim para alguma das questões acima, possivelmente você está sobrecarregado, ou ficou em um certo período.
Quando lidamos com contextos diferentes nossa mente se esforça para decifrar aquele cenário, e tem a famosa curva de aprendizado, na qual entregamos menos pois estamos ainda aprendendo e nos adaptando.
Pois é, cada mudança no projeto ou mudança de projeto, pode gerar essa aumento na carga cognitiva e desacelerar a equipe, eventualmente até desmotivar e desengajar no propósito do time!
Inobservância da lei de Conway na definição dos sistemas sociotécnicos
Lei de Conway? Sistemas sociotécnicos? Que isso, Tiago?
Bom, Melvin Edward Conway é um cientista da computação e programador americano, o qual cunhou a seguinte lei:
“As organizações que projetam sistemas são obrigadas a produzir projetos que são cópias das estruturas de comunicação dessas organizações”.
Explicando um pouco o conceito dessa lei, basicamente é que a forma como você monta seus times e a interação entre eles, é que vai determinar como o seu sistema vai ser, ou o quão difícil vai ser para chegar ao resultado final.
No caso de você projetar um software, sem “projetar” as equipes, deixando à sorte e disponibilidade da organização, há uma alta probabilidade do projeto ficar diferente do planejado, ter retrabalho, replanejamento, e um grande esforço até chegar ao resultado esperado.
O mesmo ocorrerá se você projetar as equipes, ou ter estruturas fixas de times com papéis rígidos, sem considerar o projeto do sistema e as diferentes arquiteturas presentes na organização.
Por fim isso é o sistema sociotécnico, a combinação do social, comunicação, interação dos times e indivíduos, com o técnico, a arquitetura, o design de um sistema.
A falha de comunicação 📣 🙉 🙊
Quando se trata de comunicação, vejo dois extremos bem distintos:
Quando você tem alguma dúvida ou precisa comunicar alguma modificação, você não sabe com quem, quando, e como falar com outros times ou indivíduos?
Ou …
Na sua organização a comunicação ocorre por intermediadores? As verticais diferentes ou times de áreas diferentes não podem se comunicar diretamente, apenas através de caminhos fixos e pré determinados?
Você acaba de encontrar um dos detratores mais comuns do nosso dia a dia, a má comunicação!
O que fazer?
Agora que estamos cientes dos nossos pontos fracos, como podemos melhorar? Quais são as práticas e princípios abordados no livro?
Team First
Primeiro de tudo é que o time vem primeiro, para melhorar a performance do time, nada melhor do que colocar o time em primeiro lugar!
Team First é colocar os interesses do time a frente dos interesses individuais, como por exemplo ser pontual, focar nos objetivos do time, priorizar o desbloqueio dos colegas à uma nova atividade, compartilhar conhecimento e apoiar colegas menos experientes, estar aberto para novas soluções, ouvir a todos os membros sem julgamento …
Team First é remover as barreiras organizacionais para o time, tais como forçar o time a utilizar ferramentas que não atendem as necessidades, criar processos e dependências bloqueantes, criar multiplos controles de autorização e execução.
Em relação a novas ferramentas e plataformas, Team First é treinar, ensinar e incentivar o uso das novas ferramentas e plataformas, mas sempre deixar a cargo do time adotar ou não tais ferramentas, ao seu tempo e necessidade.
“You build it, you run it”
A companhia deve confiar no time, de modo que o time seja dono do módulo ou subsistema e tenha autonomia e capacidade para lidar com todo seu ciclo de vida. Desde a inicialização, deploy, teste, homologação até produção, manutenção e eventual descontinuação!
Times pequenos e de longa data, promovem uma alta confiança entre os indivíduos, trazendo uma considerável melhora de performance. O livro aborda alguns números sendo estes entre 5 e 9 membros.
Outro ponto positivo de manter os times unidos se baseia no modelo de Bruce Tuckman, no qual ele demonstra os quatro estágios da criação de um time, passando entre “Forming”, “Storming”, “Norming” e “Performing”, logo se nosso time está sempre mudando, acabamos não chegando ao “Performing”.
Indivíduos não devem ser compartilhados entre times! O “pertencimento” a mais de um time causa um conflito de interesses entre os times, além de aumentar consideravelmente a carga cognitiva, devido a constante mudança de contexto. Normalmente isso gera bloqueios e atrasos, além de sobrecarga.
Team API
Definir um caminho claro para a comunicação, onde, quando e como deve ocorrer. A proposta do Team API é criar uma documentação simples no confluence, por exemplo, na qual traga todas informações importantes daquele time além de um esquema de comunicação bem definido. Aqui o objetivo não é limitar a comunicação, mas sim organizar e direcionar a mesma.
O que precisa ter nessa landing page do time?
- Sistemas, serviços, bibliotecas e artefatos sob responsabilidade do time (owner).
- Estratégias de teste e versionamento.
- Wiki, documentação, swagger e credenciais dos serviços.
- Práticas e princípios da equipe.
- Release notes, roadmap e prioridades da equipe.
- Preferências de comunicação (quando, como, onde).
Reverse Conway Maneuver
Primeiro defina uma boa arquitetura, escalável, resiliente, adaptável a ao fluxo de mudanças rápidas, depois adapte a estrutura dos times para compatibilizar com a arquitetura definida. Por fim defina a role do arquiteto sociotécnico, normalmente é um arquiteto experiente que mantem em mente a Lei de Conway, este arquiteto vai ajudar a modelar o org design e as interações entre os times, de modo a beneficiar tanto o design do sistema quanto o aspecto social entre os times.
Carga cognitiva do time
A carga cognitiva é a definição do quanto de esforço mental o time está fazendo para absorver os detalhes técnicos, domínio de negócio, necessidades dos usuários e possíveis integrações e interações com outros times.
Manter a carga cognitiva em níveis adequados é fundamental para um time de alta performance, pois a mesma atua como barreira e detrator, significando que o time não domina o contexto no qual está inserido.
Para medir a carga cognitiva, o livro não determina uma regra, mas sim traz um ponto de partida, utilizando formulários anônimos, com perguntas específicas do contexto do time, abordando as ferramentas, métodos, processos, negócio, integrações e interações. Dessa forma conseguimos identificar os pontos de melhoria do time como um todo e a partir daí promover treinamentos, plataformas ou até refinar o processo.
Você pode encontrar um exemplo de formulário e muitos outros templates no git do Team Topologies -> https://github.com/teamtopologies
Os 4 tipos de times
Stream-Aligned team é o time que gera valor para o usuário final. Por si só este time deve apresentar um alto grau de conhecimento de negócio, além de dominar o contexto técnico relacionado ao serviço ou módulo.
Enabling team é um time mais sênior, com boa didática e comunicação. Este time será o responsável por habilitar os outros times em novas tecnologias, processos e ferramentas, afim de aumentar o conhecimento do time relacionado ao contexto técnico e diminuir a carga cognitiva.
Complicated Subsystem team é um time que nem sempre existe pois nem todas as companhias tem esta necessidade. Um bom exemplo deste tipo de time são os times de engenharia de dados e inteligência artificial, nos quais temos uma alta complexidade técnica e de negócio. Logo, isolando este contexto em um time mais especialista e capacitado, é possível controlar a carga cognitiva de todos os times.
Platform team é um time composto por especialistas e arquitetos, capazes de criar bibliotecas, plugins, ferramentas, templates e serviços com a finalidade de diminuir a complexidade técnica no contexto dos outros times, diminuindo assim a carga cognitiva e aumentando a performance. Um exemplo dos entregáveis deste time são templates base para inicialização do micro-serviços, provimento de pipelines e infraestrutura automatizadas, scripts de inicialização e configuração do ambiente de desenvolvimento…
Isso é tudo pessoal!
Espero que estas dicas realmente façam a diferença na sua realidade!
Obrigado pela leitura! Abraço!
Referências
