Olá! Vamos dar continuidade ao nosso curso de Platform Engineering com a aula de Estruturação de Times e Funções. Eu serei o instrutor nesta jornada. Meu nome é Eduardo Munari, atuo atualmente como Staff Technical Product Manager, e vou compartilhar um pouco da minha trajetória. Sou formado em Ciência da Computação pela Unesp, em São José do Rio Preto. Tenho uma pós-graduação em Redes, Infraestrutura e Estrutura de TI pela UFSCar. Também possuo um MBA pela FIAP em Cloud Engineering Architecture e sou um Golden Cube Astronaut da CNCF. Recentemente, passei pelas provas das últimas certificações de Platform Engineering da CNCF e sou um dos desenvolvedores da certificação KCNA, que é a certificação de entrada para o mundo Kubernetes e Cloud Native também da CNCF.
Hoje, vamos nos basear bastante no livro Team Topologies, principalmente na segunda edição, para falar sobre times e a interação entre eles. É importante ressaltar que nosso material não é endossado pelo Team Topologies, mas serve como referência para nossos estudos.
Vamos falar sobre a estruturação de times e funções, começando com o desafio das plataformas. Quando falamos desse desafio, precisamos lembrar do Platform Manifesto, criado pelos coautores do Team Topologies, que segue o mesmo modelo do Agile Manifesto. O Platform Manifesto enfatiza equipes e interações antes de ferramentas e funcionalidades, adoção e engajamento antes de mandatos e padrões, e uma rica experiência de usuário antes de proeza técnica. Vamos discutir bastante esses pontos nesta aula e nas próximas. Não é necessário decorar o Platform Manifesto, mas vamos relembrá-lo durante as aulas.
Devemos estar sempre abertos a mudanças e ser colaborativos para descobrir as necessidades dos usuários, buscando desbloquear clientes internos por meio de padrões de autoatendimento, visando um impacto superlinear com crescimento sublinear. Isso significa que nossa plataforma deve suportar cada vez mais pessoas desenvolvedoras sem que precisemos aumentar proporcionalmente o time de plataforma.
Na nossa agenda, vamos discutir como as plataformas aceleram o fluxo, o paradoxo de plataformas e produtos, e o Platform Engineering como disciplina para superar esses desafios.
Plataformas bem estruturadas aceleram o fluxo de entrega de valor e resolvem problemas. Isso significa que elas devem identificar e resolver as dores dos usuários. Caso contrário, os usuários podem buscar caminhos alternativos, resultando em plataformas tecnicamente impressionantes, mas que ninguém quer usar.
Quando falamos do paradoxo de produtos versus plataformas, entramos em um paradoxo financeiro. Produtos tradicionais têm receitas claras, enquanto plataformas internas têm custos claros, mas a receita que elas devolvem não é facilmente quantificável. Isso pode ser um problema para os times de plataforma, que precisam justificar sua existência e o valor que trazem.
A ideia é usar o Platform Engineering como disciplina para resolver esse desafio. O Platform Engineering não é apenas sobre tecnologia e ferramentas, mas busca uma abordagem sistemática para resolver desafios organizacionais.
A platform engineering (engenharia de plataforma) é mais estratégica do que tecnológica. Embora a tecnologia seja um meio essencial, o foco principal é resolver um problema organizacional. Durante nossa jornada, vamos nos basear em diversos aspectos. Por exemplo, plataformas são produtos internos e, portanto, devem ser tratadas como tal. Precisamos entender os usuários, suas expectativas, dialogar com eles, e ter um(a) gerente de produto para cuidar do backlog (lista de pendências), priorizando com base nos feedbacks dos usuários. É importante medir a satisfação e lembrar que a confiança é a moeda de adoção. Quando as pessoas não confiam em um produto, elas buscam alternativas ou criam novos produtos. Em se tratando de um produto interno como uma plataforma, conquistar a confiança dos times é benéfico, pois eles se tornam promotores, ajudando a divulgar a plataforma e demonstrar sua importância para outros times e stakeholders (partes interessadas).
Devemos medir nosso sucesso em termos de fluxo, considerando quais problemas estamos resolvendo, quais partes estamos acelerando e como estamos entregando mais valor, em vez de focar apenas em funcionalidades. Muitas vezes, nos apegamos a adicionar várias funcionalidades à plataforma, mas elas podem não resolver os problemas reais das pessoas. Nosso objetivo principal é reduzir a carga cognitiva, especialmente dos times de desenvolvimento que entregam os produtos finais. Como engenheiros de plataforma, precisamos entender que, além de aliviar a carga cognitiva dos times, devemos gerenciá-la para que não nos afete. Não adianta transferir o risco de burnout (esgotamento) de um lugar para outro, pois a carga cognitiva não desaparece, apenas é transferida. Precisamos organizá-la de forma que possamos dominá-la também do lado da plataforma.
Uma frase dita por Ivan Botcher resume bem essa ideia: "fazer a coisa certa ser a coisa mais fácil de se fazer". A plataforma deve ser o caminho correto e de menor resistência. Deve ser mais fácil e seguro realizar um deploy (implantação) pela plataforma do que manualmente. Tudo o que criamos na plataforma deve nascer com observabilidade, conformidade e segurança, sem a necessidade de processos adicionais ou abertura de tickets (chamados) para algo tão importante.
Falamos também sobre handover (transferência de conhecimento) e como ele pode interromper nosso fluxo de valor. Baseado no Team Topology (topologia de times), temos os Stream Aligned Teams (times alinhados ao fluxo), que são os times de produto de desenvolvimento que entregam valor, e os times de infraestrutura, chamados de Platform Team (time de plataforma). Vamos explorar mais essas nomenclaturas, mas a ideia é mostrar que muito do que a cultura DevOps trouxe, como unir desenvolvimento e operações em um mesmo objetivo, é para melhorar a transmissão de conhecimento e manter o fluxo de entrega o mais transparente e suave possível. Não queremos mais a situação em que o time de desenvolvimento termina uma implementação e simplesmente passa o problema para o time de operações. Queremos reduzir esses handovers e, quando necessários, torná-los suaves.
Sabemos que os handovers podem causar perda de contexto, pois nem sempre todas as informações são transmitidas. Isso aumenta a carga cognitiva, pois quem recebe a informação precisa entendê-la completamente, e quanto maior a carga cognitiva, maior a propensão a erros. Além disso, há atrasos na assimilação de novos conhecimentos e sistemas, o que pode aumentar o potencial de erros devido à falta de informação.
Vamos iniciar nossa jornada de estruturação de times. Na parte 1, abordaremos os fundamentos da estruturação desses times. Na parte 2, falaremos sobre a anatomia do time de plataforma. Na parte 3, exploraremos as dinâmicas de interação entre esses tipos de time. Na parte 4, veremos como aplicar isso no dia a dia e garantir que esteja funcionando. Esta jornada é sobre a disciplina de engenharia de plataforma e estruturação de times, não apenas sobre ferramentas. Vamos entender os tipos de times, seus papéis, como criar dinâmicas, medir e mostrar valor continuamente, e evitar antepadrões conhecidos. Lembre-se de que é uma maratona, não uma corrida rápida. Vamos juntos, e sairemos do outro lado entendendo cada parte. Até já!
Vamos iniciar nossa jornada com a parte 1 da aula sobre estruturação de times e funções, focando nos fundamentos dessa estruturação. No Platform Manifest, a sugestão é que pausemos o vídeo, façamos uma leitura e estejamos prontos para prosseguir.
Nesta parte 1, nossa agenda será dividida em dois tópicos: a contextualização do porquê estruturar times de plataforma e, de fato, os quatro tipos de times com base no Team Topologies. Recapitulando nosso desafio, discutimos o paradoxo e plataformas que prometem acelerar o valor. Essas plataformas prometem acelerar o fluxo e a entrega de valor, mas frequentemente se tornam gargalos. Nosso objetivo aqui é responder à pergunta: por que a estruturação adequada de times é um fator determinante para o sucesso de uma plataforma? Vamos entender por que a estruturação de um time é fundamental para uma iniciativa de plataforma alcançar o sucesso esperado.
Começamos com a teoria da carga cognitiva de John Sweller, que se baseia em modelos tradicionais do sistema cognitivo. Temos a memória de trabalho, com capacidade limitada, e a memória de longo prazo, que é ilimitada e contém diversos esquemas automatizados para absorver tudo o que aprendemos. A carga cognitiva é a quantidade de recursos materiais que investimos ao realizar uma tarefa, seja aprender ou ensinar algo. Essa carga é finita, e quando excedemos esse limite, a qualidade do que fazemos cai, tornando-nos mais propensos a erros, com menor atenção e inovação.
A carga cognitiva tem três fontes: intrínseca, extrínseca e essencial. A carga intrínseca está relacionada ao aprendizado em si. A carga extrínseca refere-se à qualidade do material utilizado para aprender. Se a documentação não estiver bem escrita, a carga aumenta, dificultando o desenvolvimento e aprendizado. A carga essencial é a internalização de novas informações. Quando uma pessoa desenvolvedora está exposta a toda essa carga, ela enfrenta uma sobrecarga cognitiva, tornando-se mais propensa a erros e menos inovadora, além de estar mais próxima de um esgotamento.
Os times também enfrentam carga cognitiva. Quando um time tem muitas responsabilidades diferentes, isso pode sobrecarregá-lo. Fronteiras e responsabilidades não claras, dependência de outros times e falta de autonomia aumentam essa carga. Um domínio amplo ou complexo, sem fronteiras bem definidas, também contribui para essa sobrecarga.
Quando falamos de transferências e fluxo de valor, o handover causa perda de contexto, aumento de carga cognitiva e potencial para erros. Um exemplo é o TicketOps, que representa o custo oculto do handover. Um desenvolvedor pode precisar abrir um ticket para criar um banco de dados, que passa por vários times, causando atrasos. Uma plataforma bem estruturada resolve isso, permitindo que o desenvolvedor acesse um portal centralizado com automações e recursos necessários, reduzindo o tempo de semanas para minutos.
A ideia é usar o Platform Engineering como resposta organizacional, abstraindo a complexidade dos usuários e processos, padronizando e automatizando práticas repetitivas. Se sabemos que um usuário sempre precisa criar um banco de dados e passar por vários times, podemos automatizar esse processo.
De forma self-service (autônoma), o usuário pode acessar nosso portal, ouvir o CLI, solicitar um banco de dados e, em 15 a 20 minutos, ter esse recurso disponível para trabalhar. Assim, o time de produto pode focar no negócio, sem se preocupar com infraestrutura, abertura de tickets, ou informações que não deveriam ser o foco do trabalho deles.
Gregor Hope, no livro Platform Strategy, afirma: "Construa abstrações e não ilusões." A plataforma deve criar abstrações para tornar a complexidade gerenciável, mas não invisível. Queremos reduzir a carga cognitiva das pessoas desenvolvedoras, transferindo-a para nossos times de plataforma. Nosso objetivo é saber lidar com essa carga cognitiva, organizando-a adequadamente. Construir abstrações significa criar algo que elimina cargas desnecessárias, sem criar ilusões.
Por exemplo, um carro automático abstrai a necessidade de trocar marchas manualmente, mas ainda oferece visibilidade e controle, como mudar para modo manual ou ver a marcha atual no painel. Da mesma forma, uma plataforma não deve apenas prometer que tudo funcionará automaticamente; é preciso considerar como ela escalará, seja com base em requisições, memória, CPU ou tamanho de fila. A ideia é construir abstrações, não ilusões, e sempre fazer a coisa certa de forma fácil.
Com esse princípio, adotamos segurança por padrão. Os templates já vêm com configurações seguras, permitindo que a pessoa desenvolvedora ajuste apenas o necessário, sem se preocupar com segurança. Observabilidade automática é garantida, eliminando a necessidade de seguir checklists ou abrir chamadas para acessar logs centralizados. O compliance é embutido, com um pipeline automatizado que valida e bloqueia, se necessário, qualquer problema no deploy.
Mantemos a mentalidade de produto interno, priorizando pesquisa e interação contínua. É essencial entender o que os usuários desejam e como resolver seus problemas. Métricas de satisfação são fundamentais para avaliar se estamos entregando soluções eficazes. A documentação é uma funcionalidade essencial, devendo ser bem elaborada para que os times a utilizem com autonomia. A plataforma é um produto, e as pessoas devem usá-la por escolha, não por obrigação. Devemos destacar suas vantagens para promover adoção voluntária.
Analisamos também o modelo de maturidade da CNCF sobre Platform Engineering, que possui quatro níveis. O nível provisório envolve ferramentas ad hoc e pouca padronização, com iniciativas de plataforma lideradas por voluntários. No nível operacionalizado, já existem algumas capacidades centralizadas e um time dedicado, ainda que pequeno. O nível escalável trata a plataforma como produto, com roadmap, foco em qualidade e adoção ampla, além de investimento dos stakeholders. Por último, a plataforma otimizada prioriza melhoria contínua, automação e é uma prioridade para a companhia.
Links úteis sobre o modelo de maturidade e avaliação de maturidade são fornecidos. A organização das iniciativas de plataforma é crucial, conforme a lei de Conway, que afirma que organizações produzem sistemas que refletem suas estruturas de comunicação. Para sistemas e plataformas desacoplados e autônomos, precisamos de times igualmente estruturados.
O modelo de plataforma como produto requer um time dedicado, com um Product Manager ou PPM (Platform Product Manager) ou TPM (Technical Product Manager), responsável pela visão, roadmap e estratégia da plataforma. As métricas de sucesso devem estar alinhadas com os objetivos de negócio da companhia. Uma plataforma que não segue esses objetivos está fadada ao fracasso.
Os feedback loops são essenciais, permitindo ouvir e responder aos usuários, mostrando que suas opiniões são consideradas. A plataforma é um projeto evolutivo, não um projeto com começo, meio e fim. Criamos e deprecamos funcionalidades, ouvindo o usuário e alinhando suas necessidades com os objetivos da companhia.
Agora que explicamos essa contextualização sobre a estruturação de times, vamos explorar os tipos de times com base no Tintopolis. Até lá!
Para finalizar a primeira parte da nossa aula, vamos discutir os quatro tipos de times com base no Team Topologies. Quando falamos em quatro tipos fundamentais de times, pode parecer algo pequeno, mas essa simplicidade não é um mero simplismo. Após muito tempo de observação e conversas com empresas, entendendo como os fluxos funcionam e como gerar valor, esses tipos de times foram definidos pelos autores do Team Topologies. Os quatro tipos fundamentais são: Stream Aligned Teams, Enabling Teams, Complicated Subsystem Teams e Platform Teams, que serão os protagonistas na jornada.
Vamos entender um pouco sobre cada um desses times. Começando pelos Stream Aligned Teams, que são os consumidores e geradores de valor. Esses times têm foco no cliente, uma característica principal. Eles são autônomos, precisam ter autonomia para entregar produtos, são persistentes e multifuncionais, com pessoas desenvolvedoras, de qualidade e de design, entre outras especialidades. No contexto de plataforma, os Stream Aligned Teams são os principais clientes, para os quais transformamos nossa plataforma em capacidades. A ideia é permitir que esses times entreguem mais rapidamente, com autonomia e qualidade, reduzindo a carga cognitiva. Por exemplo, em uma empresa, podemos ter um Stream Aligned Team cuidando do checkout, outro do pagamento e outro do catálogo, todos utilizando o serviço da plataforma para deploy, observabilidade, entre outros.
O princípio do Two Pizza Team, criado por Jeff Bezos, aplica-se aos Stream Aligned Teams e outros times. A ideia é que o time seja pequeno o suficiente para ser alimentado por duas pizzas, geralmente de 5 a 9 pessoas. Isso visa comunicação eficiente, carga cognitiva gerenciável, velocidade de decisão e fronteiras bem definidas. Se a carga cognitiva crescer muito, precisamos tomar cuidado. O Two Pizza Team serve como base para entender essas premissas e tomar decisões conforme necessário.
Os Platform Teams são os aceleradores de fluxo e protagonistas da nossa jornada. Suas características principais incluem uma mentalidade de produto, tratando a plataforma como um produto interno, foco em self-service para usuários, expertise técnica profunda e orientação por métricas. Precisamos modular nosso discurso, tratando a plataforma como um produto para que pessoas de negócio entendam. Por exemplo, em vez de dizer que usamos Kubernetes, podemos dizer que fornecemos capacidade de deploy em minutos com auto-scaling.
Na composição de um Platform Team, temos os Platform Engineers, com perfil T-shaped, que conhecem as capacidades da plataforma de forma generalista, mas têm especialidades. O Product Manager, ou Technical Product Manager, ajuda a definir a visão, roadmap e prioridades. O SRE garante a confiabilidade da plataforma, e o Developer Advocate faz a ponte entre a plataforma e os usuários, entendendo suas necessidades. O Technical Writer é fundamental para construir documentações intuitivas, e o Designer melhora a experiência do usuário.
Não devemos ignorar lacunas de habilidade. Precisamos tratar esses gaps com cuidado. Podemos nos basear no White Paper da CNCF para entender as interfaces de plataforma e capacidades técnicas. Um anti-padrão a evitar é o "Build it and they will come". Devemos ouvir os usuários antes de construir, começando pequeno, com MVPs, e medindo adoção e valor. Continuamos iterando com base no feedback.
Por fim, os Enabling Teams são multiplicadores temporários. É importante destacar que eles são temporários por natureza.
Os enabling teams possuem uma expertise técnica em uma área de conhecimento ou em alguma funcionalidade que desejamos implementar, com foco em capacitação. O objetivo desses times é capacitar pessoas e equipes para que se tornem autônomas. Por isso, a interação deles deve ser temporária, permanecendo com as equipes apenas até que estas consigam alcançar a autonomia desejada. Além disso, eles atuam como multiplicadores de conhecimento, permitindo que as equipes ampliem seu conhecimento à medida que aprendem com os enabling teams.
Os enabling teams são úteis em situações como a adoção de uma nova tecnologia, um novo padrão de microserviços, uma nova forma de usar observabilidade, uma nova estratégia de deploy ou melhorias de práticas, como observabilidade e testes. Eles também são importantes para o onboarding na plataforma, ajudando a torná-lo mais autônomo e com menos fricção para os usuários. Além disso, podem auxiliar na resolução de gargalos, como problemas de testes ou práticas de teste lentas.
Os enabling teams podem interagir com as equipes por meio de pair programming, workshops quinzenais ou semanais, mentorias mensais, entre outros. Eles também podem ajudar na criação e melhoria de documentações, entendendo o feedback e aprimorando o material. Por exemplo, em uma funcionalidade de observabilidade, os enabling teams podem realizar uma avaliação das práticas atuais, oferecer workshops sobre conceitos de observabilidade e melhorias, e realizar pair programming para criar métricas e traces customizados. Por fim, eles geram documentação e reduzem o tempo de transição para quem precisará utilizá-la, com vídeos e exemplos explicativos.
Um antipadrão a ser evitado é o enabling team permanente, que indica falha na transferência de conhecimento. Isso pode ocorrer devido à complexidade da solução, falta de documentação adequada ou resistência à mudança por parte das equipes. Quando um enabling team permanece muito tempo com uma equipe, é sinal de que algo está errado na estrutura.
Os complicated subsystem teams são especialistas em áreas específicas e devem ser utilizados com parcimônia. Eles possuem uma expertise técnica em partes específicas da empresa ou aplicações, focando em subsistemas específicos. Esses times precisam ter uma interface clara de comunicação com as equipes e, geralmente, evoluem mais lentamente, focando em manter o funcionamento e otimização, em vez de criar novas soluções.
Criamos um complicated subsystem quando há complexidade extrema em algoritmos, vantagem competitiva, otimização de modelos, codecs de áudio e vídeo, algoritmos de machine learning, entre outros. Esses times são especialistas em legados específicos, regulamentações como PCI, ou em áreas de performance crítica que oferecem vantagem competitiva.
Os complicated subsystem teams podem integrar-se ao platform engineering cuidando de runtimes e segurança, detectando intrusões e ataques. Eles também podem cuidar de video encoding, audio encoding, algoritmos de busca, entre outros, para melhorar a eficiência e a experiência dos usuários.
Para evitar que um complicated subsystem se torne um gargalo, é importante ter APIs bem documentadas, reduzindo a necessidade de interação. Ferramentas self-service podem ser criadas com o apoio dos enabling teams e platform teams, permitindo que o complicated subsystem se torne um serviço self-service.
Os platform teams geralmente fornecem serviços para os stream-aligned teams, como deploy, pipeline, e observabilidade. Os complicated subsystem teams também oferecem serviços para os stream-aligned teams. A criação de serviços resulta da colaboração entre complicated subsystems ou platform teams com os stream-aligned teams. Os enabling teams podem atuar como facilitadores, mostrando como usar funcionalidades da plataforma e ajudando a superar obstáculos.
O Team Topologies não é implementado de forma abrupta. Iniciamos com um piloto, adicionando enabling teams conforme necessário, evoluindo a plataforma e escalando o que funciona. É uma transição gradual, não um evento único.
Para refletir sobre a estrutura dos times, liste todos os times com os quais interage, classifique-os em um dos quatro tipos e identifique anomalias. Utilize ferramentas como Google Slides ou Miro para visualizar a estrutura e identificar gargalos, sobreposições de funções e outros problemas.
Na próxima parte, focaremos no Platform Team, nosso protagonista. Vamos explorar como garantir que ele não seja apenas um time de infraestrutura ou suporte, mas sim um time que gera valor. Discutiremos como esses times interagem, trabalham juntos e geram valor, destacando que Platform Engineering não é apenas sobre ferramentas ou tecnologia, mas sobre organização e propósito.
Até já!
O curso Platform Engineering: estruturar times e demonstrar valor da plataforma possui 140 minutos de vídeos, em um total de 62 atividades. Gostou? Conheça nossos outros cursos de Platform Engineering em DevOps, ou leia nossos artigos de DevOps.
Matricule-se e comece a estudar com a gente hoje! Conheça outros tópicos abordados durante o curso:
O Plano Plus evoluiu: agora com Luri para impulsionar sua carreira com os melhores cursos e acesso à maior comunidade tech.
2 anos de Alura
Matricule-se no plano PLUS 24 e garanta:
Jornada de estudos progressiva que te guia desde os fundamentos até a atuação prática. Você acompanha sua evolução, entende os próximos passos e se aprofunda nos conteúdos com quem é referência no mercado.
Programação, Data Science, Front-end, DevOps, Mobile, Inovação & Gestão, UX & Design, Inteligência Artificial
Formações com mais de 1500 cursos atualizados e novos lançamentos semanais, em Programação, Inteligência Artificial, Front-end, UX & Design, Data Science, Mobile, DevOps e Inovação & Gestão.
A cada curso ou formação concluído, um novo certificado para turbinar seu currículo e LinkedIn.
Acesso à inteligência artificial da Alura.
No Discord, você participa de eventos exclusivos, pode tirar dúvidas em estudos colaborativos e ainda conta com mentorias em grupo com especialistas de diversas áreas.
Faça parte da maior comunidade Dev do país e crie conexões com mais de 120 mil pessoas no Discord.
Acesso ilimitado ao catálogo de Imersões da Alura para praticar conhecimentos em diferentes áreas.
Explore um universo de possibilidades na palma da sua mão. Baixe as aulas para assistir offline, onde e quando quiser.
Luri Vision chegou no Plano Pro: a IA da Alura que enxerga suas dúvidas, acelera seu aprendizado e conta também com o Alura Língua que prepara você para competir no mercado internacional.
2 anos de Alura
Todos os benefícios do PLUS 24 e mais vantagens exclusivas:
Chat, busca, exercícios abertos, revisão de aula, geração de legenda para certificado.
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais.
Aprenda um novo idioma e expanda seus horizontes profissionais. Cursos de Inglês, Espanhol e Inglês para Devs, 100% focado em tecnologia.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Para quem quer atingir seus objetivos mais rápido: Luri Vision ilimitado, vagas de emprego exclusivas e mentorias para acelerar cada etapa da jornada.
2 anos de Alura
Todos os benefícios do PRO 24 e mais vantagens exclusivas:
Catálogo de tecnologia para quem é da área de Marketing
Envie imagens para a Luri e ela te ajuda a solucionar problemas, identificar erros, esclarecer gráficos, analisar design e muito mais de forma ilimitada.
Escolha os ebooks da Casa do Código, a editora da Alura, que apoiarão a sua jornada de aprendizado para sempre.
Conecte-se ao mercado com mentoria individual personalizada, vagas exclusivas e networking estratégico que impulsionam sua carreira tech para o próximo nível.
