Engenharia de Software: produto vs plataforma
Postado originalmente no Dev na Gringa Substack. Quer receber futuros artigos no seu e-mail? Assine gratuitamente aqui.
Nesse artigo, vamos discutir as diferenças entre engenheiros de produto e plataforma. Engenheiros de produto trabalham em software usados pelo consumidor final. Já os de plataforma dão suporte para os engenheiros de produto entregarem software maneira rápida e escalável. Não conhece esses termos? Fique comigo até o final e vamos aprender juntos.
Engenharia de Software é uma disciplina recente. Nossa história começou cerca de 64 anos atrás, em 1960. Evoluímos muito nas últimas décadas. Mas, ainda somos uma ciência nova.
Por isso, o foco das escolas e universidades se concentra em como criar software. Como devemos manusear o seu ciclo de vida. Quais fundamentos de computação são necessários para criar suas abstrações. Como vamos implantar esse sistema. Escalabilidade, manutenibilidade, confiabilidade.
E isso faz sentido. A concepção, planejamento, implementação e release de software não são atividades simples.
Porém, o software é feito para os usuários. E o seu valor final depende se ele atinge o impacto planejado para eles.
Isso é ainda mais importante para empresas que tem como software o seu centro de lucro.
Por que eu não concordo com a separação entre backend e frontend
Suponha a seguinte situação.
Você é um engenheiro de software focado em frontend. Notou que uma das APIs que você consome para montar uma UI começou a apresentar piora no tempo de resposta. O tempo foi de uma média de 100ms para 600ms.
Qual deve ser a sua primeira preocupação?
Você pode pensar: preciso chamar alguém de backend para resolver isso. Porém, isso irá estender ainda mais a duração do incidente.
Portanto, a principal preocupação deve ser o seu cliente. Você deve resolver a degradação de performance o mais rápido possível. Cada segundo que isso continua, você perde um pouco da confiança dos seus usuários. Algo que é difícil de recuperar.
Então, isso quer dizer que você precisa tentar resolver você mesmo. Ou então pedir ajuda a alguém com mais experiência que você nessa área. Mas não para aí. Faça um pair com essa pessoa. Aprenda o que você não sabia. Não deixe que a sua zona de conforto lhe deixe afastado disso.
Nessa situação, talvez envolva adicionar um novo index no banco de dados. Algo que você possa não ter feito antes.
Mas, é importante que você aprenda. Para que, numa situação futura, se houver um problema semelhante, você consegue agir rapidamente.
O ponto é: você não pode deixar que a falta de familiaridade lhe afaste dos problemas mais importantes do negócio.
E é por isso que eu não acho que a separação entre backend e frontend fazem sentido.
Estamos numa era onde existem cada vez mais recursos para aprender sobre o que não sabemos. Faculdade, cursos, livros, e mais recente, inteligência artificial.
O custo para se familiarizar com algo desconhecido cai a cada dia que se passa.
O mais importante é trabalhar no que vai gerar o maior impacto para o negócio.
Linguagens de programação, stacks, são apenas ferramentas.
O importante é você entregar valor para o seu usuário final.
E fullstack, faz sentido então?
Fullstack é um engenheiro que escreve código que roda no cliente e em servidores? Ou ele também dá manutenção em bancos de dados? Ou quem sabe escreve software development kits (SDKs) para bibliotecas?
Veja que é difícil saber aonde exatamente as linhas terminam.
Existe stack demais. É impossível uma pessoa ser capaz de gerenciar tudo.
Porém, aqui está a verdade: você não precisa saber de tudo.
Engenharia de software é uma atividade altamente colaborativa. Você pode contar com outras pessoas da sua equipe para lhe ajudar, conforme necessário.
Mas, também é importante que você tenha um conhecimento amplo. Que não envolva apenas uma ferramenta específica. Que você saiba se orientar quando houverem incertezas. Um profissional T-shaped.
Está tudo bem você se especializar em algum assunto que lhe interesse mais. E isso pode inclusive ajudar no seu crescimento profissional.
Mas também é importante que você tenha um conhecimento geral sobre as áreas adjacentes a sua.
Uma separação mais coerente
Ao invés de pensar em backend vs frontend, quero introduzir um conceito que li recentemente.
Engenheiros de Produto vs Engenheiros de Plataforma.
Se você concentra seus esforços no seu usuário final, você está mais perto do lado de produto.
No entanto, se você trabalhar mantendo a infraestrutura para as aplicações da sua empresa, isso lhe deixa no lado da plataforma.
Ambas as áreas são necessárias para a entrega de um software de alta qualidade.
Porém, os clientes de cada uma serão diferentes. E as preocupações e qualidades de cada um se tornam outras também.
Engenheiro de Produto (Product Engineer)
A principal preocupação de um engenheiro de produto é entregar um ótimo produto. Existe uma preocupação maior com a pergunta: “por que vamos construir isso?”.
Isso quer dizer que estes engenheiros também serão mais próximos de outros departamentos na empresa. Pessoas que possam ajudar a construir uma ponte entre o código e o produto. Gerentes de produto, designers, suporte ao usuário, vendas e marketing são alguns exemplos.
Engenheiros de produto também se preocupam com o ciclo completo no desenvolvimento de software. Desde a concepção inicial até o suporte ao usuário.
A prioridade para engenheiros de produto é entregar valor aos usuários.
Isso quer dizer que o foco deixa de ser em entregar o código perfeito, escalável e modularizado.
Pois entendem que o código que vira débito técnico é aquele que gerou valor. E quem sabe algum dia, será refatorado.
Engenharia de Plataforma (Platform Engineer)
Sim, software bom é aquele que gera valor e receita. 💰
Porém, ainda precisamos ter certeza que esse software será executado, seguro, testado e escalável.
E existem diversos pilares para que isso aconteça.
Times de plataforma são formados por engenheiros que tem o foco entender como executar toda a infraestrutura de uma empresa. E fornecer uma interface comum para todos os times de produto dela.
No fim, também são engenheiros de produto. Mas o seu usuário final são os próprios engenheiros de software da empresa.
Com isso, é possível centralizar diversas preocupações como segurança, logging e compliance a nível de plataforma na empresa inteira.
É uma organização que combina Developer Operations (DevOps) e Site Reliability Engineering (SRE).
O escopo principal aqui é fornecer uma interface unificada para as apps da empresa. Com foco em escalabilidade, manutenibilidade e resiliência.
O objetivo dessa organização também é reduzir o esforço cognitivo para os engenheiros de produto. De modo que eles possam dedicar sua atenção àquilo que trás o retorno financeiro para sua empresa: as aplicações utilizadas pelos usuários.
Conclusão e recomendações
Engenharia de Software, na maioria das vezes, não é o produto final. É o meio pelo qual entregamos valor o mundo real. Como o nosso software irá impactar o dia-a-dia das pessoas.
Isso quer dizer que todos nós devemos nos centralizar no produto?
Não necessariamente. A plataforma também é essencial para fornecer uma boa experiência para nossos desenvolvedores de produtos.
Em empresas grandes, com milhões de usuários, a plataforma se torna ainda mais importante. Pois a complexidade dos sistemas aumenta de maneira estratosférica.
Em startups, engenheiros de produto serão mais essenciais. Pois os desafios se encontram mais na procura de product market fit. Ou seja, encontrar uma ideia que é escalável, pode ser resolvida com software, e que principalmente, gera receita.
Conforme o sistema cresce, os desafios de sistemas distribuídos se tornam mais difíceis. Pessoas que tem paixão por esses problemas se darão bem na área de plataforma.
Por definição, haverão mais vagas de produto do que plataforma. Porque existem mais usuários finais do que times de desenvolvimento.
Mas, certamente há uma carência para ambos.
Para engenheiros que não se preocupem com as tecnologias. Mas entreguem impacto e produtividade para os seus usuários finais. Sejam eles engenheiros internos da sua empresa, ou usuários externos.
Portanto, se você gosta de estar mais perto dos seus usuários, pesquise sobre product engineering. Sim, em inglês, para não confundir com a área de Engenharia de Produto, que no Brasil é um outro curso de graduação.
Se você prefere estar mais próximo dos servidores, da infraestrutura, e de outros engenheiros de aplicações, foque em plataforma. Entenda os conceitos necessários para que uma aplicação seja disponibilizada no mundo.
Leituras adicionais:
