Times de Plataforma

Photo by Noah Näf on Unsplash

Recentemente, muito tem-se falado sobre o que é engenharia de plataforma, embora não se fale muito sobre o que é necessário para construir um time de plataforma de sucesso. Já que estamos nesta jornada dentro da NDD Tech, nos últimos 2,5 anos, resolvi escrever algumas linhas sobre isso. A intenção é explorar quais atributos acreditamos que são necessários para que os profissionais tenham sucesso em um time de plataforma.

O que são Times de Plataforma?

Vamos primeiro começar entendendo o que é engenharia de plataforma. É importante entender o propósito dessa equipe porque muitos profissionais presumem que a engenharia da plataforma trata apenas de construir serviços comuns que são compartilhados entre várias equipes ou a equipe que automatiza a entrega da infraestrutura. (Já escrevi sobre outros significados da palavra plataforma aqui e do modelo de negócio aqui)

Então, qual é o propósito da engenharia de plataforma?

Os times de plataforma existem para reunir as melhores práticas da organização e de empresas externas em uma solução entregue de forma colaborativa e transversal. Essas práticas geralmente começam como experimentos em diferentes equipes da empresa. Esses experimentos produzem aprendizados que podem se transformar em serviços, módulos ou componentes da plataforma.

Além de construir serviços compartilhados, um time de plataforma atua em uma ampla variedade de áreas. Aqui estão alguns exemplos de tópicos que geralmente são abordados pela engenharia de plataforma:

• Produtividade dos engenheiros;
• Linguagens e ferramentas de apoio;
• Práticas de experimentação e lançamento de features;
• Gerenciamento de incidentes da plataforma
• Padrões de integração por mensageria;
• Observabilidade;
• Infraestrutura de testes;
• Armazenamento de dados etc.

O trabalho dos times de plataforma concentra-se principalmente na alavancagem de longo prazo para a organização, tornando mais fácil para outros engenheiros construir produtos que criam valor para os clientes e para a empresa. Outro aspecto importante está no fato de que esse time tem oportunidade de conhecer a realidade de vários times de desenvolvimento e através dessa visão, recomendar a adoção de padrões.

Muitos papeis

Agora que entendemos um pouco do escopo de trabalho dos times de plataforma, vamos examinar os desafios enfrentados e o que os profissionais que compõem esse time precisam fazer para superá-los. Darei exemplos de dentro da NDD — Tech para mostrar o que fizemos em tais situações e principalmente alguns exemplos que fogem do clichê da engenharia.

1 — Gestão de Produto

A engenharia de plataforma geralmente é introduzida quando uma empresa atinge uma determinada escala, seja no volume ou nas pessoas. Obviamente, as equipes geralmente não esperam a construção de serviços de plataforma para começar a responder a essas necessidades. A maioria das equipes começa com processos offline ou constrói recursos de curto prazo que são posteriormente automatizados ou centralizados. Portanto, você frequentemente encontrará muitas variações da mesma coisa em equipes diferentes.

Os engenheiros de plataforma, portanto, precisam desempenhar em algum momento o papel de Tech Product Manager para entender como essas equipes estão gerenciando o problema, quais são seus principais problemas, contra o que eles lutam, o que está funcionando bem para eles etc. Importante ressaltar que esse não é um papel fixo para uma pessoa, mas sim que diferentes engenheiros, com perfil mais senior, acabam assumindo esse papel em um pequeno espaço de tempo.

Aqui está um exemplo:
Como uma plataforma de documentos eletrônicos que lida com bilhões de transações, executamos milhares de testes automatizados todos os dias. Com a infraestrutura de teste atual perto de seu ponto de ruptura e causando uma grande perda de produtividade do engenheiro, tivemos que investir na aplicação de boas práticas para resolver o problema.

Portanto, como qualquer PM, os engenheiros começaram com entrevistas com clientes (internos) e coletaram informações. Eles se aprofundaram na compreensão dos principais pontos fracos da forma atual de escrever, executar e medir testes. Eles então pesquisaram as melhores práticas do setor, conversando com outras empresas sobre como lidam com os testes e conversando com empresas que operam no espaço de infraestrutura efêmera e outras pesquisas secundárias.

