Guia de entrevista para analista de negócios

Estrutura: Objetivo -> stakeholders -> decisões -> dados -> requisitos -> validação

Primeiro, eu esclareceria o objetivo de negócio. Um dashboard deve apoiar decisões, não apenas exibir dados. Eu perguntaria quais decisões ele precisa embasar, quem vai usá-lo, com que frequência, que ações essas pessoas vão tomar a partir dele e quais são as dores atuais. Depois, identificaria os stakeholders: executivos, gestores, equipes operacionais da linha de frente, finanças, engenharia de dados, compliance e quem for dono dos sistemas de origem. Cada grupo pode precisar de visões, definições e frequências de atualização diferentes. Em seguida, definiria as métricas e os requisitos de dados. Para cada métrica, eu documentaria a definição, o responsável, a tabela ou sistema de origem, a lógica de cálculo, os filtros, a granularidade, a frequência de atualização e as ressalvas conhecidas. Também esclareceria permissões de acesso, necessidades de exportação, drill-downs, alertas e requisitos de histórico e tendência. Com os requisitos rascunhados, eu validaria tudo com os stakeholders usando mockups ou wireframes, confirmando que o dashboard responde às decisões pretendidas e que as definições das métricas batem com a fonte da verdade. Por fim, definiria critérios de aceite e cenários de homologação para que o dashboard possa ser testado antes do lançamento.

Estrutura: Problema antes da solução

Eu começaria entendendo o problema por trás da solução pedida. Como funciona o processo de aprovação hoje? Onde está a dor: velocidade, erros, conformidade, visibilidade, carga de trabalho, experiência do cliente ou trilha de auditoria? Quem envia as solicitações, quem aprova e o que acontece depois da aprovação? Depois, mapearia o fluxo: criação da solicitação, campos obrigatórios, validações, regras de roteamento, níveis de aprovação, escalonamento, rejeição, reenvio, notificações, relatórios, logs de auditoria e exceções. Também perguntaria sobre volumes, expectativas de SLA, requisitos de compliance, perfis de usuário e integração com os sistemas existentes. Entre os requisitos importantes estão as regras de aprovação, o modelo de permissões, a lógica de negócio, os casos de borda, os relatórios e as necessidades não funcionais, como segurança, desempenho, disponibilidade e auditabilidade. Eu evitaria aceitar “sistema de aprovação automatizado” como o requisito. O requisito é o resultado de negócio e as regras. A automação pode ser a solução certa, mas só depois que o processo e a lógica de decisão estiverem claros.

Estrutura: Entender a mudança -> avaliar o impacto -> priorizar -> comunicar

Primeiro, eu entenderia o que mudou e por quê. É uma nova necessidade de negócio, um requisito que ficou de fora, uma mudança regulatória, uma preferência de stakeholder, uma restrição técnica ou algo descoberto nos testes? O motivo importa, porque algumas mudanças são obrigatórias e outras são trade-offs. Depois, avaliaria o impacto em escopo, prazo, custo, dependências, experiência do usuário, modelo de dados, integrações, testes, treinamento e risco. Eu estimaria esse impacto junto com produto, engenharia, QA e os stakeholders de negócio. Em seguida, decidiria como tratar a mudança: incluir agora, adiar, substituir outro requisito ou recusar, se ela não apoiar o objetivo. A decisão deve ficar registrada em um log de mudanças, com a justificativa. Por fim, comunicaria com clareza. O pior cenário é o scope creep escondido. Um bom BA deixa os trade-offs visíveis e mantém os stakeholders alinhados sobre o que será e o que não será entregue.

Estrutura: Estado atual -> gargalos -> causa-raiz -> estado futuro -> métricas

