Analista de negócios: o que faz e como montar um portfólio prático

Introdução

O analista de negócios ajuda uma organização a compreender um problema antes de escolher a solução. Em uma empresa, uma queixa como “o atendimento está lento” pode esconder causas diferentes: cadastro duplicado, informação incompleta, aprovação sem responsável, sistema inadequado ou regra pouco clara. Comprar uma ferramenta sem investigar o fluxo pode apenas digitalizar o desperdício.

Essa capacidade de transformar situações confusas em decisões verificáveis explica por que a função aparece em contextos variados, de operações e produtos digitais a finanças, logística, serviços e setor público. O cargo pode receber nomes diferentes, e nem toda vaga exige as mesmas técnicas. Ainda assim, existe um núcleo comum: entender necessidades, envolver as pessoas certas, analisar processos, definir requisitos e avaliar se a mudança entregou valor.

Neste guia, você verá o que um analista de negócios faz, quais competências desenvolver e como montar um portfólio prático mesmo sem experiência formal no cargo. Também encontrará um projeto hipotético completo, modelos de entregáveis, dicas para entrevistas e cuidados para não transformar o portfólio em uma coleção de diagramas sem propósito.

O que é análise de negócios

Análise de negócios é uma prática voltada a viabilizar mudanças úteis em uma organização. O profissional investiga necessidades, contexto, partes interessadas, riscos e alternativas para apoiar decisões. A solução pode envolver tecnologia, mas também pode ser uma mudança de processo, política, responsabilidade, treinamento, canal ou combinação desses elementos.

O International Institute of Business Analysis, o IIBA, trata a análise de negócios como uma disciplina ligada à identificação de necessidades e à recomendação de soluções que entreguem valor às partes interessadas. Essa definição é importante porque afasta dois equívocos: o analista não é apenas alguém que escreve documentos e não deve começar o trabalho supondo que a resposta será um software.

Na prática, a pergunta central não é “qual funcionalidade devemos construir?”, mas “qual resultado precisa mudar, para quem, em qual contexto e como saberemos se a mudança funcionou?”.

O que um analista de negócios faz

O cotidiano varia conforme empresa, setor e nível de maturidade. Em uma equipe de produto, o analista pode colaborar com produto, design, engenharia, atendimento e dados. Em operações, pode mapear um fluxo, reduzir ambiguidades e organizar indicadores. Em um projeto regulatório, pode relacionar regras, sistemas, controles e evidências.

As atividades mais comuns incluem:

1. compreender o problema e seus limites;
2. identificar pessoas e áreas afetadas;
3. levantar informações por entrevistas, observação, documentos e dados;
4. representar o processo atual;
5. localizar causas, restrições e oportunidades;
6. definir necessidades e requisitos;
7. comparar alternativas;
8. apoiar priorização e validação;
9. acompanhar a mudança;
10. avaliar resultados e aprender com a implementação.

O profissional não precisa executar tudo sozinho. Sua contribuição é criar entendimento compartilhado e rastreabilidade: cada decisão deve ter uma razão, uma fonte e um critério de validação.

Comece pelo problema, não pela solução

Uma solicitação normalmente chega formulada como solução: “precisamos de um aplicativo”, “coloque um botão”, “automatize a planilha” ou “crie um painel”. O analista deve acolher a demanda sem tratá-la como requisito definitivo.

Uma sequência útil de perguntas é:

• quem enfrenta a dificuldade;
• em qual momento do trabalho ela aparece;
• qual consequência produz;
• como o processo funciona hoje;
• quais evidências sustentam o relato;
• o que já foi tentado;
• quais limites não podem ser ignorados;
• qual resultado seria considerado melhor.

Essa investigação evita resolver o sintoma errado. Também ajuda a separar fatos, hipóteses e preferências. Uma pessoa pode acreditar que a causa é a lentidão do sistema, enquanto a observação mostra que a maior espera ocorre antes do cadastro, quando faltam documentos.

Identifique as partes interessadas

Parte interessada é qualquer pessoa, grupo ou entidade que influencia a mudança, é afetada por ela ou possui informação necessária. Em um processo de atendimento, isso pode incluir cliente, atendente, supervisor, equipe técnica, jurídico, segurança, financeiro e fornecedor.

Não basta criar uma lista de nomes. Registre o papel de cada parte:

O desafio é equilibrar vozes. Quem ocupa cargo mais alto não conhece necessariamente todos os detalhes da execução, e quem executa uma etapa pode não enxergar efeitos em outras áreas.

Faça elicitação com objetivo claro

Elicitação é o trabalho de obter e desenvolver informações com as partes interessadas. Entrevista é apenas uma técnica. Também é possível observar a atividade, analisar documentos, promover oficina, revisar chamados, aplicar questionário ou testar um protótipo.

Antes de cada conversa, defina:

• o que precisa ser descoberto;
• quem possui essa informação;
• quais perguntas são essenciais;
• que material deve ser consultado;
• como os achados serão registrados;
• quem validará o entendimento.

Perguntas abertas ajudam a revelar o fluxo: “o que acontece depois?”, “quando esse caso sai do caminho normal?” e “como você sabe que a etapa terminou?”. Perguntas fechadas servem para confirmar um ponto específico. Evite conduzir a resposta, como em “você concorda que a planilha é o problema?”.

Ao final, recapitule decisões, dúvidas e próximos passos. Uma boa sessão não termina com uma transcrição extensa, mas com informação organizada e verificável.

Mapeie o processo atual

O mapa do processo atual mostra como o trabalho realmente acontece. Ele deve incluir início, fim, atores, atividades, decisões, entradas, saídas, esperas, exceções e sistemas utilizados. O nível de detalhe depende da pergunta do projeto.

Um mapa útil torna visíveis pontos como:

• transferência sem confirmação;
• aprovação sem prazo ou responsável;
• digitação repetida;
• regra interpretada de formas diferentes;
• documento solicitado tarde;
• exceção tratada fora do controle;
• informação crítica mantida apenas em conversa.

Não desenhe o fluxo sozinho com base em um manual. Compare o procedimento previsto com a prática observada. Quando houver diferença, registre-a sem culpar pessoas. Muitas adaptações surgem porque o processo oficial não cobre uma situação real.

Diferencie causa, sintoma e consequência

Um problema bem definido evita conclusões apressadas. Considere:

• sintoma: clientes perguntam repetidamente sobre o andamento;
• consequência: atendimento gasta tempo procurando atualizações;
• hipótese de causa: o processo não registra próximo passo;
• evidência necessária: análise de atendimentos e observação do fluxo;
• causa confirmada: conclusão obtida após investigação.

Ferramentas como os cinco porquês ou o diagrama de causa e efeito podem organizar hipóteses, mas não substituem evidências. O analista deve indicar o que está confirmado, o que ainda é suspeita e como cada hipótese será testada.

Defina requisitos que possam ser verificados

Requisito descreve uma necessidade, condição ou capacidade necessária. Ele pode ser de negócio, de parte interessada, de solução ou de transição. A terminologia usada pela organização pode variar; o importante é manter clareza e rastreabilidade.

Um requisito fraco diz: “o sistema deve ser rápido e fácil”. Um requisito melhor identifica contexto, comportamento esperado e critério de verificação. Quando não houver medida validada, não invente uma. Registre que o limite precisa ser definido com as pessoas responsáveis.

Para cada requisito, considere:

• identificação única;
• descrição clara;
• origem;
• objetivo relacionado;
• prioridade;
• regra aplicável;
• critério de aceitação;
• dependências;
• dúvidas abertas;
• histórico de alteração.

Requisitos não funcionais também importam: segurança, disponibilidade, acessibilidade, privacidade, desempenho e auditabilidade podem determinar se a solução é adequada.

Escreva critérios de aceitação

Critério de aceitação torna uma expectativa testável. Ele descreve condições que precisam ser atendidas para considerar uma entrega aceita. Não deve afirmar detalhes arbitrários nem substituir uma regra de negócio ainda não confirmada.

Um formato simples é contexto, ação e resultado. Exemplo hipotético:

• dado que uma solicitação possui documento obrigatório ausente;
• quando o atendente tenta encaminhá-la para análise;
• então o sistema informa a pendência e mantém a solicitação na etapa de conferência.

O critério precisa ser revisado por quem entende a regra e por quem implementará ou testará o comportamento. Casos de erro e exceções devem aparecer, não apenas o caminho ideal.

Compare alternativas com critérios explícitos

Depois de compreender o problema, o analista pode ajudar a comparar alternativas. Não se trata de escolher pela ferramenta mais conhecida. Estabeleça critérios ligados ao objetivo e às restrições.

As notas, pesos e critérios devem ser acordados, não fabricados para justificar uma escolha já feita. Quando faltarem dados, registre a incerteza.

Acompanhe a entrega sem abandonar a análise

O trabalho não termina quando os requisitos são enviados. Durante a implementação, surgem dúvidas, mudanças de contexto e novas restrições. O analista apoia o esclarecimento e mantém a ligação entre problema, requisito, decisão e teste.