Feito isso, os engenheiros descobriram e priorizaram os principais objetivos que uma infraestrutura de teste precisa abordar a curto, médio e longo prazo. Em seguida, fizeram uma apresentação que captura todo o aprendizado e, logo após, obtiveram a aprovação de outros engenheiros / líderes seniores de que estão lidando com a definição correta do problema. Eles então definiram as métricas corretas para medir o sucesso da iniciativa. Tudo isso antes de escrever uma especificação técnica ou uma única linha de código!

Uma vez que tenhamos feito todo esse trabalho de base, definir as métricas corretas para monitorar o progresso é fundamental. Frequentemente, você verá que os times de plataforma que adotam uma meta de adoção com ‘Número de Serviços Integrados’ como a principal métrica. Essas métricas geralmente não fornecem a imagem certa. Enfrentamos essas mesmas questões e, portanto, tendo cometido o erro, começamos a nos perguntar: ‘E se fôssemos uma startup independente, como seriam nossas métricas?’. Com essa mentalidade, fomos capazes de criar métricas muito melhores, principalmente se elas focarem em resultados dessa adoção. Em um futuro post sobre métricas quero trazer nossos exemplos disso.

2 — Deep Tech

Eu entendo que a frase “deep tech” se refere a organizações que fornecem soluções tecnológicas inovadoras e todo aquele romantismo por trás, no entanto, achei que esta é a maneira mais apropriada de descrever a natureza do trabalho. A construção de capacidades exige que os engenheiros se aprofundem no espaço do problema e na tecnologia envolvida. Os engenheiros de plataforma normalmente trabalham em áreas de nicho muito específicas e adquirem experiência que vai além do uso padrão de uma stack de tecnologia.

Aqui está um exemplo:
Como parte de nosso esforço para melhorar continuamente a experiência de nossos sistemas, investimos fortemente em arquitetura de Micro-Frontends, acreditando no poder de escala dos nossos times e no empoderamento dos engenheiros. Começamos há alguns anos com uma configuração simples de Single-SPA junto com alguns projetos pilotos para validar. Conforme escalávamos, enfrentamos vários desafios em ter uma configuração de micro-frontends rápida e confiável. Também precisávamos integrar todas as micro-apps criadas com as nossas ferramentas de build e deploy, e nesse caso decidimos usar o Lerna em nossos projetos. Devido aos nossos requisitos únicos, não obtivemos uma solução plug-and-play. Tivemos que realizar vários experimentos em projetos pilotos nos primeiros dias para validar a ideia.

Para resolver esses problemas, decidimos experimentar a construção de uma CLI própria, integrada a todas as ferramentas que usamos (Node, Lerna, Angular, Docker, LiteServer, .NET etc.) e a escrita de uma documentação, para melhorar a experiência do engenheiro. Você pode dar uma conferida na imagem abaixo.

Exemplo da nossa documentação

A maioria das declarações de problemas de um time de plataforma são semelhantes. Os engenheiros precisam desenvolver experiência nesses nichos de espaços problemáticos e investir tempo neles ao longo de muitos anos. Eles passam por várias evoluções, resolvendo diferentes necessidades dentro das organizações. Pode não parecer estimulante continuar trabalhando na definição de um problema por muitos anos, mas aqueles que o fazem se tornam especialistas em seu campo.

3 — Vendas

Esta é definitivamente a parte mais difícil e provavelmente a parte com a qual a maioria dos engenheiros de plataforma tem dificuldade. Na NDD — Tech certamente fizemos e continuamos a fazê-lo. Por quê? Uma vez que a maioria das equipes já experimentou e implementou práticas para resolver suas preocupações imediatas, os engenheiros de plataforma muitas vezes têm que assumir o papel de vendedor para convencer outras equipes a migrar de uma solução que está funcionando para eles, para uma solução que pode dar-lhes mais valor a longo prazo.