Primeiro, eu mapearia o processo atual de onboarding, do cadastro do cliente até a ativação completa, identificando cada etapa, responsável, sistema, passagem de bastão, dependência, aprovação, exigência de documento e caminho de exceção. Depois, levantaria o tempo de ciclo por etapa, e não apenas a duração total. Eu segmentaria o onboarding por tipo de cliente, produto, região, nível de risco e canal. A média de 10 dias pode esconder clientes simples que concluem em 2 dias e clientes complexos que levam 20. As causas-raiz podem incluir digitação manual, documentos faltando, fila na análise de compliance, responsabilidades indefinidas, aprovações duplicadas, falhas de integração entre sistemas ou clientes esperando instruções. Para cada gargalo, eu estimaria o impacto e a viabilidade. No estado futuro, as opções podem incluir validação de documentos logo no início, lembretes automáticos, execução em paralelo de compliance e configuração, formulários de autoatendimento, roteamento por nível de risco, acompanhamento de status mais claro e eliminação de aprovações desnecessárias. Como métricas de sucesso: tempo de onboarding na mediana e no p90, taxa de conclusão, taxa de retrabalho, satisfação do cliente, exceções de compliance e chamados de suporte. Eu recomendaria fazer um piloto do novo fluxo com um segmento de clientes antes da implantação completa, principalmente se houver mudanças de compliance ou de sistema.

Estrutura: Escopo -> atores -> fluxo -> exceções -> controles

Eu começaria definindo o escopo: onde o processo começa, onde termina, quais equipes e sistemas estão incluídos e qual resultado de negócio ele apoia. Para o estado atual, documentaria atores, etapas, sistemas, entradas, saídas, pontos de decisão, passagens de bastão, tempos de espera, pontos de dor e exceções. Um diagrama de raias (swimlane) ajuda bastante, porque mostra quem é responsável por cada parte entre as equipes. Eu validaria o mapa com as pessoas que realmente executam o processo, e não só com os gestores. Para o estado futuro, mostraria as etapas alteradas, o trabalho eliminado, as etapas automatizadas, os novos controles, as mudanças de sistema, as mudanças de papéis e o tratamento de exceções. Também documentaria premissas, dúvidas em aberto, dependências e métricas de sucesso. A documentação final precisa ser compreensível para usuários de negócio, equipes técnicas, QA, treinamento e operações. Se públicos diferentes precisarem de níveis de detalhe diferentes, eu criaria um resumo executivo e também um mapa de processo detalhado.

Estrutura: Join -> filtro -> agrupar por mês e categoria -> somar a receita

Vamos supor que temos as tabelas orders, order_items e products. O primeiro passo importante é identificar a granularidade. A receita pode estar registrada no nível do pedido ou do item. Se a categoria do produto está no nível do item, devemos agregar a receita dos itens por categoria, em vez de juntar a categoria diretamente à receita no nível do pedido e duplicar os totais. A consulta deve fazer o join de order_items com products por product_id e depois com orders para obter a data e o status do pedido, filtrar os pedidos concluídos, agrupar pelo mês (com date_trunc) e pela categoria do produto e, por fim, somar a receita dos itens. Se houver reembolsos ou descontos, é preciso esclarecer se a receita deve ser bruta ou líquida. Uma resposta forte também menciona a validação: comparar a receita mensal total da consulta com um relatório de finanças ou com a fonte da verdade, verificar se há categorias de produto faltando e conferir se pedidos cancelados ou de teste foram excluídos.

Estrutura: Objetivo -> qualidade do atendimento -> eficiência -> resultado para o cliente -> métricas de proteção