Também verifica se a solução continua coerente. Uma equipe pode entregar exatamente o que foi descrito e ainda assim não resolver a necessidade. Por isso, resultado operacional e retorno das partes interessadas precisam ser avaliados após a mudança.

Competências essenciais

Conhecimento de técnicas ajuda, mas o desempenho depende de uma combinação de habilidades.

Pensamento analítico

É a capacidade de decompor um problema, reconhecer relações, testar hipóteses e avaliar evidências. Na prática, significa não confundir coincidência com causa e não escolher uma conclusão antes de investigar.

Comunicação

O analista traduz perspectivas. Precisa escrever de forma objetiva, fazer perguntas sem constranger, facilitar conversas difíceis e confirmar entendimentos. Comunicação não é produzir apresentações bonitas; é reduzir ambiguidade.

Conhecimento do negócio

Entender o setor, o processo e a linguagem da organização melhora perguntas e decisões. Isso não significa fingir domínio. O profissional deve declarar limites, consultar especialistas e aprender continuamente.

Modelagem

Modelos representam processos, informações, regras, decisões ou interações. Fluxograma, jornada, tabela de decisão, modelo de dados e protótipo são exemplos. Escolha a representação que responde à dúvida do projeto.

Colaboração e facilitação

Reuniões de análise devem produzir decisões, hipóteses ou próximos passos. O analista prepara a pauta, inclui as pessoas necessárias, administra divergências e registra resultados.

Como montar um portfólio prático

Um portfólio de analista de negócios não precisa expor informações confidenciais nem simular experiência que você não possui. Ele pode apresentar estudos hipotéticos, projetos acadêmicos, melhorias voluntárias ou análises de processos públicos.

Escolha um problema pequeno o suficiente para ser compreendido de ponta a ponta. Exemplos:

• agendamento de serviço em uma oficina fictícia;
• pedidos de uma confeitaria fictícia;
• triagem de chamados internos;
• empréstimo de equipamentos em uma escola;
• organização de inscrições em um evento comunitário.

Evite começar por um sistema bancário completo, hospital ou plataforma nacional. Escopo exagerado leva a suposições e documentos superficiais.

Estruture cada estudo de caso

Cada projeto pode seguir esta organização:

1. contexto e aviso de que o caso é hipotético, quando aplicável;
2. problema inicial e por que importa;
3. escopo e itens fora do escopo;
4. partes interessadas;
5. plano de descoberta;
6. processo atual;
7. evidências e hipóteses;
8. requisitos e regras;
9. alternativas avaliadas;
10. processo proposto;
11. critérios de aceitação;
12. riscos e dependências;
13. plano de validação;
14. aprendizados e limitações.

Esse encadeamento mostra raciocínio. Um recrutador ou gestor consegue ver como você saiu de uma situação inicial e chegou a uma recomendação.

Entregáveis que agregam valor

Não inclua um documento apenas para aumentar o portfólio. Para um estudo de caso, um conjunto enxuto pode conter:

• declaração do problema;
• mapa de partes interessadas;
• roteiro de entrevista;
• processo atual e proposto;
• catálogo de regras;
• lista priorizada de requisitos;
• critérios de aceitação;
• matriz de alternativas;
• riscos e perguntas abertas;
• plano de medição.

Explique ao lado de cada artefato qual pergunta ele responde. Isso demonstra que você compreende a finalidade da técnica.

Exemplo hipotético de projeto

Considere a Oficina Horizonte, empresa fictícia que recebe pedidos por telefone e mensagens. Clientes reclamam que precisam repetir dados. A hipótese inicial do proprietário é criar um aplicativo.

O analista começa delimitando o estudo ao agendamento e à confirmação do serviço. Entrevista proprietário, atendente e mecânico; observa a passagem de informações; analisa, sem dados pessoais, exemplos de solicitações; e desenha o fluxo atual.

Ele descobre que cada canal registra informações de modo diferente. O mecânico recebe pedidos sem modelo do veículo ou descrição clara, e o atendente não sabe quando existe capacidade. A causa não está confirmada até que esses achados sejam validados com a equipe.

O processo proposto cria uma ficha padronizada, uma etapa de conferência e uma regra para confirmação. A equipe compara três alternativas hipotéticas: ajustar a ferramenta atual, usar um formulário integrado ou desenvolver uma solução. Os critérios incluem aderência, esforço, manutenção, segurança e facilidade de adoção.

O portfólio não afirma que houve ganho real, porque a solução não foi implantada. Em vez disso, apresenta um plano de validação: acompanhar retrabalho, solicitações incompletas e necessidade de novo contato antes e depois de um piloto. Isso é mais confiável do que inventar uma porcentagem de melhoria.