Na NDD — Tech, não exigimos o uso de uma ferramenta ou solução para nenhuma equipe, mas recomendamos. A responsabilidade recai sobre o provedor de serviços (como o time de Plataforma) para criar uma proposta de valor atraente o suficiente para que outras equipes adotem sua solução. A batalha é multifacetada: negociar backlog para integrar / migrar, superar o conforto de uma solução existente, justificar os recursos ausentes que podem estar disponíveis em sua solução existente, mas não algo que faça sentido na nova plataforma, incentivar os usuários a migrar mesmo que não tenha 100% dos requisitos prontos etc. Agora repita isso para mais de 15 equipes em toda a organização!

Para superar isso, precisamos voltar aos fundamentos do bom gerenciamento de produtos e algumas táticas de vendas. Aprendemos isso da maneira mais difícil quando estávamos tentando impulsionar a adoção do NDD Development Kit (NDK), um kit de desenvolvimento que visa tornar a adoção de um Design System de uma maneira mais suave. NDK é uma solução abrangente que funcionou muito bem para engenheiros de front-end. Uma equipe só precisava gastar algumas horas para se integrar e, ao fazer isso, desbloquearia uma grande quantidade de backlog, não ficando preso na construção de componentes já implementados. Portanto, embora a ideia do NDK fosse incrível, proporcionasse grande valor para todos, fosse rápida para começar um projeto novo e tivesse recebido ótimos testemunhos, observamos uma adoção limitada. Todos nós, incluindo engenheiros, caímos na armadilha de “The Law of Attraction”. As coisas não acontecem só porque você pensa que irão acontecer.

Para resolver esse problema, usamos uma reunião mensal de engenheiros seniores e gerentes como uma oportunidade para vender nossa visão. Passamos muitas horas pensando, preparando e praticando um argumento de venda e, em seguida, fizemos uma demonstração em forma de vídeo e 🤯 (explodimos suas cabeças). O resultado? Criamos uma condição favorável para que as pessoas entendessem que precisavam mudar e que não seria difícil realizar essa mudança.

E sabe como são os vendedores né, assumimos o papel deles na essência realmente acreditando que as coisas seriam fáceis. Hoje estamos confiantes de que quase todos os engenheiros de software da NDD usarão o NDK para seus testes de pré-produção até o final do ano.

Tendo aprendido com isso, agora começamos a trazer esses argumentos, com exemplos concretos de migrações em diferentes fóruns para impulsionar a adoção. Afinal de contas, quem diria que os times de plataforma e desenvolvimento de produto conseguiriam mudar todo o layout de uma aplicação escrita em AngularJS, para um layout em Angular sem reescrever todo o produto e ainda manter funcionalidades em AngularJS? Tudo isso em 2,5 semanas? Bom, esse pessoal conseguiu…

4 — Developer eXperience (DX)

Se você já fez parte de um time de desenvolvimento, sabe que existe uma espécie de largura de banda da engenharia e que ela está sempre alinhada ao trabalho que deve causar o máximo impacto para os negócios. Muitas vezes não é possível conceder um tempo significativo para melhorar o cenário atual e migrar para uma plataforma diferente. Os engenheiros de plataforma, portanto, precisam investir energia na construção de uma experiência de integração incrível que requer quase ZERO esforço dos consumidores. Muitos de nós da área TECH já estamos habituados com o conceito de UX, para o DX trocamos a experiência do usuário pela experiência do engenheiro de software (que também é um usuário).

Você já usou uma ferramenta de engenharia de terceiros que exige que você passe 2 semanas em integração? A mesma lógica se aplica às ferramentas internas, serviços e módulos corporativos. Portanto, mesmo que você impressione todo mundo em seu discurso, se o esforço for muito alto, as chances de obter adoção serão extremamente baixas.

Para superar isso, tentamos fazer algumas coisas. Aqui está um exemplo de como o time de plataforma habilitou a migração para os novos serviços de autenticação criados em cima de uma API de um provedor de identidade:

