O termo plataforma é com certeza uma buzzword no mundo da tecnologia. Se você procurar o significado no Google, com certeza irá encontrar uma infinidade de definições diferentes.
Plataforma pode significar coisas diferentes em contextos diferentes, ou ter nomes diferentes com a mesma definição. E é completamente normal que essa diversidade de conceitos gere uma confusão, então tudo bem também se você chegou nesse texto achando que iria ler sobre uma coisa e encontrou outra. (Não vou ficar triste se você desistir da leitura, mas vou adorar se você ficar para aprender algo diferente).
Tipos de plataforma
Dentro do universo de desenvolvimento de produtos, consigo ver 3 tipos de plataformas em destaque. Vou usar termos diferentes para diferenciar cada uma delas, mas deixo claro esses termos ainda não são de comum acordo em toda comunidade, ou seja, usar apenas o termo plataforma já é suficiente para identificá-los, mesmo com suas diferentes definições:
Plataforma de negócios
Aqui estamos falando de plataformas que funcionam como o Airbnb, Uber, Mercado Livre, entre outros. De acordo com o livro “Platform Revolution“ de Geoffrey G. Parker, Marshall W. Van Alstyne e Sangeet Paul Choudary, uma plataforma é um “modelo de negócios que cria valor ao facilitar as trocas entre dois ou mais grupos interdependentes, geralmente consumidores e produtores”. As plataformas fornecem uma base para que diferentes usuários interajam e troquem bens, serviços ou informações, enquanto a própria plataforma permanece como intermediária.
Esse tipo de plataforma na grande maioria dos casos não será interna a uma organização e não será puramente técnica. Ou seja, ela terá uma interface onde um usuário poderá acessar suas funcionalidades (user-facing) e a empresa desenvolvedora dessa plataforma atua como um “meio de campo” entre esses dois tipos de usuário: fornecedor e comprador do serviço em questão.
Plataforma de produtos
nesse caso, são plataformas que criam uma base unificada para outros produtos nascerem. Essas plataformas são geralmente internas a uma organização e na grande maioria dos casos não possuem uma interface gráfica de conexão para o usuário. Esse tipo de plataforma é considerado um produto e na língua inglesa, é comum encontrar a mesma definição usando o termo “product platform”.
Os autores Marc H. Meyer and Alvin P. Lehnerd, no livro “The Power of Product Platforms“, definem esse tipo como “um conjunto de componentes, módulos ou partes comuns a partir dos quais um fluxo de produtos derivados pode ser criado e lançado com eficiência, incluindo seus subsistemas e as interfaces entre eles.”
Plataforma de engenharia
Finalmente chegamos onde eu queria chegar, nesse artigo vamos dar ênfase às plataformas de engenharia, que nada mais são do que ferramentas ou processos que permitem que áreas de engenharia de software de organizações escalem e evoluam seus produtos e seus processos organizacionais. Essas plataformas são puramente técnicas e eventualmente terão integração com uma plataform UI que tornará essa plataforma de engenharia também user-facing e self-service.
Parece complexo, mas fique tranquila que no restante desse texto vamos explorar esse conceito com profundidade.
Plataformas de engenharia: conceitos Importantes
Considerada uma trend no mercado de tecnologia, o conceito de plataforma de engenharia é consideravelmente simples. No artigo, “Platform Engineering 101: What you need to know about this hot new trend“, Luca Galante trouxe a seguinte definição (em tradução livre):
“Plataforma de engenharia é a disciplina de projetar e construir ferramentas e fluxos de trabalho que permitam capacidades de self-service para organizações de engenharia de software na era nativa de nuvem. Engenheiros de plataforma fornecem um produto integrado mais frequentemente referido como uma “Plataforma Interna de Desenvolvedor” (Internal Developer Platform) abrangendo as necessidades operacionais de todo o ciclo de vida de um aplicativo.”
Na prática, plataformas de engenharia podem ser um conjunto de tecnologias, de ferramentas, de serviços, de documentação, APIs ou processos que, de alguma forma, permitem que engenheiras de software de uma organização, consigam desenvolver, testar e implantar soluções para problemas complexos de engenharia e entregar produtos com qualidade para o usuário final.
Dentro desse contexto, alguns conceitos importantes fazem parte do dia a dia de uma pessoa Product Manager trabalhando com produtos de plataforma de engenharia. Alguns deles vão ter uma definição similar à definição da “disciplina” plataforma de engenharia em si, mas mesmo assim é importante saber da existência deles.
Esses conceitos também podem ser triviais para quem já tem familiaridade com o universo de desenvolvimento de software, mas para quem está tendo um primeiro contato, vale aprofundar um pouco. A maioria desses termos são frequentemente usados em inglês, mas vou trazer a tradução livre e uma breve definição de cada um:
IDP – Internal Developer Platform (Plataforma Interna de Desenvolvimento)
Se refere ao produto gerado pelo conjunto de ferramentas, serviços, processos e infraestrutura criados internamente por uma organização para permitir que as pessoas desenvolvedoras implementem e gerenciem aplicações para o usuário final de forma mais rápida, eficiente e garantindo a qualidade.
Uma IDP tem o principal objetivo de oferecer soluções cross-domain (ou seja, que se apliquem a todos – ou maioria – dos domínios da organização) que simplifiquem o processo de desenvolvimento de software, potencializando a experiência da pessoa desenvolvedora com as ferramentas necessárias para focar na criação de valor para o negócio e para o usuário final, em vez de gastar tempo lidando com problemas de infraestrutura e configuração comuns a todas as áreas.
DX – Developer Experience (Experiência do Desenvolvedor)
Assim como no universo de produtos falamos de UX (Experiência do Usuário), no contexto de Plataformas de Engenharia, falamos em DX (Experiência do Desenvolvedor).
DX envolve todos os aspectos da interação das pessoas desenvolvedoras com a organização, suas ferramentas e sistemas. Uma má experiência do dev pode levar a baixa efetividade e baixa performance organizacional. Essa disciplina envolve desde a escolha de ferramentas e stack de tecnologia até a criação de processos e fluxos de trabalho (de preferência automatizados), que facilitam a vida das pessoas desenvolvedoras.
Cognitive Load (Carga Cognitiva)
Se refere à quantidade total de esforço sendo usado pela memória de trabalho. Psicólogos dizem que a aprendizagem é prejudicada quando essa capacidade de memória de trabalho é excedida. No livro Team Topologies, os autores Manuel Pais e Matthew Skelton, enfatizam muito esse conceito, trazendo a visão de que Plataformas de Engenharia tem como um de seus principais objetivos reduzir a carga cognitiva das pessoas engenheiras de software alocadas em times de value-stream.
Reduzir o número de decisões que uma pessoa engenheira precisa tomar, diminuir a complexidade da tecnologia através da automação e integração das infraestruturas, criando assim, de forma consistente ferramentas que permitam que engenheiras trabalhem com maior foco em resolver problemas e entregar features para o produto final.
DevOps (combinação dos termos “Desenvolvimento” e “Operações”)
DevOps é uma abordagem colaborativa entre equipes de desenvolvimento de software e de operações de infraestrutura, que visa integrar e automatizar processos para entregar software com mais rapidez, eficiência e qualidade.
Essa abordagem busca aprimorar a comunicação, a colaboração, a automação e o monitoramento contínuo, para garantir a entrega de software de forma mais ágil e confiável. As boas práticas de DevOps são a base para construção de plataformas de engenharia de sucesso.
Tooling Landscape (Panorama de Ferramentas)
Dado que uma IDP é a soma de todas as tecnologias e ferramentas que uma equipe de engenharia de plataforma une para pavimentar um golden path, nem sempre essas ferramentas e tecnologias serão construídas in-house, ou seja, desenvolvidas do zero dentro de casa.
O mercado de tecnologia conta com uma infinidade de ferramentas que já resolvem problemas conhecidos, então não faria sentido que cada empresa fosse reinventar a roda para ter uma plataforma interna. Então, dentro desse contexto de Plataformas de Engenharia é comum que tenhamos um conjunto de ferramentas que foram adaptadas, customizadas ou inseridas dentro da nossa IDP.
A decisão de construir versus comprar é algo comum e os critérios vão depender da estratégia de negócio e gerenciamento de recursos financeiros de cada organização.
Plataformas de engenharia como produto
O conceito de plataforma como produto não é novo, e se refere principalmente à abordagem de tratar uma plataforma de tecnologia interna como se fosse um produto externo, com uma mentalidade voltada para o produto e práticas de gerenciamento de produto aplicadas ao desenvolvimento, evolução e gestão da plataforma.
Isso implica em considerar a experiência do usuário, a reutilização de componentes, a interoperabilidade, a governança efetiva e a evolução iterativa da plataforma com base nos feedbacks recebidos dos usuários.
Desde 2020 o Tech Radar da Thoughtworks (um famoso relatório semestral que indica as tendências de tecnologia no mundo) sugere que empresas devem adotar Product Management a suas plataformas internas e testar platform engineering product teams. Já em 2021, a tendência era de adoção de times de produto de plataforma e recomendação para evitar times de plataforma em camadas, ou seja, divididos por tecnologia.
Na última edição publicada em Maio de 2023, o poder das plataformas como produto aparece novamente como destaque no report como mostra o trecho a seguir:
“Continuamos recebendo bons feedbacks das equipes que aplicam gestão de produto a plataformas internas. Um recurso importante a ser lembrado, no entanto: não se trata apenas de estrutura de equipe ou mudar o nome de equipes de plataforma existentes; trata-se também de aplicar práticas de trabalho centradas no produto dentro da equipe. Especificamente, recebemos feedback de que as equipes enfrentam desafios com essa técnica, a menos que tenham uma mentalidade centrada no produto. Isso provavelmente significa papéis adicionais, como gerente de produto, além de mudanças em outras áreas, como coleta de requisitos e medição de sucesso. Trabalhar dessa maneira significa estabelecer empatia com as consumidoras internas (as equipes de desenvolvimento) e colaborar com elas no design. As gerentes de produto da plataforma criam roteiros e garantem que a plataforma agregue valor aos negócios e aprimore a experiência da desenvolvedora. Continuamos a ver esta técnica como chave para construir plataformas internas para lançar novas soluções digitais de forma rápida e eficiente.”
Como plataformas de engenharia se relacionam com outros produtos da organização
A construção e/ou evolução de um produto de plataforma interno, ou um IDP, deve partir do pressuposto de colaboração entre o time de plataforma com os outros times de produtos da organização que irão consumir os serviços, ferramentas ou processos criados.
O livro Team Topologies define 4 tipos de times: Stream-aligned team, enabling team, complicated-subsystem team e platform team. A forma que esses 4 tipos se relacionam são explorados em 3 tipos de interação, como mostra a imagem:
Nesse sentido, a forma que o time de plataforma interage com outros times da organização deve ser estrategicamente pensado para cada fase do ciclo de desenvolvimento do produto.
Colaboração
Esse tipo de interação é usado principalmente quando espera-se um alto grau de adaptabilidade e descoberta do produto de plataforma que estamos desenvolvendo. Ou seja, é o momento de o time de plataforma ficar muito próximo de outros times para entender suas dores, problemas, necessidades e desejos; entender os casos de uso do produto que se está criando, os cenários, mapear jornadas e eventualmente participar da rotina daquele time para ganhar um maior contexto do dia a dia e colaborar na ideação e definição de soluções.
X-as-a-service
Esse modo de interação surge em etapas posteriores ao desenvolvimento de uma solução de plataforma. É o momento onde a colaboração diminui e os times precisam testar a solução e entendê-la através de uma boa documentação. Prestar suporte a outros times através de pilotos, reuniões, workshops ou sessões tira-dúvidas também fazem parte desse tipo de interação.
Entretanto, o ideal é que produtos de plataforma sejam construídos para proporcionar autonomia para outros times, então esse tipo de interação precisa ser temporária e ir diminuindo conforme iteramos e melhoramos nossos produtos com base no feedback dos usuários.
Facilitadores
O modo de interação facilitador é mais adequado em situações em que uma equipe precisa da ajuda de outra. Essa ajuda geralmente é fornecida na forma de coaching. Times de plataforma costumam concentrar pessoas engenheiras especialistas em determinadas tecnologias, então é comum que outros times nos procurem para pedir esse tipo de ajuda pontual.
Inner-source
É um outro conceito de interação entre times, que não é citado no modelo do Team Topologies, mas é muito comum em estruturas com times de plataforma é o Inner Sourcing. Semelhante ao conceito de Open Source (conceito bastante difundido nas comunidades de desenvolvimento de software), o processo de inner source é uma abordagem que se baseia no desenvolvimento colaborativo de software dentro de uma organização, em que as equipes internas compartilham o código-fonte, as melhores práticas e as ideias para promover a inovação e a eficiência no desenvolvimento de software.
Conclusão
Para concluir, esse universo de produtos de plataforma de engenharia é algo com muito potencial ainda a ser explorado e um tema talvez um tanto complexo. Algumas empresas, mais maduras em cultura de produto, já trabalham com o esse senso de produto inserido nos times de plataforma de engenharia. Outras ainda estão em processo de amadurecimento e estruturação dessa área.
O papel de PPM (Platform Product Manager) está em crescimento, e embora tenha algumas similaridades com o papel de uma PM de produtos user-facing, o perfil e algumas responsabilidades são bem específicas. E logo vamos explorá-las em um novo texto.
Leia também:
