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:
Olá Lucas, tudo bem?
Gostei muito do seu texto. Comecei recentemente a produzir alguns conteúdos sobre temas que me agradam, e ainda tenho dificuldades em organizar um material rico desta forma. Parabéns! Vou me inspirar bastante em você para meus materiais futuros.
Eu vejo sentido em uma abordagem Produto vs Plataforma, mas ultimamente tenho uma leve sensação de que várias mudanças deste tipo tem surgido por dois propósitos principais: criar nichos de mercado ou mascarar sobrecarga de função. Me parece que as "big techs" tendem a criar posições cada vez mais específicas para atender demandas específicas. Mas aí vem as empresas de médio e pequeno porte, que não conseguem justificar financeiramente um cargo se restringir a apenas aquele tipo de demanda por um salário de 6 dígitos ao ano, e começam a mascarar a criação de equipes inteiras de um homem só, criando o tal do "fullstack" e outras posições do tipo. Uma época atrás também teve o DevSecOps, que quase sumiu das vagas na mesma velocidade que apareceu (pelo menos é minha impressão). Meu receio é que algumas empresas só utilizem dessa abordagem por conveniência, na expectativa de que um engenheiro de plataforma seja algo como um "super backend".
Acredito ainda que seja interessante contestar uma questão chave: a engenharia de software se estende para além do que muitos acreditam.
Não arrisco dizer que é a maioria pois não tenho dados para embasar uma frase como tal, mas percebo ser razoavelmente comum a concepção que você apresentou. Recentemente contestei um questionamento correlato durante uma entrevista de emprego.
Minha formação foi em uma instituição em que os professores diziam que a ementa do curso foi pensada com enfoque na engenharia de software. Eu já conhecia um pouco de programação, e não só eu como vários de meus colegas tinhamos a definição que você apresentou em mente para o assunto. Meu primeiro professor da matéria discordava plenamente disso, e descobri da pior forma. Fizemos um projeto durante o semestre que compôs 95% da nota, e focamos muito nos aspectos de modelagem e desenvolvimento. Reprovamos. Ainda não concordo com a forma como ele conduziu as avaliações, mas não poderia discordar de que eu não sabia do que se tratava o assunto realmente, só estava preocupado em cumprir o checklist e passar de semestre. O bendito professor frequentemente dizia algo como:
Um bom sistema deve ser eficaz, eficiente, seguro e legal.
Após minha reprovação fiquei intrigado e decidi investigar mais a fundo o que me faltava. Meu pensamento realmente mudou quando comprei e comecei a ler o principal livro de um dos autores referência do assunto, Roger Pressman (Engenharia de Software: Uma abordagem profissional). A ficha não caiu, ela foi empurrada goela abaixo pelo autor logo no segundo capítulo (isto em menos de 30 páginas de um livro que possui mais de 900 páginas de conteúdo, mesmo não se aprofundando em diversos assuntos que cita).
Lendo o livro, a primeira coisa que aprendi foi que a engenharia de software tem como principal foco a qualidade através do processo de desenvolvimento como todo, desde o problema e a expectativa do cliente, até este ter acesso ao produto/serviço. Eu estava sempre muito focado na metade para o final da coisa, e não prestando atenção no início deste processo. E aí que a coisa começou a desenrolar na minha cabeça. A ficha que caiu foi a de que aquela frase do meu professor era na verdade a ponta de um iceberg. Estes 4 aspectos são profundos a ponto de termos áreas de estudos e atuação específicas para cada um (produto, arquitetura, segurança e compliance, respectivamente e de forma simplificada).
Pressman introduz a sessão que fala sobre o processo de software da seguinte forma:
No contexto de engenharia de software, um processo não é uma prescrição rígida de como desenvolver um software. Ao contrário, é uma abordagem adaptável que possibilita às pessoas (a equipe de software) realizar o trabalho de selecionar e escolher o conjunto apropriado de ações e tarefas. A intenção é a de sempre entregar software dentro do prazo e com qualidade suficiente para satisfazer àqueles que patrociaram sua criação e àqueles que vão utilizá-lo.
Eu acho muito interessante este trecho pois ele demonstra claramente as preocupações de quando a engenharia de software teve seu primeiro "boom" em produção de conhecimento: qualidade do que é destinado à alguém, e em tempo hábil. O debate sobre o que é qualidade é estenso por si só, mas desde que li este livro (não o li por completo) tive pra mim que esta área sempre teve como ponto principal o cliente. Todo sistema tem como intenção maior o seu cliente, nem que este seja outro sistema. E o engenheiro que não tiver isto em mente, só não entendeu seu próprio propósito ainda. Isto não quer dizer que ele não terá sucesso, mas que corre mais risco de falhar ao tentar alcançar o que o cliente chamará de "um produto de qualidade".
Tomo a liberdade de fotografar e colocar aqui a sessão do livro que sintetiza meu ponto e significou a virada de chave para meu pensamento sobre o assunto, me fazendo decidir por estudar esta área mais a fundo atualmente. Apesar de ser uma solução um tanto preguiçosa da minha parte, eu não poderia te explicar minha colocação inicial melhor que o próprio autor:
Perceba que o exposto como sendo o núcleo de atuação da engenharia de software vai no sentido oposto da imagem apresentada em seu texto sobre o escopo do engenheiro de software. A ideia do que seria um engenheiro de software, pela definição do que é a própria engenharia de software, é tão extensa que cairia exatamente no que foi colocado sobre o "fullstack" (e concordo plenamente): inalcancável pela abrangência do tema.
Eu acredito que foi o mercado de trabalho quem se preocupou mais em cunhar estes "novos" profissionais, os engenheiros que você apontou além de tantos outros (como os polêmicos e recém criados engenheiros de prompt), que são os profissionais "T-shaped" com foco em diferentes aspectos que vejo muitas vezes contidos na ideia mais tradicional e fundamental de engenharia de software, segundo as principais referências do assunto.
E parte disso seria a explicação (aqui já é puro achismo meu) de não ser comum vermos estes termos nas universidades. A maioria das instituições, como sempre, tendem a se moldar ao mercado, seja para suprir as necessidades deste, seja para lucrar em cima do que está em alta. Mas as focadas em formação de corpo docente e pesquisadores (em sua maioria instituições públicas) parecem relutar contra este "desmembramento" do tema durante a graduação. Os discentes "T-shape" se formam a medida que se especializam através da pós-graduação dentro destes contextos e ainda assim não me parece comum estas nomenclaturas (posso estar muito errado neste trecho todo, e seria bem legal me corrigirem se for o caso).
Vou salvar pra ler mais tarde GODLIKE