Apresente limitações e decisões

Um bom portfólio deixa claro:

• quais dados são fictícios;
• o que foi assumido;
• o que dependeria de validação;
• quais pessoas seriam consultadas em um projeto real;
• quais riscos permanecem;
• por que uma técnica foi escolhida;
• o que você faria diferente em uma próxima versão.

Essa transparência vale mais que uma falsa certeza. Análise de negócios lida com informação incompleta, e reconhecer limites faz parte do trabalho.

Ferramentas para o portfólio

Você pode criar diagramas, tabelas, textos e protótipos com ferramentas diferentes. A escolha importa menos que a clareza do resultado. Um diagrama simples e legível é melhor que uma notação sofisticada aplicada de forma errada.

Publique o material em formato acessível, com navegação clara e textos alternativos quando houver imagens. Remova nomes, documentos, chaves, endereços e qualquer dado confidencial. Se o caso veio de experiência profissional, obtenha autorização ou recrie-o como situação genérica sem revelar a organização.

Dicas práticas para aplicar

Faça um projeto curto primeiro

Conclua um caso pequeno antes de abrir vários. O objetivo é demonstrar o ciclo completo, não acumular rascunhos.

Registre perguntas antes de diagramas

Liste o que precisa ser descoberto. Depois escolha a técnica capaz de responder. Isso reduz artefatos decorativos.

Mostre versões

Apresente como o entendimento mudou após uma entrevista ou validação. A evolução revela capacidade de aprender com evidências.

Use linguagem do negócio

Explique siglas e evite transformar o estudo em uma prova de jargões. Um decisor precisa compreender o material.

Prepare uma apresentação curta

Treine explicar problema, investigação, principal decisão, risco e próximo passo. Esteja pronto para aprofundar os artefatos quando perguntado.

Peça revisão crítica

Solicite a outra pessoa que identifique lacunas, ambiguidades e conclusões sem evidência. Não peça apenas avaliação estética.

Erros comuns e cuidados importantes

Confundir analista de negócios com gerente de projetos

As funções podem colaborar, mas têm focos diferentes. O analista concentra-se em necessidades, requisitos, valor e solução; a gestão de projetos coordena planejamento e entrega conforme a estrutura adotada.

Confundir análise de negócios com análise de dados

Dados podem apoiar a investigação, mas análise de negócios abrange pessoas, processos, regras, decisões e mudanças. Uma função não substitui automaticamente a outra.

Criar documentação sem leitor

Todo artefato deve ter público e finalidade. Se ninguém o usa para entender, decidir, construir, testar ou operar, revise sua necessidade.

Inventar resultados

Não declare economia, produtividade ou satisfação sem medição. Em projeto hipotético, apresente resultado esperado como hipótese e descreva como seria avaliado.

Esconder exceções

Fluxos perfeitos parecem fáceis, mas o trabalho real inclui cancelamentos, informação ausente, indisponibilidade e casos fora da regra. Inclua exceções relevantes.

Tratar ferramenta como competência principal

Saber operar software ajuda, porém o valor está em escolher a técnica, interpretar achados e apoiar decisões. Ferramentas mudam; raciocínio e comunicação permanecem transferíveis.

Copiar modelos prontos

Templates economizam tempo, mas campos sem propósito criam ruído. Adapte o documento ao problema e explique por que cada parte existe.

Conclusão

O analista de negócios conecta problemas, pessoas, regras e alternativas para tornar mudanças mais conscientes. Seu trabalho começa com investigação, passa por elicitação, processos, requisitos e critérios de aceitação, e continua até a avaliação do resultado.

Para entrar na área, você não precisa esperar um cargo formal para praticar. Escolha um processo simples, declare o caso como hipotético, investigue o contexto, produza poucos artefatos úteis e mostre a relação entre evidência e decisão. Revise o trabalho com alguém e publique apenas informações seguras.

Comece hoje escrevendo uma declaração de problema com quatro elementos: pessoa afetada, situação, consequência e evidência necessária. Esse primeiro parágrafo será a base do seu projeto e impedirá que o portfólio comece pela solução.

Fontes consultadas

IIBA – New to Business Analysis, consultado em 8 de outubro de 2026, para a visão geral da disciplina, atuação profissional e desenvolvimento de carreira.

IIBA – Business Analysis Core Concept Model, consultado em 8 de outubro de 2026, como referência para relacionar mudança, necessidade, solução, contexto, valor e partes interessadas.