1. Para facilitar a integração dos consumidores, criamos SDKs para diferentes versões de frameworks que os produtos da NDD — Tech utilizam. O SDK faz todo o trabalho pesado relacionado à autenticação e geração de um JWT e expõe métodos que permitem uma integração fácil.
2. Criamos um portal administrativo para facilitar a execução de testes e a gestão do processo de autenticação assim que forem integrados. Não queríamos que as pessoas tivessem que fazer várias publicações em suas máquinas locais toda vez que quisessem testar suas autenticações e para isso foi disponibilidade uma imagem de container com tudo funcionando.
3. Uma CLI que fosse capaz de subir separadamente micro-apps em modo Debug ou em modo Prod rodando apenas um único comando.
4. Com base no feedback, priorizamos a construção de mecanismos de seeding ao invés de startups vazios que costumavam causar erros. Isso reduziu os problemas de inicialização dos serviços e módulos que eles precisavam integrar em seus produtos.
5. Estrutura de multi-tenant para configurar as regras de obtenção de Tenant baseada em diferentes estratégias escolhidas por cada produto.

Nesse caso, concentrar-se nos usuários avançados é especialmente útil, pois eles são os mais comprometidos e os melhores para fornecer feedback antecipado. Se você se concentrar em obter a experiência certa, os usuários mais casuais acharão muito fácil integrar e usar seu serviço / módulo / componente.

Além disso, você tem a oportunidade de eliminar quaisquer lacunas na integração para que a adoção seja mais fácil de conduzir. Sabemos que temos um longo caminho pela frente, mas quando a DX está presente no dia a dia dos engenheiros de plataforma, certamente eles vão contagiando os demais engenheiros dos times de desenvolvimento de produto a se preocuparem mais com essa causa nas suas aplicações.

5 — Coragem

Estávamos em um cenário com a seguinte afirmação: “A NDD — Tech cresceu!”. Cresceu entre outras razões, através de uma estratégia de diversificação, a empresa possui unidades de negócios diferentes, que atendem segmentos de clientes diferentes, através de produtos diferentes.

O que aconteceu? Surgimento de várias UIs, pouco integradas e inconsistentes nos produtos das diferentes unidades. Precisávamos de uma abordagem para estabelecer e escalar a consistência na interface do usuário em várias grandes plataformas. Naquela época, o termo “Design System” era novidade para muitos de nós. Um Design System é um termo guarda-chuva para vários subsistemas, incluindo bibliotecas de componentes, documentação de desenvolvimento, diretrizes de design, bibliotecas de ícones, kits para designers etc. Resumindo, um produto! Através dele acreditávamos no desenvolvimento eficiente e escalável de produtos que resultassem em experiências consistentes nas plataformas. Esses benefícios levaram muitas empresas a implementá-los nos últimos anos.

Aqui cabe um post exclusivo (que deixarei para outro momento) para falar mais a fundo sobre o nosso Design System, porque criamos ele e os resultados obtidos, mas se você tem curiosidade de entender um pouco melhor do nosso processo de construção, recomendo esse post escrito pelo

Patrick A. G. Naufel

.

Pois bem, tínhamos então uma estratégia, porém além do mundo abstrato da estratégia está o mundo muito mais prático da implementação, que apresenta sua própria mistura única de dragões e miragens.

A equipe do Labs era pequena naquela oportunidade, por volta de 10 pessoas. Divididas em um time de UX e um time de Engenharia. Nem todos iriam trabalhar nessa iniciativa, mas lembro muito bem dos primeiros dias em que começamos a nos organizar para a construção. Olhava no semblante dos colegas e enxergava uma certa insegurança, um nervosismo, imagino que até estavam com aquele frio na barriga, pois eu estava. Era o novo, a mudança, a saída da zona de conforto em enfrentar um desafio que nunca tínhamos passado e principalmente saber que o resultado dela, bem ou mal, impactaria todos os produtos da empresa. Não adiantava pedir para terem coragem ou para ficarem tranquilos que tudo “ia dar certo”, era necessário que eles próprios entendessem que eram capazes de enfrentar o desafio.

Você deve estar se perguntando, o que tudo isso tem a ver com times de plataforma? A resposta é que escolhemos parte do nosso time de plataforma para ser responsável pela implementação da biblioteca de componentes do Design System. Talvez isso não seja muito comum, já li sobre vários modelos de estruturação de times para construção do Design System e essa escolha não é muito popular. Entretanto, naquele momento era o que mais fazia sentido para nós, pois tínhamos nesse time de engenharia pessoas com experiências em outros produtos, com visões de diferentes realidades dispostas a construir algo novo e principalmente algo que eles próprios iriam desenhar visando uma estratégia de fácil adoção. Algo muito alinhado ao que descrevi nos tópicos anteriores.