Primeiro, eu esclareceria o objetivo da equipe de suporte: reduzir o tempo de resolução, aumentar a satisfação do cliente, controlar custos, reduzir escalonamentos ou sustentar o crescimento. Os KPIs precisam equilibrar experiência do cliente e eficiência operacional. As métricas centrais podem incluir tempo de primeira resposta, tempo médio de resolução, cumprimento de SLA, backlog, taxa de reabertura, taxa de escalonamento, resolução no primeiro contato, CSAT, taxa de contato por cliente, custo por chamado e volume de chamados por categoria. Eu segmentaria por tipo de problema, prioridade, canal, nível do cliente, produto, região e agente ou equipe. Médias podem esconder problemas graves em chamados de alta prioridade ou em clientes corporativos. As métricas de proteção (guardrails) são essenciais. Se os agentes forem cobrados apenas por reduzir o tempo de atendimento, a qualidade pode cair. Se só o CSAT for otimizado, o custo pode subir. Um dashboard equilibrado deve mostrar velocidade, qualidade, carga de trabalho e causas-raiz, para que a equipe possa melhorar processo, produto e dimensionamento.

Estrutura: Validar -> decompor -> segmentar -> diagnosticar -> recomendar

Primeiro, eu validaria o número. Verificaria a atualização dos dados, mudanças no sistema de origem, filtros, período selecionado, devoluções e reembolsos, conversão de moeda e se a definição do dashboard mudou. Depois, decomporia as vendas em seus direcionadores: tráfego ou leads, taxa de conversão, ticket médio, preço, volume, mix de produtos, região, canal, clientes novos versus existentes e desempenho por vendedor ou loja. Segmentar a queda é fundamental. Uma queda total de 15% pode vir de um único canal, uma linha de produtos, uma região ou um segmento de clientes. Em seguida, diagnosticaria as causas prováveis: sazonalidade, mudanças no investimento em marketing, movimentos da concorrência, ruptura de estoque, mudanças de preço, qualidade do pipeline de vendas, problemas no site, condições econômicas ou erros de relatório. A recomendação depende do direcionador. Se o tráfego caiu após cortes em mídia paga, eu revisaria o investimento por canal. Se a conversão caiu no mobile, investigaria o checkout ou o desempenho do site. Se o mix de produtos mudou, ajustaria promoções ou estoque. Eu comunicaria o nível de confiança da análise e os próximos dados necessários.

Estrutura: Usuário -> objetivo -> valor -> condições testáveis

Uma boa história de usuário descreve quem precisa de algo, do que precisa e por que isso importa. O formato mais comum é: Como [usuário], quero [funcionalidade], para que [benefício]. A parte do valor é importante porque ajuda a equipe a fazer trade-offs. Os critérios de aceite devem ser específicos e testáveis. Eles definem o que precisa ser verdade para que a história esteja concluída. Bons critérios cobrem o caminho feliz, validações, permissões, estados de erro, casos de borda, regras de dados e, quando relevante, necessidades não funcionais. Exemplo: Como gerente de suporte, quero filtrar chamados por prioridade e status de SLA para que eu consiga identificar o trabalho urgente. Os critérios de aceite poderiam incluir os filtros disponíveis, o estado padrão, as combinações de filtros, o comportamento quando não há resultados, as regras de permissão, a exportação e as expectativas de desempenho. Um bom BA também valida as histórias de usuário com stakeholders, engenharia, QA e design antes do início do desenvolvimento.

Estrutura: O porquê do negócio, o quê do sistema, a fatia de entrega

O BRD (documento de requisitos de negócio) explica o problema de negócio, os objetivos, o escopo, os stakeholders, os requisitos de alto nível, as premissas, as restrições e as métricas de sucesso. Ele responde por que o trabalho importa e qual resultado de negócio é necessário. O FRD (documento de requisitos funcionais) descreve com mais detalhe o que o sistema precisa fazer: fluxos, regras de negócio, campos, permissões, integrações, relatórios e exceções. Ele ajuda as equipes técnicas a entender o comportamento esperado. A história de usuário é uma unidade de entrega menor, usada em times ágeis. Ela descreve uma necessidade do usuário e os critérios de aceite que podem ser construídos e testados dentro de uma sprint ou incremento. Os documentos exatos variam de empresa para empresa. O ponto principal é que a documentação deve combinar com o modelo de entrega e com o risco. Um fluxo bancário regulado pode exigir uma documentação mais robusta do que uma pequena mudança em um dashboard interno.

