Os cargos de uma empresa de software, explicados sem rodeios

Publicado em 2026-09-12 por frfrand

Qué hace realmente cada uno, por qué los títulos varían tanto entre empresas, y qué pasa cuando un rol no existe: el trabajo no desaparece, lo absorbe alguien peor preparado.

Os títulos nesta indústria são um caos. A mesma pessoa pode se chamar Tech Lead numa empresa, Staff Engineer em outra e "aquele que sabe" numa terceira.

Como os nomes não ajudam, vale olhar outra coisa: qual pergunta cada papel responde. Isso sim é estável.

Em torno do produto

Product manager. Responde o que construímos e por quê. Conversa com usuários, analisa dados, decide prioridades. Seu trabalho mais importante e menos visível é dizer não: sem isso, o produto vira uma lista de pedidos.

Project manager / delivery. Responde quando chega e o que está travado. Planea, organiza, coordena entre equipes, remove dependências.

Esta é a confusão que mais custa caro, e vale parar para analisar: são duas perguntas distintas. Quando uma única pessoa faz as duas, o que quase sempre acontece é que a data começa a decidir o escopo, em vez do contrário.

Product owner. Em equipes que usam Scrum, é quem prioriza o backlog. Geralmente se sobrepõe ao product manager; em algumas empresas é a mesma pessoa com outro nome.

Em torno do design

UX / Product designer. Como se usa. Fluxos, estrutura, o que acontece quando algo falha, o que alguém vê ao entrar pela primeira vez.

UI / Visual designer. Como se parece. Tipografia, cor, espaçamento, componentes.

Em equipes pequenas são a mesma pessoa. Vale a distinção porque são habilidades diferentes: alguém pode fazer telas bonitas que são um labirinto, e alguém pode projetar um fluxo impecável que parece feio.

Em torno do código

Frontend, backend, full stack. A divisão que já tratamos: um trabalha no que roda no navegador, outro no que roda no servidor, o terceiro cruza.

DevOps / SRE / Platform. Como se implanta, como se monitora, como se recupera. O nome muda e o foco também: DevOps é mais cultural (para que desenvolvimento e operações não sejam dois mundos), SRE vem do Google e coloca o acento na confiabilidade medida com números.

Tech lead. Decide como se constrói: arquitetura, padrões, qual dívida se paga e qual se posterga. Costuma continuar escrevendo código.

Engineering manager. Cuida das pessoas: crescimento, conflitos, contratações. É um papel distinto do anterior, embora muitas empresas os misturem com maus resultados.

QA. Como se quebra. Não é "o que testa no final": um bom QA participa desde que se define a funcionalidade e faz perguntas incômodas antes de escrever uma linha.

O que acontece quando um papel não existe

Este é o ponto que mais vale do artigo.

Em uma equipe pequena é normal não ter todos os papéis. O que não é certo é que o trabalho desapareça. Alguém o absorve, quase sempre sem tempo nem formação para isso:

• Sem papel de produto: as prioridades são decididas por quem programa, baseadas na intuição e em quem insistiu mais.
• Sem papel de design: a interface acaba sendo um reflexo do modelo de dados. Funciona, mas não se entende.
• Sem QA: os usuários testam. Em produção.
• Sem ninguém de infraestrutura: o deploy é sustentado por uma pessoa, e esse conhecimento não está escrito.

Saber qual papel falta não obriga a contratar. Mas permite dizer "esta parte estamos fazendo mal de propósito", o que é muito diferente de não perceber.

Um apunte sobre equipes de duas ou três pessoas

Em uma equipe muito pequena, uma pessoa faz de tudo. O que funciona não é fingir que os papéis não existem, mas sim colocar o chapéu de propósito: "agora estou decidindo o que construir" é um momento distinto de "agora estou decidindo como construir".

Separar esses momentos, mesmo que seja a mesma pessoa, melhora bastante as duas decisões.