Impulsionados pela necessidade, juntos começamos a construir o primeiro Design System da NDD — Tech. A forma como nos organizamos foi um modelo de equipe Federado (você pode ler mais nesse artigo do Nathan Curtis).

Federated Model Teams — Nathan Curtis

O modelo federado é uma espécie de comitê, esse tal comitê garante a direção de design de um sistema para um subconjunto representativo e capacitado de designers, líderes designados e engenheiros para colaborar no sistema por um período. Eles tomam decisões de design coletivamente, mesmo que apenas um subconjunto de pessoas (UX e Engenheiros de Plataforma) documentem, construam e comuniquem essas decisões através de artefatos, como um guia de estilo vivo.

Enfim, o ponto que quero chegar nesse tópico, a Coragem para realizar tudo isso. Ninguém desistiu, ninguém se omitiu. Todos foram em busca do melhor resultado possível e essa é umas das principais características que esse profissional deve ter, coragem de enfrentar algo novo, mesmo que você tenha que lidar com algo ambíguo.

6 — Escritores de Conteúdo

Os engenheiros de plataforma não podem se dar ao luxo de perder muito tempo segurando outras equipes. Isso não apenas proporciona uma experiência realmente ruim para os engenheiros de software, mas muitas vezes as dependências se transformam em impedimentos, arruinando ainda mais a adoção. Os engenheiros de plataforma, portanto, precisam escrever documentação de alta qualidade para permitir o autoatendimento. Confiar apenas nas especificações técnicas escritas para o seu serviço não é bom o suficiente. O objetivo da documentação do engenheiro é permitir uma integração fácil, e não educar os usuários sobre o que sua plataforma faz e como o faz.

Na NDD — Tech, estamos tentando centralizar toda a documentação de serviços, módulos e componentes corporativos em um Hub que é uma reunião de portais que contém a nossa documentação. Isso serve ao propósito adicional de fornecer feedback ao nosso time de plataforma sobre como é fácil ou difícil usar nossos serviços.

Como parte da iniciativa, as equipes cobrem:

1. Descritivo com as etapas de integração
2. Código de amostra que pode ser copiado, colado e usado como exemplo
3. Snippets de repositórios já integrados
4. Blogs com conteúdo focado na aprendizagem e divulgação de boas práticas.

O que ainda vamos cobrir:

1. Q&A colaborativo explorando o aprendizado de todas as áreas (se conhecer algum me avise)
2. FAQs de perguntas frequentes (geradas a partir do trabalho conjunto com outras equipes)
3. Um novo canal de comunicação para divulgar novidades do time de plataforma (novas features, correção de bugs etc.) a todos os interessados

É difícil, mas gratificante

Você já deve ter adivinhado que construir serviços, módulos e componentes de uma plataforma costuma ser a parte mais fácil do trabalho. Por isso, esse post foi mais focado em outras habilidades não técnicas que um time de plataforma precisa ter. As tarefas não técnicas às vezes não atraem muitos engenheiros. Falando francamente, não é para todos e depende do interesse e perfil de cada um. No Brasil temos poucas empresas orientadas para a tecnologia há tempo suficiente para ver a escala de tudo isso. Grande parte das empresas que tive contato estão passando por essa estruturação. Isso significa que há poucos profissionais no ecossistema que lideram um time de plataforma para troca de experiências.

O que percebemos em nossa jornada é que um engenheiro de plataforma deve ir além de sua competência central para tornar seu time bem-sucedido. No entanto, aqueles que consideram um desafio que vale a pena vencer, é recompensado com um trabalho extremamente gratificante e que lhes proporciona enormes oportunidades de crescimento.

Está pronto para o desafio? 🚀

Se nosso trabalho o entusiasma, estamos contratando ativamente para nosso time de engenharia. Somos um pessoal maneiro pensando diferente para resolver os nossos problemas do cotidiano e estamos sempre procurando por ótimas pessoas para trabalhar conosco. Estamos procurando engenheiros e engenheiros seniores para quebrar barreiras e construir um novo o futuro para a empresa. Candidate-se através da nossa página de empregos ou contate-me!