Estrutura: Escopo -> usuários -> cenários -> dados -> defeitos -> aceite formal

Primeiro, eu definiria o escopo da homologação: qual fluxo, quais usuários, sistemas, integrações, relatórios e regras de negócio serão testados. A homologação deve validar se o negócio está pronto, e não repetir cada teste de QA. Depois, identificaria os participantes: analistas de sinistros, supervisores, compliance, operações e usuários de relatórios. Então, criaria cenários baseados em casos reais do negócio: sinistro padrão, documentos faltando, sinistro de alto valor, sinistro recusado, sinistro escalonado, sinistro duplicado e tratamento de exceções. Prepararia uma massa de teste que reflita as condições reais, incluindo casos-limite, permissões, transições de status, notificações, trilha de auditoria, relatórios e integrações com os sistemas seguintes da cadeia. Cada cenário deve ter resultados esperados e critérios de aceite. Durante a homologação, acompanharia os defeitos com severidade, responsável, status e impacto no negócio, separando defeitos reais de lacunas de treinamento ou pedidos de mudança. O aceite final deve confirmar que os cenários críticos passaram, que os problemas conhecidos foram aceitos e que os usuários estão prontos para a implantação.

Estrutura: Entendimento comum -> restrições -> opções -> documentação

Eu começo garantindo que o problema de negócio e o resultado esperado estejam claros. Depois, trabalho com a engenharia para entender restrições técnicas, dependências, pontos de integração, impactos no modelo de dados, necessidades de desempenho e questões de segurança. Se um requisito é tecnicamente complexo, eu o quebro em partes menores: regra de negócio, fluxo do usuário, requisito de dados, comportamento da API, lógica de permissões, tratamento de erros e necessidade de relatório. Uso diagramas, exemplos e dados de amostra para reduzir a ambiguidade. Também peço à engenharia opções e trade-offs. Pode existir um MVP mais simples, um caminho de entrega em fases ou uma restrição técnica que exija ajustar o requisito. Meu papel não é desenhar o sistema sozinho; é garantir que a solução continue atendendo à necessidade do negócio e que os trade-offs fiquem visíveis para os stakeholders. A documentação deve registrar as decisões acordadas, as dúvidas em aberto, as premissas e os critérios de aceite, para que a equipe não dependa da memória.

Estrutura: Medir -> segmentar -> diagnosticar -> melhorar

Primeiro, eu definiria o que é adoção. É login, uso da funcionalidade, fluxo concluído, uso recorrente ou resultado de negócio? Depois, mediria a adoção por grupo de usuários, departamento, região, função, turma de treinamento e tempo desde o lançamento. Em seguida, diagnosticaria a causa. Os usuários podem não saber que a funcionalidade existe, não entender o valor, achá-la difícil de usar, não ter permissão ou continuar presos aos processos antigos. Também pode ser que a funcionalidade não resolva o problema real. Chamados de suporte, entrevistas com usuários, gravações de sessão, observação do processo e funis de uso ajudam nesse diagnóstico. As ações podem incluir treinamento, comunicação melhor, melhorias de UX, mudanças no fluxo, reforço por parte dos gestores, migração das ferramentas antigas, ajustes de permissão ou mudanças de requisitos. Se a adoção está baixa porque a solução não atendeu à necessidade, eu reconheceria isso e voltaria à fase de descoberta. O sucesso deve ser medido não só pelo uso, mas pelo resultado de negócio pretendido: tempo economizado, redução de erros, melhoria de SLA, impacto na receita ou satisfação do cliente.

Estrutura: Valor de negócio -> urgência -> risco -> esforço -> dependências

Primeiro, eu esclareceria os objetivos de negócio do período. A priorização precisa estar ligada a resultados como receita, conformidade regulatória, experiência do cliente, redução de custos, redução de riscos ou eficiência operacional. Depois, avaliaria cada demanda por valor de negócio, urgência, risco regulatório ou operacional, impacto no usuário, esforço, dependências e grau de confiança. Um modelo simples de pontuação pode ajudar, mas eu não o usaria às cegas. Algumas demandas são obrigatórias por causa de compliance ou de incidentes críticos. Eu agruparia as demandas em obrigatórias, de alto valor, quick wins, dependências e adiadas. Então, alinharia com os stakeholders de forma transparente: o que foi selecionado, o que foi adiado, por quê e que evidências mudariam a decisão. Um bom BA também procura duplicidades e causas-raiz. Vinte demandas podem representar cinco problemas de fundo. Resolver a causa-raiz pode ser melhor do que entregar muitas demandas desconectadas.

Estrutura: Custo atual -> risco de erro -> custo da automação -> benefícios -> recomendação

Eu avaliaria o valor quantitativo e o qualitativo. O custo atual é de 40 horas por mês multiplicadas pelo custo total da mão de obra (com encargos), somado ao custo dos erros, ao custo dos atrasos, ao risco de auditoria e ao custo de oportunidade. Se o processo afeta relatórios financeiros ou compliance, a redução de risco pode pesar mais do que a economia de mão de obra. Depois, estimaria o custo da automação: engenharia ou fornecedor, manutenção, tratamento de exceções, controles, testes, treinamento e integração com os sistemas de origem. Alguns processos de conciliação são simples e repetitivos; outros exigem julgamento e só podem ser parcialmente automatizados. Também analisaria o crescimento do volume. Um processo que hoje leva 40 horas pode passar a levar 100 à medida que o negócio escala. A automação pode se justificar pela capacidade e pela precisão no futuro, mesmo que o retorno imediato seja moderado. Minha recomendação: automatizar se o processo for estável, baseado em regras, de alto volume, propenso a erros e tiver sistemas de origem claros. Se o processo mudar com frequência ou exigir julgamento, eu começaria pela padronização e por uma automação parcial antes de um desenvolvimento completo.

Estrutura: Definir produtividade -> linha de base -> adoção -> resultado -> métricas de proteção

Primeiro, eu definiria produtividade de vendas. Pode significar mais atividades qualificadas por vendedor, ciclo de vendas mais curto, conversão maior, mais pipeline gerado, forecast mais preciso ou mais receita fechada por vendedor. A métrica certa depende do objetivo do fluxo. Eu estabeleceria uma linha de base antes do lançamento e compararia com o período posterior, de preferência com um grupo de controle ou uma implantação em fases. Também acompanharia a adoção: os vendedores estão usando o fluxo corretamente ou o uso está baixo? Sem adoção, não dá para atribuir mudanças nos resultados ao fluxo. As métricas podem incluir tempo gasto em tarefas administrativas, número de follow-ups concluídos, tempo de resposta a leads, avanço das oportunidades entre etapas, taxa de conversão, duração do ciclo de vendas, higiene do pipeline, precisão do forecast e receita por vendedor. Como métricas de proteção, eu olharia qualidade dos dados, satisfação dos vendedores, experiência do cliente e tentativas de manipular as métricas. Eu segmentaria por equipe, região, tempo de casa, segmento e gestor, porque a adoção e o impacto costumam variar. A recomendação final deve dizer se vale escalar, ajustar o treinamento, simplificar o fluxo ou mudar os requisitos.

Estrutura: Entender os objetivos -> expor os trade-offs -> usar evidências -> decidir

Primeiro, eu entenderia o objetivo por trás do pedido de cada stakeholder. Requisitos conflitantes muitas vezes refletem incentivos diferentes, e não apenas opiniões diferentes. Por exemplo, vendas pode querer flexibilidade, enquanto compliance quer controle. Depois, deixaria o conflito explícito: o que cada requisito implica, quem é afetado, que riscos existem e se é possível atender aos dois por meio de configuração, permissões, entrega em fases ou mudança de processo. Sempre que possível, usaria evidências: volume de usuários, impacto na receita, risco de compliance, taxa de erro, impacto no cliente, custo ou carga operacional. Se a decisão exigir alguém com autoridade sobre o trade-off, eu escalaria com opções e uma recomendação, em vez de levar uma discussão sem solução. Por fim, documentaria a decisão, a justificativa e as necessidades adiadas. O papel do BA é criar clareza e alinhamento, não escolher um lado em silêncio.

Estrutura: Impacto no negócio, opções, trade-offs

Eu traduzo a restrição em impacto no negócio. Em vez de dizer “a API não suporta isso”, explico o que isso significa na prática: custo maior, prazo mais longo, menor confiabilidade, risco de segurança, contorno manual ou lançamento adiado. Depois, apresento opções. Por exemplo: a opção A entrega o requisito completo em oito semanas; a opção B entrega o fluxo principal em três semanas, com tratamento manual de exceções; e a opção C usa uma ferramenta existente, mas tem limitações de relatório. Cada opção deve vir com seus trade-offs. Recursos visuais e exemplos ajudam. Um diagrama simples, um fluxo de exemplo ou dados fictícios tornam as restrições concretas. Evito jargão técnico, a menos que seja necessário, e confirmo se a pessoa entendeu. O objetivo não é tornar os stakeholders técnicos. É ajudá-los a tomar decisões bem informadas.

Estrutura: Problema -> análise -> solução -> implementação -> impacto

Escolha um processo com um antes e depois bem claros. Comece pelo problema: tempo de ciclo longo, taxa de erro alta, esforço manual, pouca visibilidade, reclamações de clientes ou risco de compliance. Depois, explique como você analisou a situação. Você mapeou o processo atual, entrevistou usuários, mediu gargalos, revisou dados, identificou causas-raiz ou comparou sistemas? Mostre que sua recomendação foi baseada em evidências. Em seguida, explique a solução e o seu papel na implementação: requisitos, alinhamento de stakeholders, redesenho do processo, mudanças de sistema, homologação, treinamento e implantação. Feche com um impacto mensurável, como horas economizadas, redução de erros, melhoria de SLA, redução de custos ou aumento da satisfação do cliente. Uma resposta forte também inclui o que você aprendeu e como melhoraria ainda mais o processo.

Estrutura: Ambiguidade -> premissas -> validação -> decisão

Escolha uma história em que esperar pela informação perfeita teria atrasado o andamento do trabalho. Explique o que era desconhecido, por que a decisão importava e quais informações você tinha. Depois, descreva como você avançou de forma responsável: documentou premissas, buscou primeiro as informações faltantes de maior valor, consultou stakeholders, montou cenários, usou dados aproximados (proxies) ou recomendou uma abordagem em fases. O segredo é mostrar discernimento. Você não deve parecer descuidado, mas também não deve parecer paralisado. Analistas de negócios muitas vezes precisam fazer os projetos andarem enquanto deixam a incerteza visível. Feche com o resultado e com o que mudou quando mais informações ficaram disponíveis.

Estrutura: Contexto -> detalhe -> risco -> ação -> resultado

Use uma história em que a atenção aos detalhes evitou retrabalho, risco de compliance, erros de dados, impacto no cliente ou problemas no lançamento. Comece pelo contexto do projeto e por que o detalhe importava. Depois, explique como você o encontrou: revisando requisitos, testando casos de borda, conciliando dados, mapeando exceções do processo ou validando premissas com usuários. A história deve mostrar método, não sorte. Em seguida, descreva a ação que você tomou. Você atualizou critérios de aceite, segurou uma release, alinhou stakeholders, corrigiu um relatório ou criou um controle? Feche com o resultado: defeito evitado, dinheiro economizado, apontamento de auditoria evitado ou experiência do usuário melhorada. Evite transformar a história em uma narrativa sobre perfeccionismo. Mostre que o foco era proteger os resultados do negócio.